サーバーにEV SSL証明書をインストールしました。これは正しく行われ、機能しています。問題は、Chromeが緑色のアドレスバーに会社名を表示せず、緑色の南京錠と緑色のhttps://が表示されるときのように標準のSSL証明書があります。
IEとFirefoxには、緑色のバーと会社名が表示されます。
Chromeでこの問題が発生する理由を誰かが知っていますか?
ページに安全でないコンテンツはありません。ssllabs.comでチェックを実行しましたが、結果は「B」に戻りました。
このサーバーは、BEAST攻撃を軽減しません。グレードBにキャップ
BEAST攻撃の脆弱性(詳細)
RC4はい問題(詳細)
誰かがこの問題をどうやって回避するか知っていますか?これは、chromeが他のブラウザよりも有効かどうかを確認するための詳細なテストを行うことを意味しますか?.
ありがとう。
BEAST攻撃の脆弱性(詳細)
RC4はい問題(詳細)
これらの警告は、証明書とは直接関係ありません。彼らはあなたのSSL構成についてもっとです。クライアントがSSLを介してサーバーに接続すると、クライアントとサーバーは、キーの交換とデータの暗号化に使用するプロトコルをネゴシエートします。
BEASTは、SSLv3およびTLSv1の脆弱性です。基本的に、SSLv3とTLSv1(広く実装されていないTLSv1.1で修正済み)に暗号の欠陥があり、ハッカー(中間者)が長時間実行中のセッションを攻撃できるようにします。 BEASTに影響されない暗号を使用し、それらの暗号を優先するようにサーバーを構成することにより、この問題を軽減できます。
Nginxでは、構成は次のようになります。
ssl_ciphers RC4:HIGH:!aNULL:!MD5:!ADH:!kEDH;
ssl_prefer_server_ciphers on;
これは、RC4をサポートするクライアントで使用し、AESにフォールバックします。
https://www.comodo.com/ でも同じ効果が見られます
彼らは自分で署名したEV証明書を持っています。 Firefoxはそれを信頼しています:
しかしChromeはしません。
ChromeはVerisignで正常に動作します。
ここでの問題は、ブラウザがSSL証明書のベンダーを信頼していない可能性があります。どこかで構成をめちゃくちゃにした可能性があります(チェーン証明書は厄介な場合があります)が、ここにURLを投稿しなければ、それを理解するのは困難です。
ロックをクリックして、接続タブをクリックしてから、証明書情報(2番目のスクリーンショットで行ったように)。うまくいけば、その画面でChromeが証明書について間違っていると考えていることがわかります。
ブラウザーdoは、SSL/TLSの多くの側面に関して、特にEV証明書に関しては、異なる動作をします。 失効を異なる方法で処理する1つの例を示します 。
現在の最高評価の回答は実際の回答ではないため、以下を提供します:ChromeではEVで証明書の透明性が必要です 、FirefoxとEdgeおよびSafariでは必要ありません
CTがない証明書のSSL Labsスキャンの例を次に示します。Firefox、Safari、およびEdgeではEVとして、Chromeでは低信頼DV証明書として表示されます。
証明書ベンダーに連絡して、関連するx509v3フィールドを使用して証明書に署名済み証明書タイムスタンプ(SCT)を含めるように依頼することで、これを修正できます(また、修正する必要があります)。