SSL-Kommunikationsstrecken & Zertifikate

Auf dieser Seite sind für den Applikations-Betrieb relevante Informationen zu Kommunikationsstrecken und Zertifikaten enthalten.

Allgemein

Der reibungslose Betrieb der CRM-Applikation erfordert die Installation eines gültigen, kundenspezifischen und auf den aktuellsten SSL-Technologien basierenden Zertifikats.

• Beispielsweise muss der in den URLs verwendete DNS als SubjectAlternativeName im Zertifikat eingetragen sein.

Zertifizierungsstellenzertifikate

Unter Zertifizierungsstellenzertifikate sind nachfolgend die Root Certificate Authority's (bzw. CAs) (Stammzertifizierungsstelle) und Intermediate CAs (Zwischenzertifizierungsstellen) eines Server-Zertifikats gemeint. Für die Vertrauensstellung muss immer nur gewährleistet sein, dass das Root CA und die Intermediate CAs (falls existierend) in den jeweiligen Truststore (Applikations-Truststore oder Betriebssystem-Truststore) importiert werden.

• Das Server-Zertifikat selbst muss NICHT importiert werden

Wird im nachfolgenden Text von der "Kette" oder "Zertifikatskette" gesprochen, sprechen wir immer von sämtlichen Intermediate CAs und die Root CA, die notwendig sind, um die Vertrauensstellung zum Server-Zertifikat herzustellen.

Gültigkeit von Zertifikaten

Zertifikate, welche nach dem 01.09.2020 ausgestellt wurden, unterliegen bei Browsern und den Mobile Devices der Betriebssystemhersteller Apple und Google den Voraussetzungen, dass Zertifikate nur noch für maximal 398 Tage gültig sein dürfen. Andernfalls werden die Zertifikate von Browsern als unsicher eingestuft und bei Mobile Devices kann beispielsweise keine Verbindung mit der App aufgebaut werden.

• siehe: → Informationen zu bevorstehenden Beschränkungen für vertrauenswürdige Zertifikate

Company-Owned PKI vs. Public PKI

Jeder Kunde kann bei der Beschaffung des Zertifikats selbst entscheiden, ob er ein Zertifikat bei einer Public PKI einkauft oder das Zertifikat über eine Company-Owned PKI bezieht. Die meisten Public PKI Anbieter haben die Vertrauensstellung Out-of-the-Box auf den meisten Geräten und Betriebssystemen sichergestellt. Bei einer Company-Owned PKI ist der Kunde dafür verantwortlich für die Vertrauensstellung der Clients/Betriebssysteme und dem Applikationsserver zu sorgen.

Einsatz von Reverse-Proxy / Loadbalancer / WAF (Web Application Firewall)

Es steht dem Kunden frei, den Zugriff seiner Mitarbeiter auf den/die CRM-Applikationsserver mit einem Reverse-Proxy oder einer ähnlichen Technologie zu verwalten. In den meisten Fällen wird der Reverse-Proxy so betrieben, dass die Clients den Verbindungsaufbau und somit auch den SSL-Handshake, inkl. Verifizierung der Vertrauensstellung, mit dem Reverse-Proxy durchführen und nicht direkt mit dem CRM-Applikationsserver. Der Kunde muss in diesem Fall sicherstellen, dass bei einem Zugriff des Mitarbeiters auf die CRM-Applikation, die jeweiligen im Einsatz befindlichen Clients (Webclient, App, Admin-Client) in der Lage sind die Vertrauensstellung herzustellen. Zusätzlich muss der gewährleisten, dass der Reverse-Proxy die Verbindung zum CRM-Applikationsserver herstellen kann. Kommt ein Layer-7 Loadbalancer / eine Web Application Firewall zum Einsatz, sind diese Systeme dazu in der Lage, den Zugriff von den Kunden-Mitarbeitern auf unseren CRM-Applikationsserver feingranularer zu steuern. Beispielsweise können explizite Kontextpfade in den Web-Aufrufen freigegeben und blockiert werden. Für den reibungslosen Betrieb ist entweder der gesamte Kontextpfad "/" oder alternativ die aktuell von CURSOR verwendeten Kontextpfade freizugeben:

• /auth

• /admin

• /cti

• /cti_crm

• /help

• /infoboard

• /invocation

• /login

• /maskEditor

• /oauth

• /rest

• /script

• /scriptlibrary

• /soap

• /tilebuilder

• /webclient

Wird der Zugriff über die Freigaben einzelner Kontextpfade gesteuert, sind die aktuellen Kontextpfade während eines Updates zu prüfen und ggf. zu erweitern.

Single IP & Wildcard-Zertifikat & HTTP/2

Der Einsatz von Single IP, Wildcard-Zertifikat und HTTP/2, in Kombination mit einem Reverse-Proxy / Web Application Firewall, welcher die einzelnen Sessions nicht terminiert, sondern einfach nur weiterleitet, ist mit dem aktuellen Webstandard nicht erlaubt.

