SSL Konfiguration

service.monitor kann sämtliche HTTP-Kommunikation mit Transport Level Security (TLS/SSL) abwickeln.

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

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

Mit der Konfigurationsoption security.ssl.trustAny steuern Sie, 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.

Wir empfehlen dringend, 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 die JVM ein Serverzertifikat als vertrauenswürdig erachtet, 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, andere Quellen für vertrauenswürdige Zertifikate zu nutzen.

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 Webseiten, 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 sicherzustellen, dass allen von dieser organisationsinternen CA ausgestellten Serverzertifikaten vertraut wird, müssen Sie das Stammzertifikat der CA dem Keystore [JRE_HOME]/lib/security/cacerts hinzufügen.

(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, müssen Sie dieses Zertifikat dem Keystore [JRE_HOME]/lib/security/cacerts hinzufügen.

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

Das vom Server präsentierte Zertifikat für die HTTPS-Verbindung wird von der JVM nicht als vertrauenswürdig eingestuft. 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

Der in der HTTPS-Anfrage genutzte Hostname passt nicht zu dem Hostnamen, der im Serverzertifikat angegeben ist. Der Client (Browser, Java-Applikation) vergleicht dabei den in der Anfrage-URL verwendeten Hostnamen 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 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 Hostnamen 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 Hostnamen in Anfrage-URLs bzw. Serverzertifikaten zu diesem Problem. Auch die Verwendung des speziellen Hostnamen localhost oder IP-Adressen in URLs führt zu diesem Problem, wenn das Serverzertifikat auf den qualifizierten Rechnernamen ausgestellt wurde.

Mögliche Lösungen:

  • Verwenden des Hostnamen in Anfrage-URLs, wie er im Serverzertifikat angegeben wird.

  • Erstellen und Hinterlegen eines neuen Serverzertifikats für den vom Client gewünschten Hostname, beispielsweise wenn die Verwendung eines nicht-vollqualifizierten Hostnamens (oder localhost oder IP-Adresse) nicht sinnvoll ist.

  • Erstellen und Hinterlegen eines neuen Serverzertifikats mit alternativen Hostnamen (Subject Alternative DNS Names), beispielsweise wenn der Server unausweichlich unter unterschiedlichen Hostnamen 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. Einziger Unterschied ist, dass das Serverzertifikat ein zusätzliches Feld mit alternativen Hostnamen besitzt. Jedoch entspricht der vom Client verwendete Hostname weder dem Subject-CN des Serverzertifikats noch einem in dessen Liste alternativer Hostnamen (Subject Alternative DNS Names).

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:

Authentifizierung mit security.manager nicht durchführbar (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