Entscheidungen über die Vertrauenswürdigkeit von X.509-Zertifikaten mit dem Trust-Manager treffen

Der Trust-Manager hat die Aufgabe, das vom Peer gesendete SSL-Zertifikat zu validieren. Zu diesem Zweck werden unter anderem die Signatur und das Verfallsdatum des Zertifikats überprüft. Ein JSSE-Trust-Manager (Java™ Secure Socket Extension) bestimmt während eines SSL-Handshake, ob der ferne Peer vertrauenswürdig ist.

WebSphere Application Server kann während einer SSL-Verbindung mehrere Trust-Manager aufrufen. Der Standard-Trust-Manager führt die standardmäßige Validierung von Zertifikaten durch. Eigene Trust-Manager-Plug-ins können angepasste Validierungsschritte, z. B. die Überprüfung des Hostnamens, durchführen. Weitere Informationen enthält der Artikel Beispiel: Eigenen Trust Manager für angepasste SSL-Vertrauensentscheidungen entwickeln.

Wenn in einer serverseitigen SSL-Konfiguration ein Trust-Manager konfiguriert ist, ruft der Server die Methode isClientTrustedauf. Ist in einer clientseitigen SSL-Konfiguration ein Trust-Manager konfiguriert, ruft der Client die Methode isServerTrusted auf. An diese Methoden wird die Peerzertifikatkette übergeben. Wenn der Trust-Manager den Peerinformationen nicht vertraut, kann er eine Ausnahme erzeugen, um den Handshake zu verhindern.

WebSphere Application Server stellt optional die Schnittstelle "com.ibm.wsspi.ssl.TrustManagerExtendedInfo" bereit, damit zusätzliche Informationen an den Trust-Manager übergeben werden können. Weitere Informationen hierzu finden Sie in der Dokumentation der Schnittstelle "com.ibm.wsspi.ssl.TrustManagerExtendedInfo".

IbmX509-Standard-Trust-Manager

Der IbmX509-Standard-Trust-Manager, der im folgenden Codebeispiel verwendet wird, baut durch die Standardzertifikatvalidierung Vertrauen auf.
<trustManagers xmi:id="TrustManager_1132357815717" name="IbmX509" provider="IBMJSSE2" 
algorithm="IbmX509" managementScope="ManagementScope_1132357815717"/>
Der Trust-Manager stellt ein Unterzeichnerzertifikat bereit, um das beim Handshake gesendete Peerzertifikat zu überprüfen. Die Unterzeichner, die zum Truststore für die SSL-Konfiguration hinzugefügt werden, müssen vertrauenswürdig sein. Falls Sie den Unterzeichnern nicht trauen oder keine Verbindungen zu Ihren Servern zulassen möchten, könnten Sie die Standardstammzertifikate von Zertifizierungsstellen entfernen. Sie könnten auch alle Zertifikate entfernen, wenn Sie deren Ursprung nicht prüfen können.

Standard-Trust-Manager IbmPKIX

Die Ersetzung des IbmX509-Trust-Managers durch den IbmPKIX-Standard-Trust-Manager ist im folgenden Codebeispiel gezeigt:
<trustManagers xmi:id="TrustManager_1132357815719" name="IbmPKIX" provider="IBMJSSE2" 
algorithm="IbmPKIX" trustManagerClass="" managementScope="ManagementScope_1132357815717">
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_1132357815717" 
name="com.ibm.security.enableCRLDP" value="true" type="boolean"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_1132357815718" 
name="com.ibm.jsse2.checkRevocation" value="true" type="boolean"/>
  </trustManagers>

<trustManagers xmi:id="TrustManager_managementNode_2" name="IbmPKIX" provider=
"IBMJSSE2" algorithm="IbmPKIX" trustManagerClass="" 
managementScope="ManagementScope_managementNode_1">
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_1" name="com.ibm.se
curity.enableCRLDP" value="false" type="boolean" displayNameKey="" nlsRangeKey="
" hoverHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_2" name="com.ibm.js
se2.checkRevocation" value="false" type="boolean" displayNameKey="" nlsRangeKey=
"" hoverHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_3" name="ocsp.enabl
e" value="false" type="String" displayNameKey="" nlsRangeKey="" hoverHelpKey=""
range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_4" name="ocsp.respo
nderURL" value="http://ocsp.example.net:80" type="String" displayNameKey="" 
nlsRangeKey="" hoverHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_5" name="ocsp.respo
nderCertSubjectName" value="" type="String" displayNameKey="" nlsRangeKey="" hov
erHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_6" name="ocsp.respo
nderCertIssuerName" value="" type="String" displayNameKey="" nlsRangeKey="" hove
rHelpKey="" range="" inclusive="false" firstClass="false"/>
<additionalTrustManagerAttrs xmi:id="DescriptiveProperty_7" name="ocsp.respo
nderCertSerialNumber" value="" type="String" displayNameKey="" nlsRangeKey="" ho
verHelpKey="" range="" inclusive="false" firstClass="false"/>
</trustManagers>

Weitere Informationen zur Verwendung des Standard-Trust-Managers IbmPKFIX finden Sie im Artikel Beispiel: Überprüfung des Zertifikatswiderrufs mit dem Standard-Trust-Manager IbmPKIX aktivieren.

Der Trust-Manager IbmPKIX führt nicht nur die standardmäßige Zertifikatsprüfung durch, sondern sucht auch nach OCSP-Eigenschaften und Zertifikaten mit CRL-Verteilungspunkten. Dieser Prozess wird als erweiterte CRL-Überprüfung bezeichnet. Wenn Sie einen Trust-Manager auswählen, werden die zugehörigen Eigenschaften automatisch als Java-Systemeigenschaften gesetzt, damit die Provider "IBMCertPath" und "IBMJSSE2" wissen, dass die CRL-Überprüfung aktiviert ist.

