JSSE di Java fornisce due diversi TrustManager:
- PKIX e
- SunX509 Ho cercato di scoprire quali sono le differenze tra i due, ma non ho trovato alcun documento nella documentazione. Puoi dirmi la differenza tra entrambi i TrustManager?
Da un punto di vista dell'utilizzo di base, la differenza è il modo in cui i TrustManager risultanti vengono inizializzati, come per Architettura di crittografia Java Documentazione di Oracle Provider per JDK 8
SunX509: A factory for X509ExtendedTrustManager instances that validate certificate chains according to the rules defined by the IETF PKIX working group in RFC 3280 or its successor. This TrustManagerFactory supports initialization using a Keystore object, but does not currently support initialization using the class javax.net.ssl.ManagerFactoryParameters.
PKIX: A factory for X509ExtendedTrustManager instances that validate certificate chains according to the rules defined by the IETF PKIX working group in RFC 3280 or its successor. This TrustManagerFactory currently supports initialization using a KeyStore object or javax.net.ssl.CertPathTrustManagerParameters.
Una cosa da notare è Documentazione del nome dell'algoritmo standard di architettura di crittografia Java per JDK 8 , elenca solo PKIX come algoritmo TrustManagerFactory. SunX509 è lasciato alla documentazione del fornitore poiché è un'implementazione fornita dal fornitore, mentre PKIX è fornito da tutti i fornitori. Ad esempio, se stai utilizzando IBM JRE, non c'è SunX509 , ma IbmX509 . Consecutivamente, se abbiamo hardcode "SunX509" nella nostra applicazione, riceveremo NoSuchAlgorithmException . Quindi, per la portabilità, è meglio utilizzare l'algoritmo di default della piattaforma come di seguito, in quanto entrambi funzioneranno con i file keystone (attualmente sia Sun che IBM JRE sono predefiniti su PKIX).
TrustManagerFactory trustManagerFactory=
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
Sebbene entrambe le fabbriche possano essere inizializzate con un parametro KeyStore , l'uso di PKIX consente alternative, che possono essere configurate utilizzando i parametri di inizializzazione. Un esempio interessante è l'utilizzo di LDAPCertStoreParameters per l'utilizzo di un archivio di certificati LDAP anziché di un file di archivio di chiavi (un esempio qui ).
C'è un problema nel sistema di tracciamento dei bug di Oracle che aggiunge un po 'più di chiarezza a questa domanda
Dal problema:
Il gestore di attendibilità SunX509 è implementato in SimpleValidator.java solo per uso con compatibilità e non verranno aggiunte nuove funzionalità. Il gestore sicuro PKIX è il gestore di attendibilità predefinito e consigliato.
Nell'implementazione del validatore / trust manager SunX509, eravamo soliti controllare solo le estensioni critiche conosciute. Le estensioni supportate sono elencate in bianco in sun / security / validator / EndEntityChecker.java. Se un'estensione è critica e non presente nell'elenco bianco, il certificato non può superare la convalida SunX509. Il validatore / trust manager PKIX supporta estensioni e funzionalità più ricche.
Nella documentazione di Oracle Provider, attualmente dice:
"SunX509: una factory per le istanze X509ExtendedTrustManager che convalida le catene di certificati in base alle regole definite dal gruppo di lavoro IETF PKIX in RFC 3280 o nel suo successore."
Ciò è fuorviante in quanto non supporta tutte le estensioni richieste (e probabilmente altri requisiti) di RFC 3280 e non è strettamente conforme a RFC 3280 e potrebbe non supportare tutte le estensioni richieste. Possiamo anche scoraggiare il suo uso. E dovremmo aggiornare i riferimenti RFC 3280 a 5280 in tutto questo documento.