Fra et grunnleggende synspunkt er forskjellen hvordan resulterende TrustManagers initialiseres, i henhold til Java Cryptography Architecture Oracle Providers Documentation for JDK 8

SunX509 : En fabrikk for forekomster av X509ExtendedTrustManager som validerer sertifikatkjeder i henhold til reglene definert av IETF PKIX-arbeidsgruppen i RFC 3280 eller dens etterfølger. Denne TrustManagerFactory støtter initialisering ved hjelp av et Keystore-objekt, men støtter foreløpig ikke initialisering ved bruk av klassen javax.net.ssl.ManagerFactoryParameters .

PKIX : A fabrikk for X509ExtendedTrustManager-forekomster som validerer sertifikatkjeder i henhold til reglene definert av IETF PKIX-arbeidsgruppen i RFC 3280 eller dens etterfølger. Denne TrustManagerFactory støtter for øyeblikket initialisering ved hjelp av et KeyStore-objekt eller javax.net.ssl.CertPathTrustManagerParameters .

En ting å merke seg er, Java Cryptography Architecture Standard Algorithm Navnedokumentasjon for JDK 8, viser bare PKIX som en TrustManagerFactory-algoritme. SunX509 overlates til leverandørens dokumentasjon fordi det er implementering fra leverandører, mens PKIX leveres av alle leverandører. Hvis du for eksempel kjører på IBM JRE, er det ingen SunX509 , men IbmX509 . Hvis vi hardkoder "SunX509" i applikasjonen vår, vil vi motta en NoSuchAlgorithmException . Derfor, for bærbarhet, er det best å bruke plattformens standardalgoritme som nedenfor, da begge fungerer for keystone-filer (for øyeblikket er både Sun og IBM JREs som standard PKIX).

  TrustManagerFactory trustManagerFactory = TrustManagerFactory. getInstance (TrustManagerFactory.getDefaultAlgorithm ());  

Mens begge fabrikkene kan initialiseres med en KeyStore -parameter, bruker PKIX muligheter for alternativer som kan konfigureres ved hjelp av initialiseringsparametere. Et interessant eksempel er å bruke LDAPCertStoreParameters for å bruke et LDAP-sertifikatlager i stedet for en keystore-fil (et eksempel her).

Det er et problem i Oracles feilsporingssystem som gir dette spørsmålet litt mer klarhet

https://bugs.openjdk.java.net/browse/JDK-8169745

Fra problemet:

SunX509 trust manager er implementert i SimpleValidator.java kun for kompatibilitetsbruk, og ingen nye funksjoner blir lagt til. PKIX trust manager er standard og anbefalt trust manager.

I implementeringen av SunX509 validator / trust manager pleide vi bare å sjekke kjente kritiske utvidelser. De støttede utvidelsene er hvite oppført i sun / security / validator / EndEntityChecker.java. Hvis en utvidelse er kritisk og ikke finnes i den hvite listen, kan ikke sertifikatet bestå SunX509-valideringen. PKIX validator / trust manager støtter flere rike utvidelser og funksjoner.

I Oracle Providers-dokumentasjonen står det for øyeblikket:

"SunX509: En fabrikk for X509ExtendedTrustManager-forekomster som validerer sertifikatkjeder i henhold til reglene definert av IETF PKIX-arbeidsgruppen i RFC 3280 eller dens etterfølger. "

Dette er villedende siden det ikke støtter alle nødvendige utvidelser (og sannsynligvis andre krav) til RFC 3280, og det er ikke strengt i samsvar med RFC 3280 og støtter kanskje ikke alle nødvendige utvidelser. Vi kan også fraråde bruken. Og vi bør oppdatere RFC 3280-referansene til 5280 i hele dette dokumentet.