Unterschiede zwischen den Ibmx509- und IbmPKIX-Trust-Managern

Die Validierungsanforderungen für x.509-Zertifikate sind im IbmX509-Trust-Manager strenger als im IbmPKIX-Trust-Manager. Beispiel:
  • Der IbmX509-Trust-Manager validiert die gesamte Zertifikatskette, unabhängig davon, welche Zertifikate der Client/Server anerkennt. Der IbmPKIX-Trust-Manager hingegen validiert ein Zertifikat selbst dann nicht, wenn Sie den IbmPKIX-Trust-Manager anweisen, dieses Zertifikat anzuerkennen. Der IbmPKIX-Trust-Manager validiert nur die Zertifikate ab dem Zertifikat, das mit dem von Ihnen anerkannten Zertifikat signiert wurde, bis hin zum Blattzertifikat. Außerdem ist Folgendes zu beachten:
  • IbmX509 setzt voraus, dass alle CA-Stammzertifikate die Erweiterung BASIC CONSTRAINTS haben. Andernfalls kann das Zertifikat nicht als CA-Stammzertifikat verwendet werden. IbmPKIX weist diese Anforderung bezüglich der Erweiterung BASIC CONSTRAINTS für CA-Stammzertifikate nicht auf.
  • Der IbmX509-Trust-Manager führt Signaturvalidierungs- und Zertifikatsablaufprüfungen durch, um die Zertifikate zu validieren. Der IbmPKIX-Trust-Manager führt dieselben Validierungen und darüber hinaus erweiterte CRL-Prüfungen durch, bei denen bestimmt wird, ob die Zertifizierungsstelle (CA) das Zertifikat widerrufen hat.
  • Der IbmPKIX-Trust-Manager ruft automatisch eine CR (Zertifikatswiderrufsliste) ab, wenn ein Zertifikat empfangen wird und CR-Verteilungspunkterweiterungen vorhanden sind.

Außerdem kann Online Certificate Status Protocol (OCSP) verwendet werden, um eine Onlineprüfung der Zertifikatsgültigkeit durchzuführen. Diese Funktion erfordert von Ihnen jedoch die Definition weiterer Systemeigenschaften, die in der Veröffentlichung Java Certification Path API Programmer's Guide dokumentiert sind, die Sie auf der Website von IBM® developerWorks finden.

Eigener Trust-Manager

Sie können einen eigenen Trust-Manager definieren, der entsprechend den Anforderungen der Umgebung zusätzliche Überprüfungen durchführt, um Vertrauen aufbauen zu können. In einer Umgebung könnte es beispielsweise sinnvoll sein, nur Verbindungen aus demselben TCP-Teilnetz zuzulassen. Die Schnittstelle "com.ibm.wsspi.ssl.TrustManagerExtendedInfo" stellt erweiterte Informationen zur Verbindung bereit. Von der JSSE-Standardschnittstelle "javax.net.ssl.X509TrustManager" werden diese Informationen nicht zur Verfügung gestellt. Das konfigurierte Attribut "trustManagerClass" bestimmt, von welcher Klasse die Laufzeit eine Instanz erstellt. Vergleichen Sie hierzu das folgende Codebeispiel:
<trustManagers xmi:id="TrustManager_1132357815718" name="CustomTrustManager" 
trustManagerClass="com.ibm.ws.ssl.core.CustomTrustManager" 
managementScope="ManagementScope_1132357815717"/>
Das Attribut "trustManagerClass" muss die Schnittstelle "javax.net.ssl.X509TrustManager" implementieren und kann die Schnittstelle "com.ibm.wsspi.ssl.TrustManagerExtendedInfo" implementieren.

Standard-Trust-Manager inaktivieren

In bestimmten Fällen möchten Sie vielleicht nicht die Standardzertifikatprüfung durchführen, wie sie von den IbmX509- und IbmPKIX-Standard-Trust-Managern angeboten wird. Möglicherweise arbeiten Sie ja in einer internen automatisierten Testinfrastruktur, in der SSL-Client- oder -Serverauthentifizierung, Datenintegrität oder Vertraulichkeit keine Rolle spielen. Der folgende Beispielcode zeigt einen angepassten Basis-Trust-Manager wie com.ibm.ws.ssl.core.CustomTrustManager, für den die zugehörige Eigenschaft auf true gesetzt ist.
com.ibm.ssl.skipDefaultTrustManagerWhenCustomDefined=true 
Sie können diese Eigenschaft in den allgemeinen Eigenschaften am Anfang der Datei ssl.client.props (für Clients) oder der Datei mit angepassten Eigenschaften security.xml (für Server) setzen. Wenn Sie den Standard-Trust-Manager inaktivieren, müssen Sie einen eigenen Trust-Manager konfigurieren, damit der Server nicht den konfigurierten Standard-Trust-Manager aufruft. Es ist nicht üblich, den Standard-Trust-Manager zu inaktivieren. Sie sollten das System mit dem inaktivierten Standard-Trust-Manager zunächst in einer Testumgebung testen. Weitere Informationen zum Konfigurieren eines eigenen Trust-Managers finden Sie im Artikel Angepasste Trust-Manager-Konfiguration für SSL erstellen.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_sslx509certtrustdecisions
Dateiname:csec_sslx509certtrustdecisions.html