Ausgehende HTTPS-Verbindungen

Aus den folgenden Gründen stellen security.manager Web-Applikationen HTTPS-Verbindungen mit anderen Diensten her:

  • Kommunikation mit anderen security.manager Web-Applikationen

  • Weiterleiten von Anfragen zu und Abfragen von Metadaten von geschützten Diensten

  • Anfragen von Diensten, die die Geometrien für die Durchsetzung räumlicher Auflagen bereitstellen

  • Validieren und Anfragen von Tokens von ArcGIS Server oder Portal for ArcGIS

Beim Aufbau von Verbindungen zu HTTPS-Endpunkten durch serverseitige Java-Komponenten muss sichergestellt werden, dass das TLS/SSL-Server-Zertifikat des angefragten Hosts von der Java Virtual Machine (JVM) akzeptiert und als vertrauenswürdig erachtet wird. Andernfalls wird keine HTTPS-Verbindung zum Server aufgebaut und die Applikation reagiert fehlerhaft.

Mit der Konfigurationsoption security.ssl.trustAny wird gesteuert, unter welchen Bedingungen ein TLS-Server-Zertifikat akzeptiert wird:

  • security.ssl.trustAny=false (empfohlen)
    Es werden nur Zertifikate akzeptiert, die von der JVM als vertrauenswürdig erachtet werden. Es wird dringend empfohlen, diese Einstellung beizubehalten. Dies gilt insbesondere für produktive Umgebungen. Sie müssen sicherstellen, dass Server-Zertifikate von HTTPS-Endpunkten, zu denen Verbindungen hergestellt werden, vertrauenswürdig sind. Andernfalls kommt es beim Aufbau einer Verbindung zu einem Fehler.

  • security.ssl.trustAny=true
    Es werden alle Zertifikate akzeptiert. Das Zertifikat muss weder für den angefragten Host noch von einer vertrauenswürdigen Stelle ausgestellt worden sein. Aktivieren Sie diese Einstellung nur in Entwicklungsumgebungen.

Server-Zertifikaten vertrauen

Damit ein Server-Zertifikat von der JVM als vertrauenswürdig erachtet wird, muss entweder das konkrete Server-Zertifikat oder dessen Stammzertifikat im Java Runtime Environment (JRE) installiert sein. Vertrauenswürdige Zertifikate bzw. Stammzertifikate werden im JRE standardmäßig in einem Java Keystore unter [JRE_HOME]/lib/security/cacerts gespeichert.

Je nach Betriebssystem oder Konfiguration der JVM ist es möglich, dass andere Quellen für vertrauenswürdige Zertifikate genutzt werden.

Im Folgenden wird beschrieben, welche Typen von Server-Zertifikaten von HTTPS-Endpunkten üblicherweise verwendet werden und was bezüglich der Vertrauenswürdigkeit zu beachten ist.

(A) Zertifikate mit Stammzertifikat, das im JRE installiert ist

Produktive Websites, die Dienste per HTTPS zur Verfügung stellen, besitzen üblicherweise Server-Zertifikate, deren Stammzertifikat von einer Vertrauenswürdigen Certificate Authority (CA) ausgestellt wurde. Diese Stammzertifikate sind in der JRE bereits vorinstalliert und werden damit als vertrauenswürdig eingestuft.

Um die Verbindung mit einem Endpunkt zu erlauben, dessen Server-Zertifikat ein bereits in der JRE installiertes Stammzertifikat besitzt, sind keine weiteren Schritte notwendig.

(B) Zertifikate mit Stammzertifikat, das nicht im JRE installiert ist

Gelegentlich werden in Organisationen Server-Zertifikate verwendet, die von einer eigenen, organisationsinternen CA ausgestellt wurden. Das zugehörige Stammzertifikat ist folglich nicht Teil der im JRE vorinstallierten Zertifikate. Verbindungen zu HTTPS-Endpunkten mit solchen Server-Zertifikaten schlagen dann fehl, es sei denn, das Stammzertifikat wird durch unternehmensinterne Prozesse allen JRE-Installationen hinzugefügt.

Um sicher zu stellen, dass allen von dieser organisationsinternen CA ausgestellten Server-Zertifikaten vertraut wird, muss das Stammzertifikat der CA dem Keystore [JRE_HOME]/lib/security/cacerts hinzugefügt werden.

(C) Selbst-signierte Zertifikate

Selbst-signierte Server-Zertifikate, also Zertifikate, die sich selbst als Herausgeber referenzieren, werden häufig zu Testzwecken verwendet. Verwenden Sie sie nicht in Produktivsystemen. Da ein selbst-signiertes Server-Zertifikat nicht Teil der mit dem JRE bereits installierten Zertifikate ist, ist es nicht vertrauenswürdig.

Um HTTPS-Verbindungen mit einem Host zu erlauben, der ein selbst-signiertes Server-Zertifikat verwendet, muss dieses Zertifikat dem Keystore [JRE_HOME]/lib/security/cacerts hinzugefügt werden.

