ChromiumがTLS証明書に満足していない理由と解決策を見つけようとしています。
Chromium(現在58.0.3029.81、Debianテストで実行)をアップグレードして再起動すると、内部GitLabサーバー(統合パッケージを介してDebian Jessieにインストールされている)にアクセスできなくなります。私は得る:
接続はプライベートではありません
攻撃者はgit.ourdomain.netからあなたの情報(パスワード、メッセージ、クレジットカードなど)を盗むことを試みる可能性があります。 NET::ERR_CERT_COMMON_NAME_INVALID
証明書は、システムストアにインストールされている内部CAによって署名されます(に入力/usr/local/share/ca-certificates
)。openssl s_client -verify 5 -verify_return_error -connect git.ourdomain.net:443
私はFirefox 52と;どちらもとても幸せでした。 OpenSSLはチェーンを次のように表示します。
Certificate chain
0 s:/C=US/ST=Virginia/L=Sterling/O=«us»/OU=Servers/CN=git.ourdomain.net
i:/C=US/ST=Virginia/L=Sterling/O=«us»/CN=«us» Certification Authority/[email protected]
OpenSSLとFirefoxはどちらも強力な署名(SHA-512)とパスワード(AES-GCM)を表します。証明書openssl x509 -text
はsha512WithRSAEncryptionに基づいており、4096ビットRSAキーを持っています。 Netscape証明書タイプSSLクライアント、SSLサーバーがあります。
注:「us」とourdomain.netは修正されました。実際の出力では、会社名は「us」で、実際のドメイン名はourdomain.netです。私はすべてのourdomain.netが実際に一致していることを再確認しました。
私が知っている限り、証明書には問題がなく、一般名(git.ourdomain.net)は完全に有効でURLと一致します。それでは、Chromiumは何について文句を言いますか?そして、これが実際に問題にならないと仮定すると、これを無視する方法はありますか?
答え1
そうだChromeエラー308330彼らは、ホスト名を証明書の一般名と一致させると矛盾する危険があると考えて、この機能を無効にしました。 ChromiumはsubjectAltName拡張子とのみ一致します。 Firefoxも同様の変更を適用しましたが、内部証明書ではなくパブリックCAによって発行された最新の証明書にのみ適用されます。これがFirefoxがまだ機能している理由です。
EnableCommonNameFallbackForLocalAnchors
以下を使用して作成できるポリシーを設定することで、Chromiumの変更を上書きできます/etc/chromium/policies/managed/use-common-names.json
。
{
"EnableCommonNameFallbackForLocalAnchors": true
}
Chromiumを作成した後に再起動する必要があるようです。