mod_proxyを使用したリバースプロキシモードで、mod_sslを使用してApache2.2.25を使用しています。 GoDaddyによって発行された、テスト目的で使用するサーバー証明書があります。チェーンには、_server cert -> GoDaddy intermediate CA -> GoDaddy Root CA
_という3つの証明書があります。中間CA(Go Daddy Secure Certificate Authority-G2)は、クライアントの信頼できるCAのリストに常に含まれているとは限りません。
サーバーへのSSL接続は、ブラウザー(少なくとも一部)では正常に機能しますが、他の一部のクライアントでは機能しません。次のコマンドを使用して、サーバーが完全な証明書チェーンを送信しないことに気付きました:_openssl s_client -showcerts -connect SERVER_URL:443
_、そして実際、コマンドはエラーVerify return code: 21 (unable to verify the first certificate)
を報告します
各VirtualHostでSSLCertificateFile
ディレクティブを使用します。
_SSLCertificateFile certificate.crt
_
証明書.crtファイルに秘密鍵とチェーン内のすべての証明書が含まれている場合。私たちはそれを次のように分割しようとしました:
_SSLCertificateFile server.crt
SSLCertificateKeyFile server.key
SSLCertificateChainFile chain.crt
_
しかし、これは何も変わりませんでした。
ご協力いただきありがとうございます!
[〜#〜]編集[〜#〜]
プロットが厚くなります-証明書とサーバーの組み合わせのようです。
(テストは SSLショッパー ツールで行われます)
あなたは正しい方向に進んでいます。
SSLCertificateFile server.crt >> Your public certificate
SSLCertificateKeyFile server.key >> Your private key
SSLCertificateChainFile chain.crt >> List of intermediate certificates;
in your case, only one - GoDaddy intermediate CA
SSL Labs などのツールを使用してサーバー構成を確認し、正しい中間証明書を送信しているかどうかを確認してください。
SSLCACertificatePath
ディレクティブを使用して、元の.crt
ファイルを指定されたディレクトリに配置することもできます。ただし、それらへのハッシュシンボリックリンクも作成する必要があります。これは、openssl
の一部であるc_rehash
ツールを使用して実行されます。例えば、
Sudo c_rehash /etc/Apache2/ssl/certs
ただし、使用されているハッシュアルゴリズムは2つあることに注意してください。新しいものはopenssl
1.0で導入され、openssl
を1.0以降にアップグレードした後、c_rehash
を再実行する必要があります。これにより、古いスタイルと新しいスタイルの両方のシンボリックリンクが作成されます。
これを行わないと、openssl
(したがってApache
)は中間証明書を見つけることができないため、それらはクライアントに送信されません。 UbuntuサーバーをLucidからPreciseにアップグレードした後、SSLエラーのデバッグにイライラする数時間を費やしました。これには、openssl
の0.9.8から1.0.1へのアップグレードが含まれていました。私は検索しましたが、何が問題になっているのかについてWeb上で手がかりを見つけることができなかったので、自分でそれを理解する必要がありました。
ちなみに、ブラウザにはより大きなルートセットがあり、中間証明書の1つがそのセットに含まれている必要があるため、ブラウザでエラーは発生しませんでした。この問題は、openssl
、wget
、openssl s_client
などのcurl
ベースのコマンドラインプログラムを使用している場合にのみ発生しました。