Guide de gestion des certificats de la solution UCCX

Introduction

Ce document décrit comment configurer Cisco Unified Contact Center Express (UCCX) pour l'utilisation de certificats auto-signés et signés.

Conditions préalables

Conditions requises

Avant de poursuivre les étapes de configuration décrites dans ce document, vérifiez que vous avez accès à la page Administration du système d'exploitation (OS) pour ces applications :

• UCCX 
• SocialMiner
• MediaSense

Un administrateur doit également avoir accès au magasin de certificats sur les PC client de l'agent et du superviseur.

FQDN, DNS et domaines

Tous les serveurs de la configuration UCCX doivent être installés avec des serveurs DNS (Domain Name System) et des noms de domaine. Il est également nécessaire que les agents, les superviseurs et les administrateurs accèdent aux applications de configuration UCCX via le nom de domaine complet (FQDN).

UCCX version 10.0+ nécessite que le nom de domaine et les serveurs DNS soient renseignés lors de l'installation. Les certificats générés par le programme d'installation d'UCCX version 10.0+ contiennent le nom de domaine complet (FQDN) approprié. Ajoutez les serveurs DNS et un domaine au cluster UCCX avant de procéder à la mise à niveau vers UCCX version 10.0+.

Si le domaine change ou est renseigné pour la première fois, les certificats doivent être régénérés. Après avoir ajouté le nom de domaine à la configuration du serveur, régénérez tous les certificats Tomcat avant de les installer sur les autres applications, dans les navigateurs clients ou lors de la génération de la demande de signature de certificat (CSR) pour la signature.

Components Used

Les informations décrites dans ce document sont basées sur les composants matériels et logiciels suivants :

• Services Web UCCX
• Service de notification UCCX
• Plate-forme UCCX Tomcat
• Cisco Finesse Tomcat
• Cisco Unified Intelligence Center (CUIC) Tomcat
• SocialMiner Tomcat
• Services Web MediaSense

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. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

Avec l'introduction de Finesse et CUIC co-résidents, l'intégration entre UCCX et SocialMiner pour les e-mails et les chats, et l'utilisation de MediaSense afin d'enregistrer, de comprendre et d'installer des certificats via Finesse, la capacité à dépanner les problèmes de certificats est maintenant cruciale.

Ce document décrit l'utilisation des certificats auto-signés et signés dans l'environnement de configuration UCCX qui couvre :

• Services de notification UCCX
• Services Web UCCX
• Scripts UCCX
• Corésident Finesse
• CUIC co-résident (données en direct et rapports historiques)
• MediaSense (enregistrement et étiquetage Finesse)
• SocialMiner (chat)

Les certificats, signés ou auto-signés, doivent être installés à la fois sur les applications (serveurs) de la configuration UCCX, ainsi que sur les postes de travail client de l'agent et du superviseur.

Dans Unified Communications Operating System (UCOS) 10.5, des certificats multiserveurs ont été ajoutés afin qu'un seul CSR puisse être généré pour un cluster au lieu d'avoir à signer un certificat individuel pour chaque noeud du cluster. Ce type de certificat n'est explicitement pas pris en charge pour UCCX, MediaSense et SocialMiner.

Configuration

Cette section décrit comment configurer UCCX pour l'utilisation de certificats auto-signés et signés.

Schéma de configuration

Architecture de la solution UCCX valide depuis UCCX 11.0. Diagramme de communication HTTPS.

Certificats signés

La méthode recommandée de gestion des certificats pour la configuration UCCX consiste à tirer parti des certificats signés. Ces certificats peuvent être signés par une autorité de certification interne ou par une autorité de certification tierce bien connue.

Dans les principaux navigateurs, tels que Mozilla Firefox et Internet Explorer, les certificats racine des autorités de certification tierces bien connues sont installés par défaut. Les certificats des applications de configuration UCCX qui sont signés par ces autorités de certification sont approuvés par défaut, car leur chaîne de certificats se termine par un certificat racine qui est déjà installé dans le navigateur.

