Настройка: WL 9.2 + Джерси 1.1.5.1 на WL's Jrockit.
Я выбрал Jersey 1.1.5.1, потому что более новые версии требуют Java 6, я считаю.
Weblogic EJB действует как клиент REST и продолжает получать эту ошибку:
ClientHandlerException: javax.net.ssl.SSLKeyException: [Security: 090477] Цепочка сертификатов, полученная от svcpoint.restprovider.com - xx.xxx.xxx.xx не является доверенной, что вызывает сбой рукопожатия SSL.
Поскольку это просто реализация POC, Weblogic настроен с различными флагами, чтобы игнорировать проверку сертификата, просто чтобы устранить эту ошибку:
-Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.SSL.enforceConstraints=off -Dweblogic.webservice.client.ssl.strictcertchecking=false
Кроме того, конфигурация конфигурации Джерси включает в себя этот бит:
SSLContext ctx = SSLContext.getInstance("SSL");
HTTPSProperties prop = new HTTPSProperties(
new HostnameVerifier () {
public boolean verify(String hostname, SSLSession session) {
System.out.println("\n\nFAKE_Verifier: " + hostname+"\n\n");
return true;
}
}, ctx);
config.getProperties().put(HTTPSProperties.PROPERTY_HTTPS_PROPERTIES, prop);
Наконец, единственный сервер WL, технически admin srv, был настроен в консоли администратора SSL. Расширенные настройки, чтобы не использовать проверку имени хоста.
Теперь я почти уверен, что мои поддельные настройки валидатора для Джерси на самом деле не задействованы, так как я вижу эту ошибку из отладки SSL:
<SecuritySSL> <000000> <weblogic user specified trustmanager validation status 16>
<Security> <BEA-090477> <Certificate chain received from svcpoint.restprovider.com - xx.xxx.xxx.xx was not trusted causing SSL handshake failure.>
<SecuritySSL> <000000> <Validation error = 16>
<SecuritySSL> <000000> <Certificate chain is untrusted>
<SecuritySSL> <000000> <SSLTrustValidator returns: 16>
<SecuritySSL> <000000> <Trust status (16): CERT_CHAIN_UNTRUSTED>
<SecuritySSL> <000000> <NEW ALERT with Severity: FATAL, Type: 42
java.lang.Exception: New alert stack
at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)
Я гуглил и смотрел другие подобные проблемы здесь на SO, но я, вероятно, что-то упустил. Кроме того, насколько я могу судить, сертификат кажется действительным, показывая, что он для CN = *. Restprovider.com, срок действия которого истекает в ноябре 2011 года.