Dépannage de l'erreur Finesse « SSLPeerUncheckedException » pour les gadgets hébergés sur des serveurs signés CA

Introduction

Ce document décrit les étapes pour dépanner le scénario où 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 quand vous vous connectez à Finesse et vous voyez l'erreur "SSLPeerUncheckedException".

Contribution de Gino Schweinsberger, ingénieur du centre d'assistance technique 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 de certificats de confiance est téléchargée dans Finesse
• Assurez-vous que les serveurs/services corrects ont été redémarrés
• Supposons 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 :

« Des problèmes se sont produits lors du rendu de ce gadget. javax.net.ssl.SSLPeerUncheckedException : homologue non authentifié"

Problèmes

Scénario 1 : Le serveur d'hébergement négocie les TLS non sécurisés

Lorsque Finesse Server effectue une demande de connexion au serveur d'hébergement, Finesse Tomcat annonce une liste de chiffrements de chiffrement qu'il prend en charge.

Certains chiffrements 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 chiffrements, la connexion est refusée :

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Ces chiffrements sont connus pour utiliser des clés Diffie-Hellman éphémères faibles quand il négocie 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 chiffre est négocié.

1. Finesse présente sa liste de chiffrements pris en charge dans l'étape Client Hello :

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 ce chiffre est plus élevé dans sa liste de chiffrements préférés.

3. Finesse envoie une alerte Fatal et met fin à la connexion :

Solution

Afin d'empêcher l'utilisation de ces chiffrements, le serveur d'hébergement doit être configuré pour leur donner une faible priorité, ou ils doivent être complètement supprimés de la liste des chiffrements disponibles. Cela peut être fait sur un serveur Windows avec l'éditeur de stratégie de groupe Windows (gpedit.msc).

Note : Pour plus de détails sur les effets de Logjam dans Finesse et l'utilisation de gpedit, vérifiez :

Scénario 2 : Le certificat a 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. Bien qu'elle offre une sécurité supérieure à celle de 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 différents 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 les algorithmes de signature suivants :

• MD5avecRSA
• MD2avec RSA
• AUCUNavecRSA
• SHA1 avec RSA
• SHA256avec RSA
• SHA384avec RSA
• SHA512avec RSA

Il est conseillé 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 avec cette commande : java -version

Remarque : pour plus d'informations sur le fournisseur Java SunMSCAPI, consultez le site https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunMSCAPI

Si un certificat est fourni avec une signature autre que celles répertorié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 qui sont signés avec un type de signature pris en charge, mais qui ont été émis par des autorités de certification qui ont leurs propres certificats intermédiaires et racine signés avec un autre élément.

Si vous examinez une capture de paquets, Finesse ferme la connexion avec une « alerte fatale : Erreur « Certificate Unknown », 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 les 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. 

Remarque : pour plus d'informations sur l'algorithme de signature RSASSA-PSS, consultez le site https://pkisolutions.com/pkcs1v2-1rsassa-pss/

Note: Ce problème est suivi dans le défaut CSCve79330