Le certificat racine d'une autorité de certification interne peut également être préinstallé dans le navigateur client via une stratégie de groupe ou une autre configuration actuelle.

Vous pouvez choisir de faire signer les certificats de l'application de configuration UCCX par une autorité de certification tierce bien connue ou par une autorité de certification interne en fonction de la disponibilité et de la préinstallation du certificat racine pour les autorités de certification dans le navigateur client.

Installer les certificats d'application Tomcat signés

Effectuez ces étapes pour chaque noeud des applications UCCX Publisher and Subscriber, SocialMiner, MediaSense Publisher and Subscriber Administration :

1. Accédez à la page OS Administration et choisissez Security > Certificate Management.
2. Cliquez sur Generate CSR.
3. Dans la liste déroulante Certificate List, choisissez tomcat comme nom de certificat et cliquez sur Generate CSR.
4. Accédez à Security > Certificate Management et choisissez Download CSR.
5. Dans la fenêtre contextuelle, choisissez tomcat dans la liste déroulante et cliquez sur Download CSR.

Envoyez le nouveau CSR à l'autorité de certification tierce ou signez-le avec une autorité de certification interne, comme décrit précédemment. Ce processus doit produire les certificats signés suivants :

• Certificat racine pour l'autorité de certification
• Certificat d'application éditeur UCCX
• Certificat de demande d'abonné UCCX
• Certificat d'application SocialMiner
• Certificat d'application MediaSense Publisher
• Certificat d'application d'abonné MediaSense

Note: Laissez le champ Distribution dans le CSR comme FQDN du serveur.

Note: Le certificat « Multi-server (SAN) » est pris en charge pour UCCX à partir de la version 11.6. Cependant, le SAN doit inclure les noeuds UCCX 1 et 2 uniquement. Les autres serveurs, tels que SocialMiner, ne doivent pas être inclus dans le SAN d'UCCX.

Note: UCCX prend uniquement en charge les longueurs de clé de certificat de 1 024 et 2 048 bits.

Exécutez ces étapes sur chaque serveur d'applications afin de télécharger le certificat racine et le certificat d'application vers les noeuds :

Note: Si vous téléchargez les certificats racine et intermédiaires sur un éditeur (UCCX ou MediaSense), ils doivent être automatiquement répliqués sur l'abonné. Il n'est pas nécessaire de télécharger les certificats racine ou intermédiaires sur les autres serveurs non éditeurs de la configuration si tous les certificats d'application sont signés via la même chaîne de certificats.

1. Accédez à la page OS Administration et choisissez Security > Certificate Management.
2. Cliquez sur Upload Certificate.
3. Téléchargez le certificat racine et choisissez tomcat-trust comme type de certificat.
4. Cliquez sur Upload File.
5. Cliquez sur Upload Certificate.
6. Téléchargez le certificat d'application et choisissez tomcat comme type de certificat.
7. Cliquez sur Upload File.

   Note: Si une autorité de certification subordonnée signe le certificat, téléchargez le certificat racine de l'autorité de certification subordonnée en tant que certificat tomcat-trust au lieu du certificat racine. Si un certificat intermédiaire est émis, téléchargez ce certificat dans le magasin tomcat-trust en plus du certificat d'application.

8. Une fois terminé, redémarrez ces applications :
   • Éditeur et abonné Cisco MediaSense
   • Cisco SocialMiner
   • Éditeur et abonné Cisco UCCX

Note: Lorsque vous utilisez UCCX, MediaSense et SocialMiner 11.5 et versions ultérieures, il existe un nouveau certificat appelé tomcat-ECDSA. Lorsque vous téléchargez un certificat tomcat-ECDSA signé sur le serveur, téléchargez le certificat d'application en tant que certificat tomcat-ECDSA et non en tant que certificat tomcat. Pour plus d'informations sur ECDSA, reportez-vous à la section Informations associées pour le lien permettant de comprendre et de configurer les certificats ECDSA.

