web-dev-qa-db-ja.com

Java 7（クライアントとして機能））で動作するキーストアとトラストストアでのSSLハンドシェイクの失敗Java 6

私はJBoss AS 5.1から7.4、およびJava 6から7への移行を行っており、ハンドシェイクに失敗します。

キーストアとトラストストアは、Java 6。

問題を絞り込むためにいくつかのテストを作成しました。これは間違いなくJBossではなく、Java 7.です。

SSLロギングをオンにすると、次のようになります。

17:44:30,041 INFO  [stdout] (http-/192.168.147.20:8080-120) %% Invalidated:  [Session-2, SSL_RSA_WITH_RC4_128_SHA]
17:44:30,041 INFO  [stdout] (http-/192.168.147.20:8080-120) http-/192.168.147.20:8080-120, SEND TLSv1 ALERT:  fatal, description = certificate_unknown
17:44:30,041 INFO  [stdout] (http-/192.168.147.20:8080-120) http-/192.168.147.20:8080-120, WRITE: TLSv1 Alert, length = 2
17:44:30,041 INFO  [stdout] (http-/192.168.147.20:8080-120) http-/192.168.147.20:8080-120, called closeSocket()
17:44:30,041 INFO  [stdout] (http-/192.168.147.20:8080-120) http-/192.168.147.20:8080-120, handling exception: javax.net.ssl.SSLHandshakeException: Sun.security.validator.ValidatorException: PKIX path validation failed: Java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
17:44:30,041 INFO  [stdout] (http-/192.168.147.20:8080-120) http-/192.168.147.20:8080-120, called close()
17:44:30,042 INFO  [stdout] (http-/192.168.147.20:8080-120) http-/192.168.147.20:8080-120, called closeInternal(true)

この（または同様の）問題に関連するいくつかのスレッドがあり、人々はさまざまなパラメーターで証明書またはトラストストアを再作成することを提案しています。同じ経路をたどらない方がいいです。最近成功しなかったため、同じWebサービスの異なるアカウントに対して、このようなキーストアとトラストストアをさらに作成しようとしました。

これらの古い（キーストアとトラストストア）を本番環境でJava 6）で使用してきたので、可能な限りそれらを保持したいと思います。

問題は、トラストストア証明書チェーンのチェックに関してJava 7がより厳格であることが原因である可能性がありますか？

いくつかのフラグを設定してチェックを緩和し、Java 6のように動作させることができますか？

100％確実ではないのは、失敗メッセージをどのように解釈するかです。リモートマシンが安全であることに満足していないのは、自分のマシン（削除サーバーではない）であることを示していると思います。あれは正しいですか？

どんな助け/アイデアも感謝します！

================================================== ========

提案されているように、WSEM URLにアクセスしたときにfirefoxからエクスポートされたPEM（チェーン付き）をトラストストアに追加しました。これはハンドシェイクにはなりませんが、失敗をわずかに変更します。

***
%% Invalidated:  [Session-1, SSL_RSA_WITH_RC4_128_SHA]
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
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
    at Sun.security.ssl.Alerts.getSSLException(Alerts.Java:192)
    at Sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.Java:1884)
    at Sun.security.ssl.Handshaker.fatalSE(Handshaker.Java:276)
    at Sun.security.ssl.Handshaker.fatalSE(Handshaker.Java:270)
    at Sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.Java:1341)
    at Sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.Java:153)
    at Sun.security.ssl.Handshaker.processLoop(Handshaker.Java:868)
    at Sun.security.ssl.Handshaker.process_record(Handshaker.Java:804)
    at Sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.Java:1016)
    at Sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.Java:1312)
    at Sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.Java:1339)

================================================== ============

また、他のスレッドで提案されているように、証明書チェーンを検証しないTrustManagerを使用する別のテストを作成し、これを元のトラストストアで実行しました。

このテストは接続できるため、私のマシンのリモートマシンの検証が唯一の問題であり、キーストアが正常であることを示しています。

ただし、Sun RPC libを使用しているため、実際のWebサービスクライアントではこのアプローチを使用できません。接続はコードの内部のどこかで発生するため、触れられません。

javasslkeystorehandshaketruststore
10
stupor-mundi

まず、はい、例外はJavaお使いのマシンのSSLモジュールはサーバーから受信したID（証明書）の証明を信頼しないことを示しています。

はい、Java 7はより厳密なチェックを行います。もっと多くのチェックがあるかもしれませんが、私が確信しているのは、子証明書の有効期間が親の後に終了できないことです/ CA証明書（または前に開始しますが、実際には発生しません。）を参照してください PKIXパスは、Windows環境のトラストアンカーエラーとチェーンしません これはバグであり、修正される予定です。

確認方法：サーバーがウェブサーバーの場合、ブラウザを使用して任意の（無害な）ページにアクセスし、それを使用して証明書チェーンを確認できます。それ以外の場合は、openssl s_client -connect $Host:443 -showcertsを実行し、接続したらEOF（Unix ^ D、Windows ^ Z）と入力してから、各----BEGIN CERT... to -----END CERT...ブロックを別のファイルを作成し、それぞれに対してopenssl x509 -noout -subject -issuer -startdate -enddateを順番に実行します。

修正するには：これが問題である場合、すべての証明書チェックをオフにする（したがって、SSLのセキュリティの一部が失われる）ことを除いて、直接オフにする方法はないようですが、サーバーエンティティ証明書をJavaはチェーンを検証しないため、トラストストアが機能するはずです（既存のものを削除する必要はありません。まだ使用されていないエイリアスを使用するだけです）。 。

11
dave_thompson_085