Я делаю 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)

Есть некоторые темы, затрагивающие эту (или аналогичную) проблему, когда люди предлагают воссоздать сертификаты или трастовые хранилища с различными параметрами. Я бы предпочел не идти по этому пути, поскольку недавно я безуспешно пытался создать больше таких хранилищ ключей и доверенных сертификатов для разных учетных записей одного и того же веб-сервиса.

Поскольку мы использовали эти старые (keystore и truststore) в работе с Java 6, я бы хотел сохранить их, если это вообще возможно.

Кажется, проблема может быть вызвана тем, что Java 7 более жестко проверяет цепочку сертификатов доверенного хранилища?

Можно ли установить некоторые флаги, чтобы ослабить проверку, заставить ее вести себя как Java 6?

В чем я не уверен на 100%, так это в том, как интерпретировать сообщение об ошибке: я думаю, оно говорит мне, что это моя машина (а не сервер удаления), которая не удовлетворена безопасностью удаленной машины. Это верно?

Любая помощь / идеи приветствуются!

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

Как и предполагалось, добавили PEM (с цепочкой), экспортированный из Firefox при доступе к URL-адресу WS, в хранилище доверенных сертификатов. Это не делает его рукопожатием, но немного меняет неудачу.

***
%% 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, и соединение происходит где-то глубоко внутри их кода, поэтому я не могу его затронуть.