Typische Fehlermeldungen

Beim Aufbau serverseitiger HTTPS-Verbindungen kann es zu verschiedenen Fehlersituationen im Zusammenhang mit der Validierung von Server-Zertifikaten kommen. In den folgenden Abschnitten werden typische Fehlermeldungen aufgeführt, die in der Log-Datei der serverseitigen Anwendung oder in den Browser-Oberflächen der Applikationen erscheinen können. Zusätzlich werden ihre möglichen Ursachen beschrieben und Lösungen vorgeschlagen. Abhängig von der konkreten Infrastruktur, in der die betroffene Applikation betrieben wird, sind ggf. andere Ursachen und Lösungen in Betracht zu ziehen.

1. "PKIX path building failed"

Vollständige Fehlermeldung:

sun.security.validator.ValidatorException:
 PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Diese Fehlermeldung ist ein Hinweis darauf, dass das vom Server präsentierte Zertifikat für die HTTPS-Verbindung von der JVM nicht als vertrauenswürdig eingestuft wird. Ggf. handelt es sich um ein selbst-signiertes Zertifikat oder das Stammzertifikat ist nicht im JRE installiert.

Mögliche Lösungen:

  • Installieren Sie das Stammzertifikat im JRE

  • Installieren Sie das Server-Zertifikat im JRE

  • Wenn der angefragte Server unter eigener Kontrolle ist: Stellen Sie auf dem angefragten Server ein neues Server-Zertifikat bereit, das von einer vertrauenswürdigen CA ausgestellt wurde.

2. "No name matching [requested.host.name] found"

Vollständige Fehlermeldung:

javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No name matching maps.example.com found

Diese Fehlermeldung zeigt an, dass der in der HTTPS-Anfrage genutzte Host-Name nicht zu dem Host-Namen passt, der im Server-Zertifikat angegeben ist. Der Client (Browser, Java-Applikation) vergleicht dabei den in der Anfrage-URL verwendeten Host-Namen mit dem "CN" Namen des "Subject"-Feldes im X509-Zertifikat des Servers, z.B.
https://maps.example.com/
mit
CN = www.example.com, O = Example LLC, L = Mountain Dew, ST = California, C = US.

Stimmen beide Namen nicht überein (Groß-/Kleinschreibung ist nicht relevant), wird mit der Verbindungsaufbau mit der o.g. Fehlermeldung abgebrochen. Dabei ist es unerheblich, ob das Zertifikat als vertrauenswürdig eingestuft würde. Die Prüfung der Vertrauenswürdigkeit findet erst statt, wenn das Übereinstimmen der Host-Namen sichergestellt ist.

Häufig kommt es zu diesem Problem, wenn Clients denselben Server mit unterschiedlichen Namen ansprechen können, weil mehrere DNS-Einträge vorhanden sind. Insbesondere wenn der Client sich in derselben Domäne wie der Server befindet, führt die uneinheitliche Nutzung von nicht-qualifizierten und vollqualifizierten Host-Namen in Anfrage-URLs bzw. Server-Zertifikaten häufig zu diesem Problem. Die Verwendung des speziellen Host-Namen "localhost" oder IP-Adressen in URLs führt zu diesem Problem, wenn das Server-Zertifikat auf den qualifizierten Rechnernamen ausgestellt wurde.

Mögliche Lösungen:

  • Verwenden Sie den Host-Namen in Anfrage-URLs so, wie er im Server-Zertifikat angegeben wird.

  • Erstellen und Hinterlegen Sie ein neues Server-Zertifikat für den vom Client gewünschten Host-Namen, wenn sich herausstellt, dass die Verwendung eines nicht-vollqualifizierten Host-Namens (oder "localhost" oder IP-Adresse) nicht sinnvoll ist.

  • Erstellen und Hinterlegen Sie eine neues Server-Zertifikat mit alternativen Host-Namen ("Subject Alternative DNS Names"), wenn sich herausstellt, dass der Server unausweichlich unter unterschiedlichen Host-Namen erreichbar sein muss.

3. "No subject alternative DNS name [requested.host.name] found"

Vollständige Fehlermeldung:

javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No subject alternative DNS name matching maps.example.com found

Diese Fehlermeldung ist ein Sonderfall der Fehlermeldung "No name matching [requested.host.name] found". Einziger Unterschied ist, dass das Server-Zertifikat ein zusätzliches Feld mit alternativen Host-Namen besitzt, jedoch der vom Client verwendete Host-Name weder dem "Subject-CN" des Server-Zertifikats entspricht noch in dessen Liste alternativer Host-Namen ("Subject Alternative DNS Names") angegeben ist.

Mögliche Lösungen:
Analog zu Lösungsvorschlägen zum Fehler "No name matching [requested.host.name] found"