Media Temples Dedicated Virtual4.0でホストされているドメインにワイルドカードSSL証明書をインストールしました。これが私がSSL経由で提供しようとしている簡単なサンプルページです: https://ssltest.bblhosted.com/
さて、私が尋ねた他の人々(約4または5)は、このサイトは、セキュリティ警告なしで、さまざまなブラウザのコンピュータで正常に動作すると言います。ただし、コンピューターで一貫性のない結果が得られます。
これが私の結果です。私は最新のOSXを実行しており、Windows 7はParallelsを介して実行されており、すべてのブラウザーの最新バージョンは次のとおりです。
OSX/Firefox:南京錠が表示されます。問題はありません。 Windows 7/Firefox:警告-'この接続は信頼されていません'
OSX/Chrome:警告-'このサイトのセキュリティは信頼されていません!' Windows 7/Chrome:緑の南京錠-'RappidSSLCAによって識別されたID '。
OSX/Opera:警告-'このサーバーの証明書チェーンは不完全であり、署名者は登録されていません。受け入れますか?」 Windows 7/Opera:南京錠は、「安全に接続された、クリーンなセキュリティレコード」を示しています。
OSX/Safari:警告-'SafariはWebサイトのIDを確認できません '
Windows 7/IE:南京錠は、「サーバーへのこの接続は暗号化されています」と表示します。
私の質問は、誰かがここで問題を引き起こしている可能性があるもの、またはそれを修正する方法について何か洞察を提供できますか?それは私のコンピューターの問題でしょうか?もしそうなら、何ですか?特に奇妙なのは、同じブラウザでOSXとWindows7で逆の結果が得られることです。
使用しているブラウザ/ OSや、それが機能したかどうかをコメントできたとしても、それは素晴らしいことです。ありがとう。
_______更新:
Rapid SSLからの最初の電子メールで、1つの証明書と1つのCA証明書が提供されました。 Christopher Perrinがリンクしている2つのCA証明書 ここ を含むように更新しました。
Ssltest.bblhosted.comを Rapid SSLのツール でテストしましたが、すべてが正しく設定されていると表示されます(ただし、CA証明書を変更する前にそのツールは成功しました)。
このツール エラーが発生します-そして、それはおそらく中間の証明書の問題であると言います。
Pleskを介して証明書を更新していますが、「警告:CA証明書は証明書に署名していません。」という警告が表示されますが、 これによると 、通常はその警告を無視できます。
SSLは、 https://www.bblhosted.com/ 、 https://bblhosted.com/ 、および https://anythinggoeshere.bblhosted)で正常に機能します。 com / -明示的に設定されたサブドメインに対してのみ機能しません。
var/log/httpd/error_logに、「RSAサーバー証明書のワイルドカードCommonName(CN) `* .bblhosted.com 'がサーバー名と一致しません!?」のようなエラーがたくさんあります。
ssl_error_logには、「[警告] RSAサーバー証明書はCA証明書です(BasicConstraints:CA == TRUE !?)」のようなエラーがたくさんあります。
私はそれらが何を意味するのかを知るのに十分な経験がありません。明日も戦い続けます!
OK、クリストファー・ペランは私をSSLCertificateChainFile
で正しい軌道に乗せてくれました-ありがとう。彼らが他の誰かを助ける場合に備えて、ここに詳細があります。私はPlesk11を使用していますが、参照するパスは他の人とは明らかに異なります。
サブドメインssltest.bblhosted.comを作成すると、Pleskは/var/www/vhosts/ssltest.bblhosted.com/conf/13558069200.18494000_httpd.include
(または同様のもの)にファイルを作成します。このファイルは、pleskによって自動的に生成され、Pleskで設定を変更するたびに自動的に上書きされることを除いて、vhost.confファイル(またはvhost_ssl.conf)の目的を効果的に果たします。
ファイルには次の行が含まれています。
SSLCertificateFile /usr/local/psa/var/certificates/cert-Eq8jue
これは私のSSL証明書の場所を示しています。含まれていないのは、CA証明書の場所を示す行です。したがって、次の行が含まれている必要があります。
SSLCertificateChainFile /usr/local/psa/var/certificates/cert-t8ReAO
(明らかに、パスは独自のCA証明書を指している必要があります)。私の知る限り、この行が含まれていないという事実は、Pleskのバグです。そのファイルのSSLCertificateFile
行のすぐ下に行を追加してから、Apacheを再起動すると、機能します。ただし、そうすると、次にその設定を変更したときにファイルが上書きされます。 Pleskのドメインを使用すると、変更が失われます。ファイルの先頭で、Pleskは次の警告を出します。
#ATTENTION!
#
#DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
#SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.
#
#IF YOU REQUIRE TO APPLY CUSTOM MODIFICATIONS, PERFORM THEM IN THE FOLLOWING FILES:
#/var/www/vhosts/ssltest.bblhosted.com/conf/vhost.conf
#/var/www/vhosts/ssltest.bblhosted.com/conf/vhost_ssl.conf
そこで、/var/www/vhosts/ssltest.bblhosted.com/conf/vhost_ssl.conf
を作成し、それに1行追加しました。
SSLCertificateChainFile /usr/local/psa/var/certificates/cert-t8ReAO
その1行以外は何も追加する必要はありません。私の知る限り、他のすべての設定は、Pleskによって生成されたデフォルトのhttpd.includeファイルから引き続き取得されます。
ここで、Pleskにvhost_ssl.confファイルを探すように指示する必要があります。これは、デフォルトでは作成されていないためです。これを行うには、SSH経由でログインし、次のコマンドを実行します。
/usr/local/psa/admin/bin/httpdmng --reconfigure-all
これにより、Pleskはすべてのドメインのvhost.conf(およびvhost_ssl.conf)を探すようになります。必要に応じて、単一のドメインに対してのみ実行することもできます。
最後に、Apacheを再起動すると、SSLが機能します。
別のサブドメインを追加する場合は、ターミナルコマンドを実行してPleskに新しいドメインまたはサブドメインのvhost.confとvhost_ssl.confを検索させるなど、プロセス全体を再度実行する必要があることに注意してください。
証明書チェーンが完全でない可能性があります。 RapidSSL CA Bundle を追加する必要があるかもしれません。あなたの証明書に。
Apacheには、オプションSSLCertificateChainFile
があります。これを保存したパスに設定します RapidSSL CA Bundle 。
別のオプションは、チェーン証明書を次のように証明書に追加して、独自の証明書に追加することです。
cat mycert.pem RapidSSL_CA_bundle.pem >> mychainedcert.pem
これで問題が解決するはずです。
あなたは明らかにRapidSSLで証明書を購入しました。ただし、RapidSSLは、ブラウザが信頼するCAの1つではありません。ブラウザはGeoTrustを信頼し、GeoTrustはRapidSSLを信頼するため、これは問題ありません。これを証明する証明書をブラウザに表示するだけです。そのため、チェーンファイルを含める必要があります。
私は最近、まさにこのシナリオを構成しました。さらに確認する必要がありますが、次のようになります。
証明書の詳細を確認すると、次のようになります。
Nome DNS:* .bblhosted.com Nome DNS:bblhosted.com
AltDNSNameとしてbblhosted.comを取得しました。
ルートドメインに1つの証明書を、他のすべてのサブドメインに1つのワイルドカード証明書を用意することで、発生している動作を回避しました。
そうすれば、証明書のパターンマスクは、ブラウザがチェックする必要のあるすべての可能な方法で、指定されたURLと一致します。
TL; DR:2つの新しい証明書を取得します。1つはaltDnsName/CNとして「bblhosted.com」だけを使用し、もう1つは「* .bblhosted.com」を使用します。
編集: http://www.cacert.org の人たちが無料の証明書を実行することで、それが問題であるかどうかを確認できます。私は商用証明書を気にしませんでした、そして私はそれらを私の主要なssl証明書として持っています。唯一の面倒は、ほとんどのOSがルート証明書を出荷しないことです。そのため、自分でインストールする必要があります。
証明書には、発行者の証明書へのURLを含む特別なAuthority Information Access拡張子( RFC-328 )を含めることができます。ほとんどのブラウザは、AIA拡張機能を使用して、不足している中間証明書をダウンロードし、証明書チェーンを完成させることができます。ただし、一部のクライアント(モバイルブラウザ、OpenSSL)はこの拡張機能をサポートしていないため、そのような証明書を信頼できないものとして報告します。
不完全な証明書チェーンの問題は、証明書から信頼されたルート証明書(この順序で排他的)にすべての証明書を連結することで手動で解決できます。問題。信頼されたルート証明書は、システムのルート証明書ストアにすでに含まれているため、そこにあるべきではないことに注意してください。
発行者から中間証明書をフェッチして、自分でそれらを連結できるはずです。ところで、私は手順を自動化するスクリプトを作成しました。それはAIA拡張機能をループして、正しくチェーンされた証明書の出力を生成します。 https://github.com/zakjan/cert-chain-resolver