Java7 Negarse a confiar en el certificado en la tienda de confianza

Question

Tengo un problema extraño: un proveedor utiliza TLS SSLv3 con un certificado de cliente y servidor autofirmado. Esto no ha sido un problema con Java1.5 y Java1.6: simplemente importe el certificado del cliente y la clave privada en un almacén de claves y el certificado público del servidor en el almacén de confianza. Todo funciona bien. Sin embargo, con Java7 no se puede confiar en el certificado del servidor aunque se esté utilizando el mismo almacén de confianza. He probado Windows y Red Hat usando Java7 (versiones 1.7.03, 04 y 05, x86 y x64) sin éxito.

He vuelto a crear el almacén de claves/almacén de confianza desde cero y solo contienen estos certificados. Se han establecido las propiedades apropiadas del sistema (javax.net.ssl.keyStore, javax.net.ssl.trustStore) y el aspecto clave es que el mismo código y la misma configuración se ejecutan perfectamente en JDK5/6.

Estoy perdido: no puedo encontrar ninguna referencia a las comprobaciones adicionales, pero hubiera pensado que el hecho de que el certificado se encontrara en el almacén de confianza debería significar que es confiable independientemente de que esté auto firmado.

Cualquier ayuda apreciada. Anuncios

traza Excepción:

Exception in thread "main" 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 
sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors 
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) 
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1868) 
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:1338) 
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:154) 
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:998) 
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1294) 
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:685) 
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:111) 
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) 
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) 
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) 
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) 
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) 
at com.alltria.ypsilon.testing.TestSSL.main(TestSSL.java:65) 
Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors 
at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:350) 
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:249) 
at sun.security.validator.Validator.validate(Validator.java:260) 
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326) 
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231) 
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126) 
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1320) 
... 13 more 
Caused by: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors 
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:208) 
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:279) 
at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:345) 
... 19 more 
Java Result: 1 

La parte donde la depuración de SSL no está tratando de validar el certificado de servidor:

*** 
%% Invalidated: [Session-1, SSL_RSA_WITH_RC4_128_SHA] 
main, SEND SSLv3 ALERT: fatal, description = certificate_unknown 
main, WRITE: SSLv3 Alert, length = 2 
[Raw write]: length = 7 
0000: 15 03 00 00 02 02 2E        ....... 
main, called closeSocket() 
main, 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 
main, called close() 
main, called closeInternal(true) 

Answer 1

en realidad tenía un tema algo similar, cuando una aplicación Tomcat confiaría en el certificado de ca en el almacén de confianza cuando use Java 1.6 y lo rechace con Java 1.7. Después de agregar keyUsage a mi certificado ca, funciona (después de leer un informe de error, JDK-7018897 : CertPath validation cannot handle self-signed cert with bad KeyUsage).

Lo que he hecho (Ubuntu 12.04 x64):

1. Editar /etc/ssl/openssl.cnf y elimine keyUsage línea en v3_ca sección.

2. Crear nuevo certificado CA desde antiguo con keyUsage incluidos mediante el comando:

   openssl x509 -in oldca.pem -clrext -signkey oldca.key -extfile /etc/ssl/openssl.cnf -extensions v3_ca -out newca.pem 
   

3. Eliminar vieja llave del almacén de confianza CA e inserte el nuevo.

Answer 2

También he encontrado esta situación al tratar con JDK 1.7. Si REQ que se invoca con la opción -x509, es mejor eliminar el comentario keyUsage línea en sección v3_ca y generar la CA de nuevo con (ver http://wwwneu.secit.at/web/documentation/openssl/openssl_cnf.html)

openssl req -new -x509 -days 3650 -keyout ca.key -out ca.crt -config openssl.cnf -extensions v3_ca -batch 

Y si utiliza el certificado de CA generada para firmar otro certificado, asegúrese de que también se elimina el comentario de la partida basicConstraints = CA: verdadero y el valor se establece a true