7

私は他の人と同じ問題にぶつかると思って、多くの同様の問題と潜在的な解決策を経験してきましたが、運がありません.

私が使用しているトラスト ストアは、Java 1.6.0 JRE (ビルド 1.6.0_20-b02... これが問題の原因でしょうか?) の lib/security にある cacerts です。私もjssecacertsで試しました。

InstallCert を使用して (投稿された他の同様の問題ごとに)、証明書が実際にインストールされ、有効であることを確認できます (正しいデータが表示されていることを確認するために、証明書を削除し、再インポートしました):

java InstallCert <my host name>
Loading KeyStore jssecacerts...
Opening connection to <my host name>:443...
Starting SSL handshake...
No errors, certificate is already trusted

keytool と Portecle をチェックインし、証明書を再インポートすると (-showcert を使用して openssl から生成し、ブラウザーからエクスポートして scp を実行するなど)、「この別のエイリアスの下に既に存在する」タイプのメッセージ。そのため、証明書がツールに取り込まれる方法に問題はないようです。

コードで明示的な trustStore パスを強制しても違いはありません。すべての場合で、(javax.net.debug の setProperty を "all" に設定して) デバッグをオンにすると、次のようになります。

main, SEND TLSv1 ALERT:  fatal, description = certificate_unknown
main, WRITE: TLSv1 Alert, length = 2 [Raw write]: length = 7 0000: 15
03 01 00 02 02 2E                               ....... main, called
closeSocket() main, handling exception:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target

残念ながら、独自の TrustManager を実装してチェックを無効にすることはできません。実際にチェックする必要があります。

ホストから取得した証明書にはいくつかの拡張子 (正確には 9 つ) が含まれているため、それらが何らかの形でこの問題の一部であるかどうか疑問に思います。

他に何を確認/試すことができますか? 別の JRE バージョンに切り替えますか?

4

3 に答える 3

0

私の推測では、次のいずれかが発生したと考えられます。

a) Web サーバーでコードを実行します。多くの場合、独自のトラスト ストアをcacerts使用します。コードの実行時にそれが使用されていることを本当に確信していますか?

b) デフォルトでは、Java は CRL をダウンロードして解釈することにより、証明書の有効性を確認しようとします。プロキシの背後にいる場合、ダウンロードは失敗し、結果として PKIX チェック全体が失敗します。

于 2012-06-18T22:12:18.773 に答える
0

SSL デバッグ トレースは、手動でロードしない限り、どの cacerts ファイルを使用しているかを示します。明らかに、あなたは自分が思っているものを使用していません。

于 2012-06-18T22:49:13.547 に答える