Certificats auto-signés

Installation Sur Des Serveurs Périphériques

Tous les certificats utilisés dans la configuration UCCX sont préinstallés sur les applications de configuration et sont auto-signés. Ces certificats auto-signés ne sont pas implicitement approuvés lorsqu'ils sont présentés à un navigateur client ou à une autre application de configuration. Bien qu'il soit recommandé de signer tous les certificats dans la configuration UCCX, vous pouvez utiliser les certificats auto-signés préinstallés.

Pour chaque relation d'application, vous devez télécharger le certificat approprié et le charger dans l'application. Complétez ces étapes afin d'obtenir et de télécharger les certificats :

1. Accédez à la page Application OS Administration et choisissez Security > Certificate Management.
   
   
2. Cliquez sur le fichier certificate.pem approprié et choisissez Download :
   
   
   
   
   
   
3. Afin de télécharger un certificat sur l'application appropriée, accédez à la page OS Administration et choisissez Security > Certificate Management.
4. Cliquez sur Télécharger le certificat / Chaîne de certificats :
   
   
5. Une fois terminé, redémarrez ces serveurs :
   
   
   • Éditeur et abonné Cisco MediaSense
   • Cisco SocialMiner
   • Éditeur et abonné Cisco UCCX

Afin d'installer des certificats auto-signés sur l'ordinateur client, utilisez une stratégie de groupe ou un gestionnaire de package, ou installez-les individuellement dans le navigateur de chaque PC agent.

Pour Internet Explorer, installez les certificats auto-signés côté client dans le magasin Autorités de certification racine de confiance.

Pour Mozilla Firefox, procédez comme suit :

1. Accédez à Outils > Options.
2. Cliquez sur l'onglet Advanced.
3. Cliquez sur Afficher les certificats.
4. Accédez à l'onglet Serveurs.
5. Cliquez sur Ajouter une exception.

Régénération des certificats auto-signés

Si les certificats auto-signés expirent, ils devront être régénérés et les étapes de configuration de l'installation sur les serveurs périphériques devront être exécutées à nouveau.

1. Accéder à l'application Administration du SE et choisissez Sécurité > Gestion des certificats.
2. Cliquez sur le certificat approprié et choisissez Régénérer. 
3. Le serveur dont le certificat a été régénéré doit être redémarré.
4. Pour chaque relation d'application, vous devez télécharger le certificat approprié et le télécharger vers l'application en suivant les étapes de configuration de Installation sur des serveurs périphériques.

Intégration et configuration client

UCCX vers MediaSense

L'UCCX utilise l'API REST des services Web MediaSense à deux fins :

• Pour vous abonner aux notifications de nouveaux enregistrements qui sont appelés sur Cisco Unified Communications Manager (CUCM).
• Afin d'étiqueter les enregistrements des agents UCCX avec les informations d'agent et de file d'attente de service de contact (CSQ).

UCCX utilise l'API REST sur les noeuds d'administration MediaSense. Il y a un maximum de deux dans chaque cluster MediaSense. L'UCCX ne se connecte pas via l'API REST aux noeuds d'extension MediaSense. Les deux noeuds UCCX doivent utiliser l'API REST MediaSense. Par conséquent, installez les deux certificats MediaSense Tomcat sur les deux noeuds UCCX.

Téléchargez la chaîne de certificats signée ou auto-signée des serveurs MediaSense vers le keystore tomcat-trust UCCX.

MediaSense-to-Finesse

MediaSense utilise l'API REST des services Web Finesse afin d'authentifier les agents pour le gadget MediaSense Search and Play sur Finesse.

Le serveur MediaSense configuré sur la disposition XML Finesse pour le gadget Search and Play doit utiliser l'API REST Finesse. Installez donc les deux certificats UCCX Tomcat sur ce noeud MediaSense.

Téléchargez la chaîne de certificats signée ou auto-signée des serveurs UCCX vers le keystore tomcat-trust MediaSense.

