Google Chrome では SSL が古いセキュリティ設定を使用していると表示されますが、他のサイトのテストではそうではないと表示されます

Google Chrome では SSL が古いセキュリティ設定を使用していると表示されますが、他のサイトのテストではそうではないと表示されます

CentOS 6.5でLinux Apacheを実行しているWebサーバーにStartSSLをインストールしました。shaaaaaaaaaaaaa.comは次のように言いました

いいですね。example.com には SHA-2 で署名された検証可能な証明書チェーンがあります。

しかし、Debian 7.8のGoogle Chromeでは

接続は AES_128_CBC を使用して暗号化され、認証には SHA1、キー交換メカニズムには ECDHE_RSA が使用されます。

Debianボックスでは、

mkdir ~/StartComCerts
mv /etc/ssl/certs/StartCom* ~/StartComCerts

そして問題は解決しました。しかし、クライアントが自分のコンピュータに変更を加えることを期待するのは現実的な解決策ではありません。そこで、ssls.comからGeoTrust QuickSSL Premium証明書を購入しました。そして、https://knowledge.geotrust.com/support/knowledge-base「証明書は正しくインストールされています」と表示されました。しかし、Debian 7.8 で Chrome を使用してサイトにアクセスすると、次のメッセージが表示されます。

このサイトは弱いセキュリティ設定 (SHA-1 署名) を使用しているため、接続がプライベートでない可能性があります。

そして

このサイトは古いセキュリティ設定を使用しているため、Chrome の将来のバージョンでは安全にアクセスできなくなる可能性があります。

私は自分のサイトをwww.ssllabs.com/ssltest/analyze.htmlでテストしました。私のサイトはAと評価され、署名アルゴリズムはSHA256withRSAであると表示されました。shaaaaaaaaaaaaa.comにアクセスすると、

いいですね。example.com には SHA-2 で署名された検証可能な証明書チェーンがあります。

whynopadlock.com にアクセスし、すべて問題ないことを確認できました。また、Windows 7 を実行している別のコンピューターで Chrome を使用してテストしたところ、エラー メッセージは表示されず、緑色の南京錠が表示されました。

Debian 上の Chrome で SHA-1 エラーが発生する理由がわかりません。

編集 - 2015-06-15

一部の Windows システムでは、Sha-1 の問題もあります。以下は、自宅の Windows システム (左) と職場の Windows システム (右) の Google Chrome のスクリーンショットです。異なるシステムで、Sha-1 キャッシュ証明書を使用しているようです。GeoTrust の指示に従って、中間証明書を設定しました。

SSL警告のスクリーンショット

編集:

私は在宅ビジネスを営んでおり、それが私のウェブサイトの目的です。

答え1

問題は、Windows コンピューターに Avast ウイルス対策ソフトウェアがインストールされていることです。Avast は、Web サイトと Google Chrome の間に SSL 証明書を挿入します。左の画像の上にある「Avast Web/メール シールド」を参照してください。

Google Chrome はローカルで偽装された証明書を検証するため、コンピュータに警告を表示します。Avast AntiVirus は SSL 証明書を偽装して、SSL トラフィックを確認してスキャンできるようにします。Qualys SSL ラボなどのスキャンで真実がわかります。

Avast Web/Mail シールドを無効にして、Google Chrome で再試行できます。こうすることで、Chrome はサーバーが提供する証明書を検証し、Avast がサーバーと Google Chrome の間に挿入した挿入された/偽装された SSL 証明書は検証しなくなります。

左側の画像には、Avast SSL 証明書に関する情報が表示されています。右側には、独自の GeoTrust SSL 証明書に関する情報が表示されています。

Debian マシンでも Linux バージョンの Avast を使用しており、Windows マシンと同様の状況が発生していると想定しています。

答え2

問題は、証明書が署名アルゴリズムとして SHA1 を使用していることです。証明書が実際に SHA2 を使用している場合は、チェーン内のすべての中間証明書 (およびルート証明書) を確認してください。すべての証明書で SHA2 を使用する必要があります。

SHA1 は古い (弱い) 技術なので、もう使用すべきではありません。ほとんどの PKI プロバイダーは両方の可能性を備えています。SHA2 チェーン証明書をダウンロードしてサーバーにアップロードするだけです。これで問題は解決します。

SHA2 証明書 (上記参照) を使用している場合、問題は中間証明書の 1 つにあります。すべての証明書で SHA1 を確認し、代わりに SHA2 証明書を取得してください。

関連情報