Finesse-Fehler "SSLPeerUnverifiedException" für Gadgets, die auf Servern mit CA-Signatur gehostet werden
Inhalt
Einleitung
In diesem Dokument werden die Schritte zur Fehlerbehebung in einem Szenario beschrieben, in dem eine von der Zertifizierungsstelle (Certificate Authority, CA) signierte Zertifikatskette für einen externen Webserver, der ein Gadget hostet, auf Finesse hochgeladen wird, das Gadget jedoch nicht geladen wird, wenn Sie sich bei Finesse anmelden, und der Fehler "SSLPeerUnverifiedException" angezeigt wird.
Mit freundlicher Unterstützung von Gino Schweinsberger, Cisco TAC Engineer.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- SSL-Zertifikate
- Finesse-Verwaltung
- Windows Server-Administration
- Paketerfassungsanalyse mit Wireshark
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf folgenden Software-Versionen:
- Unified Contact Center Express (UCCX) 11.x
- Finesse 11.x
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.
Hintergrundinformationen
Dies sind die Bedingungen für das Auftreten des Fehlers:
- Annahme: Die Zertifikatvertrauenskette wird nach Finesse hochgeladen
- Stellen Sie sicher, dass die richtigen Server/Dienste neu gestartet wurden.
- Angenommen, das Gadget wurde dem Finesse-Layout mit einer HTTPS-URL hinzugefügt und die URL ist erreichbar.
Dieser Fehler wurde bei der Anmeldung des Agenten bei Finesse festgestellt:
"Bei der Wiedergabe dieses Gadgets sind Probleme aufgetreten. javax.net.ssl.SSLPeerUnverifiedException: Peer nicht authentifiziert"
Probleme
Szenario 1: Der Hosting-Server handelt unsichere TLS aus
Wenn Finesse Server eine Verbindungsanforderung an den Hosting-Server stellt, kündigt Finesse Tomcat eine Liste der unterstützten Verschlüsselungsschlüssel an.
Einige Chiffren werden aufgrund von Sicherheitslücken nicht unterstützt.
Wenn der Hostserver einen dieser Chiffren auswählt, wird die Verbindung abgelehnt:
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Diese Chiffren nutzen bekanntermaßen schwache ephemere Diffie-Hellman-Schlüssel, wenn sie die Verbindung aushandeln. Aufgrund der Logjam-Verwundbarkeit sind diese eine schlechte Wahl für TLS-Verbindungen.
Folgen Sie dem TLS-Handshake-Prozess bei der Paketerfassung, um festzustellen, welche Verschlüsselung ausgehandelt wird.
1. Finesse präsentiert seine Liste der unterstützten Chiffren im Client Hello-Schritt:
2. Für diese Verbindung wurde TLS_DHE_RSA_WITH_AES_256_CBC_SHA vom Hosting-Server während des Server-Hello-Schritts ausgewählt, da dieser höher in der Liste der bevorzugten Chiffren steht.
3. Finesse sendet eine schwerwiegende Warnung und beendet die Verbindung:
Lösung
Um die Verwendung dieser Chiffren zu verhindern, muss der Hosting-Server so konfiguriert werden, dass diese eine niedrige Priorität erhalten, oder sie müssen vollständig aus der Liste der verfügbaren Chiffren entfernt werden. Dies kann auf einem Windows-Server mit dem Windows-Gruppenrichtlinien-Editor (gpedit.msc) erfolgen.
Szenario 2: Das Zertifikat verfügt über einen nicht unterstützten Signaturalgorithmus
Windows Server-Zertifizierungsstellen können neuere Signaturstandards verwenden, um Zertifikate zu signieren. Selbst wenn dadurch die Sicherheit erhöht wird als bei SHA, werden diese Standards nur in geringem Umfang außerhalb von Microsoft-Produkten übernommen, und Administratoren stoßen wahrscheinlich auf Interoperabilitätsprobleme.
Finesse Tomcat vertraut auf den Sicherheitsanbieter SunMSCAPI von Java, um die Unterstützung für die verschiedenen von Microsoft verwendeten Signaturalgorithmen und Verschlüsselungsfunktionen zu ermöglichen. Alle aktuellen Versionen von Java (1.7, 1.8 und 1.9) unterstützen nur die folgenden Signaturalgorithmen:
- MD5 mit RSA
- MD2mitRSA
- KEINE mitRSA
- SHA1 mitRSA
- SHA256mit RSA
- SHA384mit RSA
- SHA512mit RSA
Es empfiehlt sich, die Java-Version auf dem Finesse-Server zu überprüfen, um festzustellen, welche Algorithmen in dieser Version unterstützt werden. Die Version kann mithilfe des folgenden Befehls vom Root-Zugriff aus überprüft werden: java -version
Wenn ein Zertifikat mit einer anderen als den oben aufgeführten Signaturen bereitgestellt wird, kann Finesse das Zertifikat nicht zum Herstellen einer TLS-Verbindung mit dem Hosting-Server verwenden. Dazu gehören Zertifikate, die mit einem unterstützten Signaturtyp signiert sind, aber von Zertifizierungsstellen ausgestellt wurden, deren eigene Zwischen- und Stammzertifikate mit anderen Signaturen signiert sind.
Wenn Sie sich eine Paketerfassung ansehen, schließt Finesse die Verbindung mit einer "schwerwiegenden Warnung: Certificate Unknown"-Fehler, wie im Bild gezeigt.
An dieser Stelle ist erforderlich, um die vom Hosting-Server vorgelegten Zertifikate zu überprüfen und nach nicht unterstützten Signaturalgorithmen zu suchen. Es ist üblich, RSASSA-PSS als den problematischen Signaturalgorithmus zu betrachten:
Wenn ein Zertifikat in der Kette mit RSASSA-PSS signiert ist, schlägt die Verbindung fehl. In diesem Fall zeigt die Paketerfassung, dass die Stammzertifizierungsstelle RSASSA-PSS für ihr eigenes Zertifikat verwendet:
Lösung
Um dieses Problem zu beheben, muss ein neues Zertifikat von einem Zertifizierungsstellenanbieter ausgestellt werden, der nur einen der unterstützten SunMSCAPI-Signaturtypen verwendet, die wie oben erläutert in der gesamten Zertifikatskette aufgeführt sind.
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
16-Jul-2019 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)