Dépannez le " d'erreur de finesse ; SSLPeerUnverifiedException" ; pour des instruments hébergés sur les serveurs Ca-signés

Introduction

Ce document décrit les étapes pour dépanner le scénario où un Autorité de certification (CA) - la chaîne de certificat signé est téléchargée à la finesse pour un web server externe qui héberge un instrument mais l'instrument ne charge pas quand vous ouvrez une session à la finesse et vous voyez l'erreur « SSLPeerUnverifiedException ».

Contribué par Gino Schweinsberger, ingénieur TAC Cisco.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Certificats SSL
• Gestion de finesse
• Gestion de Windows Server
• Analyse de capture de paquet avec Wireshark

Composants utilisés

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

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Ce sont les conditions pour que l'erreur se produise :

• Supposez que chaîne de confiance de certificat est téléchargé à la finesse
• Assurez-vous que les serveurs corrects/services ont été redémarrés
• Supposez que l'instrument a été ajouté à l'affichage de finesse avec un URL HTTPS et que l'URL est accessible

C'est l'erreur observée quand l'agent ouvre une session à la finesse :

« Il y avait des questions rendant cet instrument. javax.net.ssl.SSLPeerUnverifiedException : pair non authentifié »

Problèmes

Scénario 1 : Le serveur principal négocie le TLS unsecure

Quand le serveur de finesse fait une demande de connexion au serveur principal, la finesse Tomcat annonce une liste de chiffrements de cryptage qu'elle prend en charge.

Quelques chiffrements ne sont pas dus pris en charge aux failles de la sécurité,

Si le serveur principal sélectionne l'un ou l'autre 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 éphémères faibles de Diffie-Hellman quand il négocie la connexion, et la vulnérabilité d'embouteillage fait à ceux-ci un mauvais choix pour des connexions de TLS.

Suivez le processus de prise de contact de TLS dans une capture de paquet pour voir quel chiffrement est négocié.

1. La finesse présente sa liste de chiffrements pris en charge dans l'étape de client bonjour :

2. Pour cette connexion TLS_DHE_RSA_WITH_AES_256_CBC_SHA a été sélectionné par le serveur principal pendant l'étape de serveur bonjour parce que c'est plus élevé sur sa liste de chiffrements préférés.

3. La finesse envoie un vigilant mortel et finit la connexion :

Solution

Afin d'empêcher l'utilisation de ces chiffrements, le serveur principal doit être configuré pour donner à ceux-ci une faible priorité, ou ils doivent être retirés de la liste de chiffrements disponibles complètement. Ceci peut être fait sur des Windows Server avec l'éditeur de stratégie de groupe de Windows (gpedit.msc).

Remarque: Pour plus de détails sur les effets de l'embouteillage dans la finesse et l'utilisation du gpedit, contrôle :

Scénario 2 : Le certificat a un algorithme de signature sans support

Les autorités de certification de Windows Server peuvent employer de plus nouvelles normes de signature pour signer des Certificats. Même il offre la sécurité accrue que le SHA, l'adoption de ces normes en dehors de des Produits de Microsoft est basse et les administrateurs sont susceptibles de s'exécuter dans des problèmes d'interopérabilité.

La finesse Tomcat se fonde sur le fournisseur de Sécurité de SunMSCAPI de Javas pour activer le soutien des divers algorithmes de signature et des fonctions cryptographiques utilisés par Microsoft. Toutes les versions en cours de Javas (1.7, 1.8, et 1.9) prennent en charge seulement ces algorithmes de signature :

• MD5withRSA
• MD2withRSA
• NONEwithRSA
• SHA1withRSA
• SHA256withRSA
• SHA384withRSA
• SHA512withRSA

C'est une bonne idée de vérifier la version de Java qui fonctionne sur le serveur de finesse pour confirmer quels algorithmes sont pris en charge dans cette version. La version peut être vérifiée de l'accès de racine avec cette commande : Javas - version

Remarque: Pour plus de détails sur le fournisseur de SunMSCAPI de Javas référez-vous à https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunMSCAPI

Si un certificat est équipé de signature autre que ceux répertoriés ci-dessus, la finesse ne peut pas employer le certificat pour créer une connexion de TLS au serveur principal. Ceci inclut les Certificats qui sont signés avec un type pris en charge de signature mais a été émis par les autorités de certification qui font signer leur propres intermédiaire et certificats racine avec autre chose.

Si vous regardez une capture de paquet, la finesse ferme la connexion avec « une alerte mortelle : Délivrez un certificat la » erreur inconnue, suivant les indications de l'image.

En ce moment IS-IS nécessaire pour vérifier les Certificats présentés par le serveur principal et pour rechercher les algorithmes non vérifiés de signature. Il est commun pour voir RSASSA-PSS comme algorithme problématique de signature :

Si n'importe quel certificat dans la chaîne est signé avec RSASSA-PSS, la connexion échoue. Dans ce cas la capture de paquet prouve que la racine CA utilise RSASSA-PSS pour son propre certificat : 

Solution

Afin de résoudre ce problème, un nouveau certificat doit être délivré d'un fournisseur CA que seulement les utilisations une des types pris en charge de signature de SunMSCAPI ont répertorié dans tout la chaîne de certificat entière comme expliqué avant. 

Remarque: Pour plus de détails sur l'algorithme de signature RSASSA-PSS, voir le https://pkisolutions.com/pkcs1v2-1rsassa-pss/

Remarque: Cette question est dépistée dans le défaut CSCve79330