it-swarm.com.de

Was ist der Unterschied zwischen TrustManager PKIX und SunX509?

Javas JSSE bietet zwei verschiedene TrustManager:

  • PKIX und
  • SunX509 Ich habe versucht herauszufinden, was die Unterschiede zwischen beiden sind, konnte aber keine in der Dokumentation finden. Können Sie mir den Unterschied zwischen beiden TrustManagern erklären?
13
qbi

Unter dem Gesichtspunkt der grundlegenden Verwendung besteht der Unterschied darin, wie die resultierenden TrustManager gemäß Java Cryptography Architecture Oracle Providers Documentation für JDK 8 initialisiert werden

SunX509: Eine Factory für X509ExtendedTrustManager-Instanzen, die Zertifikatketten gemäß den von der IETF PKIX-Arbeitsgruppe in RFC 3280 oder ihrem Nachfolger definierten Regeln validieren. Diese TrustManagerFactory unterstützt die Initialisierung mit einem Keystore-Objekt, unterstützt derzeit jedoch nicht die Initialisierung mit der Klasse javax.net.ssl.ManagerFactoryParameters .

[~ # ~] pkix [~ # ~]: Eine Factory für X509ExtendedTrustManager-Instanzen, die Zertifikatketten gemäß den von der IETF PKIX-Arbeitsgruppe in RFC 3280 oder ihrem Nachfolger definierten Regeln validieren. Diese TrustManagerFactory unterstützt derzeit die Initialisierung mit einem KeyStore-Objekt oder javax.net.ssl.CertPathTrustManagerParameters .

Zu beachten ist, dass Java Cryptography Architecture Standardalgorithmus Name Documentation für JDK 8 PKIX nur als TrustManagerFactory-Algorithmus auflistet. SunX509 wird der Dokumentation des Anbieters überlassen, da es sich um eine vom Anbieter bereitgestellte Implementierung handelt, während PKIX von allen Anbietern bereitgestellt wird. Wenn Sie beispielsweise mit IBM JRE arbeiten, gibt es kein SunX509 , sondern IbmX509 . Wenn wir in unserer Anwendung "SunX509" fest codieren, erhalten wir nacheinander ein NoSuchAlgorithmException. Aus Gründen der Portabilität ist es daher am besten, den folgenden Plattform-Standardalgorithmus zu verwenden, da beide für Keystone-Dateien funktionieren (derzeit sind sowohl Sun- als auch IBM-JREs standardmäßig PKIX).

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

Während beide Fabriken mit einem KeyStore -Parameter initialisiert werden können, ermöglicht die Verwendung von PKIX Alternativen, die mithilfe von Initialisierungsparametern konfiguriert werden können. Ein interessantes Beispiel ist die Verwendung von LDAPCertStoreParameters für die Verwendung eines LDAP-Zertifikatspeichers anstelle einer Keystore-Datei (ein Beispiel hier ).

15
Kurtcebe Eroglu

Es gibt ein Problem im Bug-Tracking-System von Oracle, das dieser Frage etwas mehr Klarheit verleiht

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

Aus der Ausgabe:

Der SunX509-Vertrauensmanager ist nur aus Kompatibilitätsgründen in SimpleValidator.Java implementiert, und es werden keine neuen Funktionen hinzugefügt. Der PKIX-Vertrauensmanager ist der Standard- und empfohlene Vertrauensmanager.

In der Implementierung von SunX509 Validator/Trust Manager haben wir nur bekannte kritische Erweiterungen überprüft. Die unterstützten Erweiterungen sind in Sun/security/validator/EndEntityChecker.Java auf der weißen Liste aufgeführt. Wenn eine Erweiterung kritisch ist und nicht in der Whitelist enthalten ist, kann das Zertifikat die SunX509-Validierung nicht bestehen. Der PKIX-Validator/Trust Manager unterstützt umfangreichere Erweiterungen und Funktionen.

In der Dokumentation zu Oracle Providers heißt es derzeit:

"SunX509: Eine Factory für X509ExtendedTrustManager-Instanzen, die Zertifikatketten gemäß den von der IETF PKIX-Arbeitsgruppe in RFC 3280 oder ihrem Nachfolger definierten Regeln validieren."

Dies ist irreführend, da nicht alle erforderlichen Erweiterungen (und wahrscheinlich auch andere Anforderungen) von RFC 3280 unterstützt werden und es nicht strikt mit RFC 3280 kompatibel ist und möglicherweise nicht alle erforderlichen Erweiterungen unterstützt. Wir können auch von seiner Verwendung abraten. Und wir sollten die RFC 3280-Verweise in diesem Dokument auf 5280 aktualisieren.

3
George Stanchev