Dépannage de l'erreur Finesse " ; SSLPeerUnverifyException" ; pour les gadgets hébergés sur des serveurs signés CA
Contenu
Introduction
Ce document décrit les étapes à suivre pour dépanner le scénario dans lequel une chaîne de certificats signée par une autorité de certification (CA) est téléchargée vers Finesse pour un serveur Web externe qui héberge un gadget mais le gadget ne se charge pas lorsque vous vous connectez à Finesse et que l'erreur « SSLPeerUnverifyException » apparaît.
Contribué par Gino Schweinsberger, ingénieur TAC Cisco.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Certificats SSL
- Administration Finesse
- Administration de Windows Server
- Analyse de capture de paquets avec Wireshark
Components Used
Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :
- Unified Contact Center Express (UCCX) 11.X
- Finesse 11.X
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Voici les conditions pour que l'erreur se produise :
- Supposons que la chaîne d'approbation de certificat est téléchargée vers Finesse
- Vérifiez que les serveurs/services corrects ont été redémarrés
- Supposez que le gadget a été ajouté à la disposition Finesse avec une URL HTTPS et que l'URL est accessible
Voici l'erreur observée lorsque l'agent se connecte à Finesse :
« Il y a eu des problèmes pour rendre ce gadget. javax.net.ssl.SSLPeerUnverifyException : homologue non authentifié »
Problèmes
Scénario 1 : Le serveur d'hébergement négocie TLS non sécurisé
Lorsque Finesse Server effectue une demande de connexion au serveur d'hébergement, Finesse Tomcat annonce une liste de chiffrement qu'il prend en charge.
Certains algorithmes de chiffrement ne sont pas pris en charge en raison de failles de sécurité,
Si le serveur d'hébergement sélectionne l'un de ces algorithmes de chiffrement, la connexion est refusée :
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Ces algorithmes de chiffrement sont connus pour utiliser des clés de Diffie-Hellman éphémères faibles lorsqu'ils négocient la connexion, et la vulnérabilité Logjam en fait un mauvais choix pour les connexions TLS.
Suivez le processus de connexion TLS dans une capture de paquets pour voir quel chiffrement est négocié.
1. Finesse présente sa liste de chiffrements pris en charge dans l'étape Hello du client :
2. Pour cette connexion, TLS_DHE_RSA_WITH_AES_256_CBC_SHA a été sélectionné par le serveur d'hébergement au cours de l'étape Hello du serveur car il figure en haut de la liste des algorithmes de chiffrement préférés.
3. Finesse envoie une alerte fatale et met fin à la connexion :
Solution
Afin d'empêcher l'utilisation de ces algorithmes de chiffrement, le serveur d'hébergement doit être configuré pour accorder une priorité faible à ces derniers, ou ils doivent être complètement supprimés de la liste des algorithmes de chiffrement disponibles. Cela peut être fait sur un serveur Windows avec l'éditeur de stratégie de groupe Windows (gpedit.msc).
Scénario 2 : Le certificat possède un algorithme de signature non pris en charge
Les autorités de certification Windows Server peuvent utiliser des normes de signature plus récentes pour signer des certificats. Même s'il offre une sécurité supérieure à celle du SHA, l'adoption de ces normes en dehors des produits Microsoft est faible et les administrateurs risquent de rencontrer des problèmes d'interopérabilité.
Finesse Tomcat s'appuie sur le fournisseur de sécurité SunMSCAPI de Java pour activer la prise en charge des divers algorithmes de signature et fonctions cryptographiques utilisés par Microsoft. Toutes les versions actuelles de Java (1.7, 1.8 et 1.9) prennent uniquement en charge ces algorithmes de signature :
- MD5avec RSA
- MD2avec RSA
- AUCUN avec RSA
- SHA1avec RSA
- SHA256avec RSA
- SHA384avec RSA
- SHA512avec RSA
Il est recommandé de vérifier la version de Java qui s'exécute sur le serveur Finesse pour vérifier quels algorithmes sont pris en charge dans cette version. La version peut être vérifiée à partir de l'accès racine à l'aide de cette commande : java-version
Si un certificat est fourni avec une signature autre que celles énumérées ci-dessus, Finesse ne peut pas utiliser le certificat pour créer une connexion TLS au serveur d'hébergement. Cela inclut les certificats signés avec un type de signature pris en charge mais qui ont été émis par les autorités de certification qui ont leurs propres certificats intermédiaires et racine signés avec autre chose.
Si vous regardez une capture de paquets, Finesse ferme la connexion avec une alerte fatale : Erreur de certificat inconnu, comme illustré dans l'image.
À ce stade, il est nécessaire de vérifier les certificats présentés par le serveur d'hébergement et de rechercher des algorithmes de signature non pris en charge. Il est courant de voir RSASSA-PSS comme l'algorithme de signature problématique :
Si un certificat de la chaîne est signé avec RSASSA-PSS, la connexion échoue. Dans ce cas, la capture de paquets montre que l'autorité de certification racine utilise RSASSA-PSS pour son propre certificat :
Solution
Pour résoudre ce problème, un nouveau certificat doit être émis par un fournisseur d'autorité de certification qui utilise uniquement l'un des types de signature SunMSCAPI pris en charge répertoriés dans toute la chaîne de certificats comme expliqué précédemment.
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)