Quando atualizamos nosso servidor de desenvolvimento Domino de 8.5.3 para 9, as conexões HTTPS do código Java para sites com o certificado GoDaddy pararam de funcionar. Conexões para servidores com certificado DigiCert funcionam bem. Isso acontece em agentes e XPages.
Aqui está um exemplo de código do XPage:
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
<xp:this.beforePageLoad>
<![CDATA[#{javascript:new java.net.URL("https://www.sslshopper.com/").openStream();]]>
</xp:this.beforePageLoad>
</xp:view>
Eu também tentei com UrlConnection
. Aqui está a exceção:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: 3659
com.ibm.jsse2.o.a(o.java:15)
com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:460)
com.ibm.jsse2.kb.a(kb.java:294)
com.ibm.jsse2.kb.a(kb.java:533)
com.ibm.jsse2.lb.a(lb.java:55)
com.ibm.jsse2.lb.a(lb.java:581)
com.ibm.jsse2.kb.s(kb.java:11)
com.ibm.jsse2.kb.a(kb.java:394)
com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:44)
com.ibm.jsse2.SSLSocketImpl.h(SSLSocketImpl.java:496)
com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:528)
com.ibm.jsse2.SSLSocketImpl.startHandshake(SSLSocketImpl.java:505)
com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:83)
com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:31)
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1184)
com.ibm.net.ssl.www2.protocol.https.b.getInputStream(b.java:40)
java.net.URL.openStream(URL.java:1022)
...
java.security.cert.CertificateException: 3659
com.ibm.domino.napi.ssl.DominoX509TrustManager.checkServerTrusted(DominoX509TrustManager.java:98)
com.ibm.jsse2.lb.a(lb.java:468)
com.ibm.jsse2.lb.a(lb.java:581)
com.ibm.jsse2.kb.s(kb.java:11)
com.ibm.jsse2.kb.a(kb.java:394)
com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:44)
com.ibm.jsse2.SSLSocketImpl.h(SSLSocketImpl.java:496)
com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:528)
com.ibm.jsse2.SSLSocketImpl.startHandshake(SSLSocketImpl.java:505)
com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:83)
com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:31)
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1184)
com.ibm.net.ssl.www2.protocol.https.b.getInputStream(b.java:40)
java.net.URL.openStream(URL.java:1022)
Eu importei os certificados GoDaddy para o armazenamento de chaves domino_path \ jvm \ lib \ security \ cacerts de acordo com estas instruções:
link
Mas isso não ajudou e eu também importei gd-class2-root.crt sem resultados. Eu também tentei renomear o arquivo cacerts e copiar aquele do servidor 8.5.3, mas também não ajudou. Eu iniciei o servidor HTTP e Domino depois dessas mudanças.
Claro que eu poderia usar o código Java que não se importa com certificados, mas acredito que não seja uma ótima solução para produção. Também temos código em muitos lugares diferentes (incluindo JARs) que fazem conexão HTTPS a este URL.
Atualização 1
Isso está em error-log-0.xml :
Certificate with subject CN=www.sslshopper.com, OU=Domain Control
Validated, O=www.sslshopper.com, issued by SERIALNUMBER=07969287,
CN=Go Daddy Secure Certification Authority,
OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.",
L=Scottsdale, ST=Arizona, C=US, is not trusted. Validation failed with
error 3659.
Eu acho que esta mensagem é bem clara. Também notei que System.getProperty("javax.net.ssl.trustStore")
retorna nulo, mas isso também acontece no servidor 8.5.3, onde isso funciona. Eu tentei definir o trustStore com setProperty
, mas o erro ainda é o mesmo.
Atualização 2
Funciona com código do Simon que usa createSocket
. Mas todo o nosso código usa java.net.URL
, UrlConnection
, HttpsUrlConnection
ou Apache HTTP Client. Alguns destes são fornecidos por terceiros como um JAR. Nós não podemos mudar todos aqueles para usar createSocket
.
Alguma ideia? Obrigado.