Java7 Rifiuto di fidarsi del certificato nell'archivio fiduciario

Question

Ho un problema strano: un fornitore utilizza SSLS3 TLS con un certificato autofirmato di client e server. Questo non è stato un problema con Java1.5 e Java1.6: è sufficiente importare il certificato client e la chiave privata in un keystore e il certificato pubblico del server nel truststore. Tutto funziona bene. Tuttavia con Java7 il certificato del server non viene considerato affidabile anche se viene utilizzato lo stesso truststore. Ho provato Windows e Red Hat sia con Java7 (versioni 1.7.03, 04 e 05, x86 e x64) senza successo.

Ho ricreato il keystore/truststore da zero e contengono solo questi certificati. Le proprietà di sistema appropriate sono state impostate (javax.net.ssl.keyStore, javax.net.ssl.trustStore) e l'aspetto chiave è che esattamente lo stesso codice e la stessa configurazione funzionano perfettamente in JDK5/6.

Sono in perdita - Non riesco a trovare alcun riferimento al controllo aggiuntivo, ma avrei pensato che il fatto che il certificato si trovasse nel truststore dovrebbe significare che è affidabile, indipendentemente dal fatto che sia autofirmato.

Qualsiasi aiuto apprezzato. annunci

traccia Eccezione:

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 in cui il debug di ssl non sta cercando di convalidare il certificato del server:

*** 
%% 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

in realtà ho avuto un problema in qualche modo simile, in cui un'applicazione Tomcat si fida del ca cert nel truststore quando si utilizza Java 1.6 e lo si rifiuta con java 1.7. Dopo aver aggiunto keyUsage al mio certificato ca, funziona (dopo aver letto un bug report, JDK-7018897 : CertPath validation cannot handle self-signed cert with bad KeyUsage).

Quello che ho fatto (Ubuntu 12.04 x64):

1. Modifica /etc/ssl/openssl.cnf e decommentare la linea keyUsage in v3_ca sezione.

2. Creare nuovo cert CA da vecchio con keyUsage incluso con il comando:

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

3. Elimina vecchia chiave CA da truststore e inserire quello nuovo.

Answer 2

Ho anche riscontrato questa situazione quando si trattava di JDK 1.7. Se il comando REQ viene richiamato con l'opzione -x509, è meglio togliere il commento keyUsage linea in sezione v3_ca e generare il CA di nuovo con (vedi 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 

E se si utilizza il certificato CA generata di firmare altri certificati fare in modo che anche togliendo il commento alla voce basicConstraints = CA: true e il valore impostato a true