UCCX vers SocialMiner

UCCX utilise les API REST et Notification de SocialMiner afin de gérer les contacts et la configuration des e-mails. Les deux noeuds UCCX doivent utiliser l'API REST de SocialMiner et être notifiés par le service de notification de SocialMiner. Installez donc le certificat SocialMiner Tomcat sur les deux noeuds UCCX.

Téléchargez la chaîne de certificats signée ou auto-signée du serveur SocialMiner vers le keystore tomcat-trust UCCX.

Certificat client AppAdmin UCCX

Le certificat client AppAdmin UCCX est utilisé pour l'administration du système UCCX. Afin d'installer le certificat UCCX AppAdmin pour les administrateurs UCCX, sur le PC client, accédez à https://<UCCX FQDN>/appadmin/main pour chacun des noeuds UCCX et installez le certificat via le navigateur.

Certificat client de la plate-forme UCCX

Les services Web UCCX sont utilisés pour la transmission de contacts de discussion aux navigateurs clients. Afin d'installer le certificat de la plate-forme UCCX pour les agents et les superviseurs UCCX, sur le PC client, accédez à https://<UCCX FQDN>/appadmin/main pour chacun des noeuds UCCX et installez le certificat via le navigateur.

Certificat client du service de notification

Le service de notification CCX est utilisé par Finesse, UCCX et CUIC afin d'envoyer des informations en temps réel au bureau du client via le protocole XMPP (Extensible Messaging and Presence Protocol). Il est utilisé pour la communication Finesse en temps réel ainsi que pour les données CUIC Live.

Afin d'installer le certificat client du service de notification sur le PC des agents et superviseurs ou des utilisateurs de rapports qui utilisent Live Data, accédez à https://<UCCX FQDN>:7443/ pour chacun des noeuds UCCX et installez le certificat via le navigateur.

Certificat client Finesse

Le certificat client Finesse est utilisé par les bureaux Finesse afin de se connecter à l'instance Finesse Tomcat pour les besoins de la communication de l'API REST entre le bureau et le serveur Finesse co-résident.

Afin d'installer le certificat Finesse pour les agents et les superviseurs, sur le PC client, accédez à https://<UCCX FQDN>:8445/ pour chacun des noeuds UCCX et installez le certificat à l'aide des invites du navigateur.

Afin d'installer le certificat Finesse pour les administrateurs Finesse, sur l'ordinateur client, accédez à https://<UCCX FQDN>:8445/cfadmin pour chacun des noeuds UCCX et installez le certificat via les invites du navigateur.

Certificat client SocialMiner

Le certificat SocialMiner Tomcat doit être installé sur l'ordinateur client. Lorsqu'un agent accepte une demande de discussion, le gadget de discussion est redirigé vers une URL qui représente la salle de discussion. Cette salle de discussion est hébergée par le serveur SocialMiner et contient le client ou le contact de discussion.

Afin d'installer le certificat SocialMiner dans le navigateur, sur le PC client, naviguez vers https://<FQDN SocialMiner>/ et installez le certificat à travers les invites du navigateur.

Certificat client CUIC

Le certificat Tomcat CUIC doit être installé sur l'ordinateur client pour les agents, les superviseurs et les utilisateurs de rapports qui utilisent l'interface Web CUIC pour les rapports historiques ou les rapports de données en direct, soit dans la page Web CUIC, soit dans les gadgets du bureau.

Afin d'installer le certificat CUIC Tomcat dans le navigateur, sur l'ordinateur client, naviguez vers https://<UCCX FQDN>:8444/ et installez le certificat à travers les invites du navigateur.

Certificat de données en direct CUIC (depuis 11.x)

Le CUIC utilise le service d'E/S de socket pour les données actives du back-end. Ce certificat doit être installé sur l'ordinateur client pour les agents, superviseurs et utilisateurs de rapports qui utilisent l'interface Web CUIC pour Live Data ou qui utilisent les gadgets Live Data dans Finesse.

