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)

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

Поскольку мы использовали эти старые (хранилище ключей и доверенность) в производстве с 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, который не проверяет цепочки сертификатов, и запускал это с помощью моего оригинального магазина доверия.

Этот тест способен подключиться и, таким образом, показывает, что моя машина проверяет удаленный компьютер - единственная проблема и что мое хранилище ключей в порядке.

Однако я не могу использовать этот подход для нашего фактического клиента webservice, поскольку в нем используется Sun RPC lib, а соединение происходит где-то глубоко внутри их кода, поэтому я не могу его трогать.

Ответ 1