SSL Konfigurationsoptionen und -hinweise

Nutzung von TLS/SSL im service.monitor

service.monitor kann sämtliche HTTP-Kommunikation mit Transport Level Security (TLS/SSL) abwickeln. Dieses Vorgehen wird auch ausdrücklich empfohlen, dabei müssen einige Implikationen berücksichtigt werden.

service.monitor verwendet HTTP(S) für:

  • die Abfrage/das Monitoring von Diensten

  • das Testen von Monitoring-Jobs im User Interface

  • die Abfrage von ArcGIS Server Tokens, falls für Authentifizierung nötig

  • die Kommunikation mit security.manager (ONLY_AUTH Authentifizierung)

  • die Abfrage von Diensten einer Monitoring-Quelle (Dienst-Harvesting)

  • das Senden von Nachrichten an Webhooks (MS Teams, Slack)

Bei einer konsequente Validierung von SSL-Zertifikaten bedeutet dies, dass Fehlermeldungen an unterschiedlichen Orten auftauchen können, falls nicht valide oder nicht vertraute Zertifikate auf der Gegenseite verwendet werden:

  • Log-Files

  • User-Interface (Test und Request-Protokollierung)

  • Benachrichtigungen

Allgemeine Informationen zu SSL/TLS

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.
Diese Einstellung sollte nur in Entwicklungsumgebungen aktiv sein.

Serverzertifikaten Vertrauen

Damit ein Serverzertifikat von der JVM als vertrauenswürdig erachtet wird, muss entweder direkt das konkrete Serverzertifikat 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 Serverzertifikaten 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 Web Sites, die Dienste per HTTPS zur Verfügung stellen, besitzen üblicherweise Serverzertifikate, deren Stammzertifikat von einer Vertrauenswürdigen Certificate Authority (CA) ausgestellt wurde. Diese Stammzertifikate sind in der JRE bereits vorinstalliert und werden damit automatisch als vertrauenswürdig eingestuft.

Um die Verbindung mit einem Endpunkt zu erlauben, dessen Serverzertifikat 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 Serverzertifikate 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 Serverzertifikaten schlagen dann fehl, es sei denn, das Stammzertifikat wird durch unternehmensinterne Prozesse automatisch allen JRE-Installationen hinzugefügt.

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

(C) Selbst-signierte Zertifikate

Selbst-signierte Serverzertifikate, also Zertifikate, die sich selbst als Herausgeber referenzieren, werden häufig zu Testzwecken verwendet und sollten in Produktivsystemen nicht genutzt werden. Da ein selbst-signiertes Serverzertifikat 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 Serverzertifikat 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 Serverzertifikaten 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. auch andere Ursachen und Lösungen in Betracht zu ziehen.

Typische Fehlermeldungen:

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 des Stammzertifikats im JRE

  • Installieren des Serverzertifikats im JRE

  • Wenn der angefragte Server unter eigener Kontrolle ist: Bereitstellung eines neuen Serverzertifikats, das von einer vertrauenswürdigen CA ausgestellt wurde, auf dem angefragten Server.

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 Serverzertifikat 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 oft die uneinheitliche Nutzung von nicht-qualifizierten und vollqualifizierter Host-Namen in Anfrage-URLs bzw. Serverzertifikaten zu diesem Problem. Auch die Verwendung des speziellen Host-Namen localhost oder IP-Adressen in URLs führt zu diesem Problem, wenn der das Serverzertifikat auf den qualifizierten Rechnernamen ausgestellt wurde.

Mögliche Lösungen:

  • Verwenden des Host-Namen in Anfrage-URLs so, wie er im Serverzertifikat angegeben wird

  • Erstellen und Hinterlegen eines neuen Serverzertifikats für den vom Client gewünschten Host-Name, wenn sich zum Beispiel herausstellt, dass die Verwendung eines nicht-vollqualifizierten Host-Namens (oder localhost oder IP-Adresse) nicht sinnvoll ist.

  • Erstellen und Hinterlegen eines neuen Serverzertifikats mit alternativen Host-Namen (Subject Alternative DNS Names), wenn sich zum Beispiel herausstellt, dass der Server unausweichlich unter unterschiedlichen Host-Namen erreichbar sein muss.

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 dieser Liste. Einziger Unterschied ist, dass das Serverzertifikat ein zusätzliches Feld mit alternativen Host-Namen besitzt, jedoch der vom Client verwendete Host-Name weder dem Subject-CN des Serverzertifikats entspricht noch in dessen Liste alternativer Host-Namen (Subject Alternative DNS Names) angegeben ist.

Mögliche Lösungen: Die Lösungsvorschläge der vorherigen Fehlermeldung gelten auch hier.

Typische Szenarien

Job-Protokollierung zeigt Fehler an

In der Anfragehistorie des User Interfaces werden Fehlermeldungen angezeigt:

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

Dies bedeutet, dass bei der Ausführung eines Monitoring-Jobs ein HTTP-Endpunkt angesprochen wurde, dessen SSL Zertifikat nicht gültig ist.

Lösungsmöglichkeiten:

  • Import des Zertifikats in den Trust Store

  • Setzung des Property security.ssl.trustAny

  • Hinweis an den Dienstbetreiber ein gültiges Zertifikat zu nutzen

Fehlschlag eines Test-Requests

Bei der Ausführung eines Test-Request erscheint im Browser:

test request failed

Dies bedeutet, dass beim Testen eines Monitoring-Jobs ein HTTP-Endpunkt angesprochen wurde, dessen SSL Zertifikat nicht gültig ist.

Lösungsmöglichkeiten:

service.monitor kann Authentifizierung mit security.manager nicht durchführen (ONLY_AUTHN)

Der Nutzer authentifiziert sich am security.manager und wird an den service.monitor zurückgeleitet. service.monitor kann jedoch keine (SSL) Verbindung zum security.manager aufbauen, um das Cookie zu validieren und leitet seinerseits den Nutzer zum security.manager zurück. Die Folge ist eine schnelle Abfolge von Umleitungen und die Meldung im Browser err_too_many_redirects.

Lösungsmöglichkeiten:

  • Import des Zertifikats des security.manager Hosts in den Trust Store

  • Setzung des Property security.ssl.trustAny.internal

  • Verwendung eines gültigen Zertifikats für den security.manager

  • Nutzung von HTTP für die Anbindung von security.manager