Wenn also keine Session-Terminierung erfolgt, können nur zwei der folgenden drei Punkte verwendet werden:

• Single IP

• Wildcard-Zertifikat

• HTTP/2

Wenn man sich nicht an diese Vorgaben hält, kann es passieren, dass der Proxy teilweise Datenpakete an die falschen Endpoints versendet.

Verweise:

• https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/

• https://bugzilla.mozilla.org/show_bug.cgi?id=1420777

• https://bugs.chromium.org/p/chromium/issues/detail?id=534069

• https://github.com/dlundquist/sniproxy/issues/178

Troubleshooting

Beim Troubleshooting ist es immer wichtig, die gesamte Netzwerk-Infrastruktur zu betrachten, die ein Datenpaket von der Source bis zur Destination durchläuft.

Werden beispielsweise bei dem Betrieb des CRM-Systems Verbindungsprobleme von einem Client oder zu einem Service festgestellt, die zu einem Troubleshooting-Termin führen, muss der Kunde sicherstellen in dem Termin entsprechende Experten in den Termin mit einzubeziehen, die beispielsweise die gesamte Datenpaket-Kommunikationsstrecke in diesem Termin erklären können.

Beispiele

• Zugriff von extern oder intern

• Reverse-Proxy (Loadbalancer/WAF)

• Proxy

• VPN

• Routing

• etc.

App

Sollte der Verbindungsaufbau mit der CURSOR App nicht erfolgreich sein, können mehrere Schritte zum Troubleshooting durchgeführt werden.

• Wenn im CRM-Applikationsserver-Log keinerlei Informationen über einen Login-Versuch zu finden sind, ist die Wahrscheinlichkeit hoch, dass das Endgerät bzw. die App keine Kommunikation mit dem CRM-Applikationsserver aufbauen konnte

  • Netzwerk-Infrastruktur prüfen, evtl. Wireshark auf dem Server betreiben bzw. ein Port-Mirroring auf Netzwerkebene einrichten

  • Firewall-Zugriffsregeln prüfen

• Handelt es sich um einen Zertifikatsfehler, der auf dem Mobile Device angezeigt wird, ist folgendes Vorgehen sinnvoll

  • Gibt die Fehlermeldung eventuell schon genaueren Aufschluss darauf, woher das Problem stammen könnte

  • Stimmen die Konfigurationen in der App (Server, Port, etc.)

    • Passen die Subject Alternative Name Informationen zu denen des Kommunikationspartner der App?

      • Kommt beispielsweise ein Reverse-Proxy zum Einsatz

    • Wir empfehlen die Nutzung von DNS-Adressen in Zertifikaten, um möglichen Problemen vorzubeugen

    • Ist die Verteilung von den Zertifizierungsstellenzertifikaten (die gesamte Kette) notwendig?

      • Falls ja, wurde die Verteilung vorgenommen?

  • Funktioniert der Webclient von einem Standard-Client im Kunden-Netzwerk

    • Zeigt der Webclient eine Zertifikatsfehlermeldung, welche im Browser "übersteuert" werden kann?

  • Funktioniert der Webclient  auf dem Mobile Device, welches mit der App keine Verbindung aufbauen konnte

    • Zeigt der Webclient eine Zertifikatsfehlermeldung, welche im Browser "übersteuert" werden kann?

    • Ist sichergestellt, dass der Webclient den gleichen Netzwerk-Pfad durchläuft wie die App?

      • z.B. mit Blick auf VPN, App-Based-VPN, etc.

  • Entspricht das Zertifikat, welches im CRM-Applikationsserver hinterlegt ist, den aktuellen technischen Anforderungen (SubjectAlternativName, etc.)

Bei der App insbesondere ist zu betrachten, dass die App eine korrekte Konfiguration der Zertifikate erfordert, damit eine Verbindung zum CRM-Applikationsserver aufgebaut werden kann.

Eine "Übersteuerung" wie es beispielsweise in einem Browser für den Webclient gibt ("Zertifikatsfehler: trotzdem fortfahren"), ist bei der App nicht möglich.

Durch die limitierten Möglichkeiten zum Remote-Troubleshooting auf einem Mobile Device, ist es sehr wichtig, dass von sämtlichen Tests Screenshots erzeugt und CURSOR zur Verfügung gestellt werden.

• Sofern der Kunde in der Lage ist eine Remote-Session auf dem Mobile Device bereit zustellen, kann dies im Rahmen des Troubleshootings bevorzugt betrachtet werden

Nur durch eine der beiden Vorgehensweisen kann CURSOR sicherstellen, dass keine wichtigen Informationen in der Kommunikation übersehen werden.

Firewalls / ZTNA

Moderne Firewalls bieten neue Sicherheits-Technologien zur Verwaltung von Netzwerkverkehr an, um den Datenfluss innerhalb eines Netzwerks und darüber hinaus zu überwachen. Basierend auf verschiedenen Regeln können somit beispielsweise komplexere Voraussetzungen geschaffen werden, damit ein Endgerät in der Lage ist einen Service auf einem Server zu erreichen. Setzt der Kunde solche Technologien ein, muss der Kunde dafür sorgen, dass die Endbenutzer die CRM-Applikation erreichen können.