Afin d'installer le certificat d'E/S de socket dans le navigateur, sur le PC client, accédez à https://<UCCX FQDN>:12015/ et installez le certificat à l'aide des invites du navigateur.

Applications tierces accessibles à partir de scripts

Si un script UCCX est conçu pour accéder à un emplacement sécurisé sur un serveur tiers (par exemple, l'étape Get URL Document to an HTTPS URL ou Make Rest Call to an HTTPS REST URL), téléchargez la chaîne de certificats signée ou auto-signée du service tiers vers le magasin de clés tomcat-trust d'UCCX. Afin d'obtenir ce certificat, accédez à la page Administration du système d'exploitation UCCX et choisissez Upload Certificate.

Le moteur UCCX est configuré afin de rechercher les chaînes de certificats tierces dans le keystore Tomcat de la plate-forme lorsqu'elles sont présentées avec ces certificats par des applications tierces lorsqu'elles accèdent à des emplacements sécurisés via des étapes de script.

La chaîne de certificats complète doit être téléchargée vers le keystore Tomcat de la plate-forme, accessible via la page Administration du système d'exploitation, car le keystore Tomcat ne contient aucun certificat racine par défaut.

Une fois ces actions effectuées, redémarrez le moteur Cisco UCCX.

Vérification

Afin de vérifier que tous les certificats sont installés correctement, vous pouvez tester les fonctionnalités qui sont décrites dans cette section. Si aucune erreur de certificat n'apparaît et que toutes les fonctionnalités fonctionnent correctement, les certificats sont installés correctement.

• Configurez Finesse de sorte qu'il enregistre automatiquement un agent via le workflow. Une fois qu'un appel est traité par l'agent, utilisez l'application MediaSense Search and Play afin de trouver l'appel. Vérifiez que l'appel comporte les balises agent, CSQ et team attachées aux métadonnées d'enregistrement dans MediaSense.
• Configurez Agent Web Chat via SocialMiner. Injecter un contact de discussion via le formulaire Web. Vérifiez que l'agent reçoit la bannière pour accepter le contact de discussion et qu'une fois le contact de discussion accepté, le formulaire de discussion se charge correctement et l'agent peut à la fois recevoir et envoyer des messages de discussion.
• Tentative de connexion d'un agent via Finesse. Vérifiez qu'aucun avertissement de certificat n'apparaît et que la page Web ne vous invite pas à installer des certificats dans le navigateur. Vérifiez que l'agent peut changer d'état correctement et qu'un nouvel appel dans UCCX lui est correctement présenté.
• Après avoir configuré les gadgets Live Data dans la présentation du bureau Finesse de l'agent et du superviseur, connectez-vous à un agent, un superviseur et un utilisateur de rapports. Vérifiez que les gadgets Live Data se chargent correctement, que les données initiales sont renseignées dans le gadget et que les données sont actualisées lorsque les données sous-jacentes changent.
• Essayez de vous connecter à partir d'un navigateur à l'URL AppAdmin sur les deux noeuds UCCX. Vérifiez qu'aucun avertissement de certificat ne s'affiche lorsque vous y êtes invité.

Dépannage

Problème - ID utilisateur/mot de passe non valide

Les agents UCCX Finesse ne peuvent pas se connecter avec l'erreur "ID utilisateur/mot de passe non valide".

Causes

Unified CCX lève une exception « SSLHandshakeException » et ne parvient pas à établir une connexion avec Unified CM.

Solution

• Vérifiez que le certificat Unified CM Tomcat n'a pas expiré.
• Assurez-vous que l'une des extensions de certificat téléchargées dans Unified CM est marquée comme critique :
       Utilisation de la clé X509v3 (OID - 2.5.29.15)
       Contraintes de base X509v3 (OID - 2.5.29.19)
  Si vous marquez d'autres postes comme critiques, la communication échoue entre Unified CCX et Unified CM en raison de l'échec de la vérification du certificat Unified CM.

Problème - Le SAN CSR et le SAN de certificat ne correspondent pas

Le téléchargement d'un certificat signé par une autorité de certification affiche l'erreur « CSR SAN and Certificate SAN does not match ».

Causes

L'autorité de certification a peut-être ajouté un autre domaine parent dans le champ de certificat Noms alternatifs de l'objet (SAN). Par défaut, le CSR dispose des SAN suivants :

SubjectAltName [
   example.com (dNSName)
   hostname.example.com (dNSName)
]

Les autorités de certification peuvent renvoyer un certificat avec un autre SAN ajouté au certificat : www.hostname.example.com. Le certificat aura un SAN supplémentaire dans ce cas :

SubjectAltName [
   example.com (dNSName)
   hostname.example.com (dNSName)

   www.hostname.example.com (dNSName)
]

Cela entraîne une erreur de non-concordance SAN.

Solution

Dans la section « Subject Alternate Name (SANs) » de la page « Generate Certificate Signing Request » d'UCCX, générez le CSR avec un champ de domaine parent vide. De cette manière, le CSR n'est pas généré avec un attribut SAN, l'autorité de certification peut formater les SAN et il n'y aura pas de non-correspondance d'attribut SAN lorsque vous téléchargez le certificat vers UCCX. Notez que le champ Parent Domain est défini par défaut sur le domaine du serveur UCCX, de sorte que la valeur doit être explicitement supprimée lorsque les paramètres du CSR sont configurés. 

Problème - NET::ERR_CERT_COMMON_NAME_INVALID

Lorsque vous accédez à une page Web UCCX, MediaSense ou SocialMiner, un message d'erreur s'affiche.

"Votre connexion n'est pas privée.

Les pirates peuvent tenter de voler vos informations à <Server_FQDN> (par exemple, des mots de passe, des messages ou des cartes de crédit). NET::ERR_CERT_COMMON_NAME_INVALID

Ce serveur n'a pas pu prouver qu'il s'agit de <Server_FQDN>; son certificat de sécurité provient de [missing_subjectAltName]. Cela peut être dû à une mauvaise configuration ou à un pirate qui intercepte votre connexion."

Causes

Chrome version 58 introduit une nouvelle fonctionnalité de sécurité où il signale que le certificat d'un site Web n'est pas sécurisé si son nom commun (CN) n'est pas également inclus comme un SAN.

Solution

• Vous pouvez naviguer vers Advanced > Proceed to <Server_FQDN> (unsafe) afin de continuer vers le site et d'accepter l'erreur de certificat.
• Vous pouvez éviter l'erreur avec les certificats signés par l'autorité de certification. Lorsque vous générez un CSR, le FQDN du serveur est inclus en tant que SAN. L'autorité de certification peut signer le CSR et, après avoir téléchargé le certificat signé sur le serveur, le nom de domaine complet (FQDN) du certificat du serveur sera indiqué dans le champ SAN afin que l'erreur ne soit pas présentée.

Plus d'informations

Reportez-vous à la section « Supprimer la prise en charge de la correspondance commonName dans les certificats » dans Dédirections et suppressions dans Chrome 58.

Défauts du certificat

• ID de bogue Cisco CSCvb46250 - UCCX : Impact du certificat ECDSA Tomcat sur Finesse Live Data
• ID de bogue Cisco CSCvb5850 - Impossible de se connecter à SocialMiner avec tomcat et tomcat-ECDSA signés par l'autorité de certification RSA
• ID de bogue Cisco CSCvd56174 - UCCX : Échec de connexion de l'agent Finesse en raison de SSLHandshakeException
• ID de bogue Cisco CSCuv89545 - Vulnérabilité Finesse Logjam

Informations connexes

• Comprendre les certificats ECDSA dans une solution UCCX
• Prise en charge SHA 256 pour UCCX
• Exemple de configuration de certificats signés et auto-signés UCCX
• Support et documentation techniques - Cisco Systems