Nuestro equipo especializado despúes de varios días de investigación y recopilar de datos, dimos con la solución, deseamos que resulte de gran utilidad para tu proyecto.
Solución:
Desde un punto de vista de uso básico, la diferencia es cómo se inicializan los TrustManagers resultantes, según la Documentación de proveedores de Oracle de arquitectura de criptografía Java para JDK 8
SolX509: Una fábrica para instancias X509ExtendedTrustManager que validan cadenas de certificados según las reglas definidas por el grupo de trabajo IETF PKIX en RFC 3280 o su sucesor. Este TrustManagerFactory admite la inicialización mediante un objeto Keystore, pero actualmente no admite la inicialización mediante la clase javax.net.ssl.ManagerFactoryParameters.
PKIX: Una fábrica para instancias X509ExtendedTrustManager que validan cadenas de certificados según las reglas definidas por el grupo de trabajo IETF PKIX en RFC 3280 o su sucesor. Esta fábrica TrustManager actualmente admite la inicialización mediante un objeto KeyStore o javax.net.ssl.CertPathTrustManagerParameters.
Una cosa a tener en cuenta es que la documentación del nombre del algoritmo estándar de la arquitectura criptográfica de Java para JDK 8 solo enumera PKIX como un algoritmo TrustManagerFactory. SunX509 se deja para la documentación del proveedor porque es una implementación proporcionada por el proveedor, mientras que todos los proveedores proporcionan PKIX. Por ejemplo, si está ejecutando IBM JRE, no hay SolX509, pero 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 archivos keystone (actualmente, tanto Sun como IBM JRE tienen el valor predeterminado PKIX).
TrustManagerFactory trustManagerFactory=
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
Si bien ambas fábricas se pueden inicializar con un KeyStore El uso de PKIX permite alternativas, que se pueden configurar mediante parámetros de inicialización. Un ejemplo interesante es el uso LDAPCertStoreParameters para usar un almacén de certificados LDAP en lugar de un archivo de almacén de claves (un ejemplo aquí).
Hay un problema en el sistema de seguimiento de errores de Oracle que agrega un poco más de claridad a esta pregunta.
https://bugs.openjdk.java.net/browse/JDK-8169745
Del problema:
El administrador de confianza SunX509 se implementa en SimpleValidator.java solo para compatibilidad y no se agregarán nuevas características. El administrador de confianza PKIX es el administrador de confianza predeterminado y recomendado.
En la implementación del administrador de confianza/validador SunX509, solíamos verificar solo las extensiones críticas conocidas. Las extensiones compatibles se incluyen 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 SunX509. El validador/administrador de confianza PKIX admite extensiones y funciones más completas.
En la documentación de proveedores de Oracle, actualmente dice:
“SunX509: una fábrica para instancias 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 cumple estrictamente con RFC 3280 y es posible que no admita todas las extensiones requeridas. También podemos desaconsejar su uso. Y debemos actualizar las referencias RFC 3280 a 5280 a lo largo de este documento.