Beispiele für moderne Technologien:

• ZTNA: Client fehlt noch ein Windows Update und darf erst noch Installation dieses Windows Updates mit dem CRM-System kommunizieren

• Application-Based-Policies: der Browser Edge darf mit dem CRM-System kommunizieren, andere Browser dürfen es nicht

Neben der Verbindung zum CRM-Applikationsserver, sind diese Punkte auch bei der Kommunikation vom CRM-Applikationsserver zu Dritt-Systemen mit zu beachten.

Schnittstellen

Möchte ein Dritt-System auf Basis von Webaufrufen mit unserem CRM-System kommunizieren, muss der Kunde sicherstellen, dass die Vertrauensstellung zwischen den beiden Systemen gewährleistet ist.

• der Kunde muss somit einerseits sicherstellen, dass das CRM-System und das Dritt-System in der Lage sind eine Verbindung aufzubauen

• der Kunde muss zusätzlich sicherstellen, dass der Truststore im CRM-System, als auch im Dritt-System so eingerichtet ist, dass die Vertrauensstellung zum jeweils anderen System hergestellt werden kann

  • zum Beispiel könnte der Import von Stamm- bzw. Zwischenzertifizierungsstellen in den Truststore des CRM-Applikationsservers notwendig sein

Zu beachten ist, dass Dritt-Systeme entweder auf den Betriebssystem-Truststore zugreifen oder einen separaten Anwendungs-Truststore besitzen könnten.

Die jeweiligen Server-Zertifikate, welche im CRM und/oder Dritt-System installiert sind, müssen nicht im Truststore importiert werden.

Company-Owned Zertifikate

Ist im CRM-System ein Zertifikat installiert, welches über eine Company-Owned Zertifizierungsstelle ausgestellt wurde, so ist sicherzustellen, dass die Schnittstellen-Systeme die Vertrauensstellung zu dieser Company-Owned CA herstellen kann.

In manchen Systemumgebungen ist die Implementierung eines Company-Owned CA Zertifikats möglicherweise nicht erlaubt, weil entsprechende Unternehmens-Richtlinien existieren, die den Import des Zertifikats verbieten. Beispielsweise könnte eine ISO 27001 bei einem ERP-Hersteller den Import des Company-Owned CA Zertifikats verbieten.

Proxy

Wenn das CRM-System Verbindungen zu anderen Systemen aufbauen soll, beispielsweise Microsoft365, ERP-Systeme, etc., muss durch den Kunden sichergestellt werden, dass die Kommunikation zwischen den Systemen durchgeführt werden kann. Steht beispielsweise ein Proxy in der Verbindungsstrecke zwischen CRM-Applikationsserver und Dritt-System, muss durch den Kunden sichergestellt werden, dass über den Proxy hinaus die Kommunikation aufgebaut werden kann.

• Ist der Proxy mit SSL-Offloading / SSL-Inspection konfiguriert, d.h. der Proxy agiert als Man-in-the-Middle zum Scannen der HTTPS-Pakete, muss sichergestellt werden, dass der CRM-Applikationsserver eine Verbindung über den Proxy hinaus zu dem entsprechenden Zieldienst aufgebaut werden kann.

  • Unter Umständen muss das Zertifizierungsstellenzertifikat (bzw. die Kette) des Proxy's im Truststore des CRM-Applikationsserver importiert werden

  • Dies ist unter Umständen auch dann notwendig, wenn die eigentliche Destination mit einem Zertifizierungsstellenzertifikat (bzw. die Kette) ausgestattet ist, welche bereits im Truststore bekannt ist

Mit OpenSSL ist es möglich, die Verbindung zwischen einem CRM-Applikationsserver und einem Dritt-System zu überprüfen

Debugging

Eine Möglichkeit bei Zertifikatsproblem das Debugging zu vereinfachen, ist über die Erweiterung der wrapper.conf (wenn als Dienst laufend, ansonsten die standalone-Skripte).

• wrapper.java.additional.XY=-Djava.security.debug=certpath

• Die Konfiguration dieses Parameters wird Auswirkungen auf die Performance und die Größen der Logdateien haben.

• Ein einzelner Aufruf einer Schnittstelle, die in das Log geschrieben wird, kann bis zu 20.000 Log-Zeilen generieren.

• Es wird dringend empfohlen, dass nach der Reproduzierung des Problems, der Parameter sofort wieder entfernt und der Applikationsserver neu gestartet wird.

Das gesamte Server- und Stacktrace-Log muss zur Fehleranalyse den Experten von CURSOR zur Verfügung gestellt werden.

Im Log kann unter anderem das problembehaftete Zertifikat bzw. die Zertifikatskette angegeben werden.

Beispielskizzierung eines Netzwerks

Glossar