次の証明書チェーンを持つ証明書があります。Entrust-> My CA-> My Issuing CA-> My JBoss Certificate。これで、JBossインスタンスに証明書をインストールした場合、My Issuing CAがブラウザーで認識されないため、このインスタンスで実行しているアクセスページは信頼されていないように見えます。私のコンピューターには、Entrust署名機関の公開鍵があることがわかっています。ブラウザーが証明書チェーン全体を表示できるように証明書をインストールするにはどうすればよいですか?
私は、それが機能すると考えているすべての証明書の単一の.pemファイルを作成しました。それはしませんでした。誰かが私が間違っていることを説明できますか、これが可能であっても説明できますか?
中間証明書をpkcs12ファイルに追加する...
以下は、Webサーバーとメールサーバーで行う方法です。
まず、www-example-com.crt
は、Startcomによって署名されたWebサーバー証明書です。 Startcomは、ほとんどのブラウザーとモバイルデバイスで信頼できる無料のクラス1証明書を提供しているので、それらを使用します。証明書はPEM形式(----- BEGIN CERT -----
および----- END CERT -----
)です。
次に、www-example-com.crt
を開き、StartcomのClass 1 Intermediateを追加します。 Startcomの Index of/certs から中間体を取得します。これで、私のwww-example-com.crt
には、2つのPEMエンコードされたエンコードされた証明書が含まれています。
3番目に、IISで使用するPKCS12/PFXファイルを作成するために以下を実行します。
openssl pkcs12 -export -in www-example-com.crt -inkey www.example.key -out www-example-com.p12
あなたの場合、www-example-com.crt
には少なくとも3つのPEMエンコードされた証明書が含まれています。
----- BEGIN CERT -----
< My JBoss Certificate >
----- END CERT -----
----- BEGIN CERT -----
< My Issuing CA >
----- END CERT -----
----- BEGIN CERT -----
< My CA >
----- END CERT -----
チェーンの3番目の証明書-My CA
-はオプションです。クライアントがMy CA
をトラストアンカーとして使用している場合は必要ありません。クライアントがEntrust
をトラストアンカーとして使用している場合、それを含める必要があります。
cat
your www-example-com.crt
を実行し、[〜#〜] [[##〜]に複数の証明書がない場合、その後、続行しないでください。サーバー証明書にチェーンの検証に必要なすべての必要な中間証明書が含まれるまで、openssl pkcs12
を実行しないでください。
Entrust CA証明書を含めないでください。
EntrustがCAと直接署名することは疑わしい。おそらく中間体も使用します。したがって、証明書チェーンはおそらく次のようになります。
----- BEGIN CERT -----
< My JBoss Certificate >
----- END CERT -----
----- BEGIN CERT -----
< My Issuing CA >
----- END CERT -----
----- BEGIN CERT -----
< My CA >
----- END CERT -----
----- BEGIN CERT -----
< Entrust Intermediate >
----- END CERT -----
Entrustsは、CAおよび中間証明書を Entrust Root Certificates で提供します。あなたがURLを提供したり、持っているチェーンを見せたりしないので、私はあなたに必要なものを伝えることができません。しかし、私はそれが1つ以上になると推測しています:
OpenSSLの `s_clientを使用してチェーンをテストできます。今回は、Entrustの証明書を使用します。
echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect myserver:8443 \
-CAfile entrust-ca.pem
Entrust Root Certificates からentrust-ca.pem
を取得できます。実行して、どのエラーが発生するかを教えてください。または、URLをサーバーに投稿して、何が起こっているかを確認できるようにしてください。
次の証明書チェーンを持つ証明書があります。Entrust-> My CA-> My Issuing CA-> My JBoss Certificate ....
ここには2つの問題があると思います。 1つは副署されたCAで、2つ目は不完全なクライアントチェーンです。
まず、簡単な問題。サーバーは、エンドエンティティ(サーバー)証明書と中間証明書を送信して、チェーンを構築する必要があります。サーバーは「どのディレクトリ」問題を回避するために中間証明書を送信します。 「どのディレクトリ」は、PKIでよく知られている問題です。本質的に、クライアントは、欠落している中間証明書を取得するためにどこに行くべきかを知りません。
したがって、最初の解決策は、サーバーが以下を使用してチェーンを送信することです。
第二に、信頼できない発行者の問題があります。クライアントは、内部発行CAを信頼する必要があります。
したがって、2番目の解決策は、クライアントが内部CA(「My CA」)を信頼するようにすることです。この場合、トラストポイントは内部CAに根ざしているため、クライアントがEntrustを使用する必要はありません。
サーバーに「My CA」、「My Issuing CA」、および「My JBoss Certificate」を含むチェーンを送信させることができます。この場合、クライアントは「Entrust」を信頼する必要があります。
クライアントが「Entrust」または「My CA」を信頼していない場合、検証エラーが発生します。
私は、それが機能すると考えているすべての証明書の単一の.pemファイルを作成しました。それはしませんでした。誰かが私が間違っていることを説明できますか、これが可能であっても説明できますか?
この場合、何が起こっているかを確認するために、証明書を確認する必要があります。証明書を提供し、チェーンを使用するURLを投稿できますか?内部CA(「マイCA」)証明書をオンラインで投稿しますか?
OpenSSLのs_client
との接続をテストするための簡単で汚い方法を次に示します。
echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect myserver:8443 \
-CAfile my-issuing-ca.pem
OpenSSLはデフォルトで(ブラウザとは異なり)何も信頼しないため、-CAfile
で信頼アンカーを指定する必要があります。
そのコマンドは、次のようなもので終了するはずです。
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 37E5AF0EE1745AB2...
Session-ID-ctx:
Master-Key: 7B9F8A79D3CC3A41...
Key-Arg : None
Start Time: 1243051912
Timeout : 300 (sec)
Verify return code: 0 (ok)
OpenSSLコマンドの結果がOKの場合、問題はブラウザとトラストポイントにあります。