JSSE de Java proporciona dos TrustManagers diferentes:
- PKIX y
- SunX509 Intenté averiguar cuáles son las diferencias entre ambos, pero no pude encontrar ninguna en la documentación. ¿Puedes decirme la diferencia entre ambos TrustManagers?
Desde un punto de vista de uso básico, la diferencia es cómo se inicializan los TrustManagers resultantes, según Documentación de proveedores de Oracle de la arquitectura de criptografía Java para JDK 8
SunX509 : Una fábrica para instancias de X509ExtendedTrustManager que valida las cadenas de certificados de acuerdo con las reglas definidas por el grupo de trabajo IETF PKIX en RFC 3280 o su sucesor. Este TrustManagerFactory admite la inicialización utilizando un objeto Keystore, pero actualmente no admite la inicialización utilizando la clase javax.net.ssl.ManagerFactoryParameters .
PKIX : una fábrica para instancias de X509ExtendedTrustManager que validan las cadenas de certificados de acuerdo con las reglas definidas por el grupo de trabajo IETF PKIX en RFC 3280 o su sucesor. Esta TrustManagerFactory actualmente admite la inicialización utilizando un objeto KeyStore o javax.net.ssl.CertPathTrustManagerParameters .
Una cosa a tener en cuenta es, Java Cryptography Architecture Algoritmo estándar Nombre Documentación para JDK 8 , solo enumera PKIX como un algoritmo de TrustManagerFactory. SunX509 se deja en la documentación del proveedor porque es una implementación proporcionada por el proveedor, mientras que PKIX es proporcionada por todos los proveedores. Por ejemplo, si está ejecutando en IBM JRE, no hay SunX509 , sino IbmX509 . Consecutivamente, si codificamos "SunX509" en nuestra aplicación, recibiremos un NoSuchAlgorithmException . Por lo tanto, para la portabilidad, es mejor usar el algoritmo predeterminado de la plataforma como se muestra a continuación, ya que ambos funcionarán para los archivos de Keystone (actualmente, tanto el Sun como el JRE de IBM están predeterminados para PKIX).
TrustManagerFactory trustManagerFactory=
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
Si bien ambas fábricas se pueden inicializar con un parámetro KeyStore , el uso de PKIX permite alternativas, que se pueden configurar utilizando parámetros de inicialización. Un ejemplo interesante es usar LDAPCertStoreParameters para usar un almacén de certificados LDAP en lugar de un archivo de almacén de claves (un ejemplo here ).
Hay un problema en el sistema de seguimiento de errores de Oracle que agrega un poco más de claridad a esta pregunta
De la edición:
El administrador de confianza SunX509 se implementa en SimpleValidator.java solo para uso de compatibilidad, y no se agregarán nuevas funciones. El administrador de confianza PKIX es el administrador de confianza predeterminado y recomendado.
En la implementación del validador / administrador de confianza SunX509, solíamos verificar solo las extensiones críticas conocidas. Las extensiones admitidas están en la lista blanca en sun / security / validator / EndEntityChecker.java. Si una extensión es crítica y no está presente en la lista blanca, el certificado no puede pasar la validación de SunX509. El validador / administrador de confianza PKIX es compatible con extensiones y funciones más ricas.
En la documentación de los proveedores de Oracle, actualmente dice:
"SunX509: Una fábrica para instancias de X509ExtendedTrustManager que validan cadenas de certificados de acuerdo con las reglas definidas por el grupo de trabajo IETF PKIX en RFC 3280 o su sucesor".
Esto es engañoso, ya que no admite todas las extensiones requeridas (y probablemente otros requisitos) de RFC 3280, y no es estrictamente compatible con RFC 3280 y puede que no sea compatible con todas las extensiones requeridas. También podemos desalentar su uso. Y debemos actualizar las referencias RFC 3280 a 5280 a lo largo de este documento.