Pour les partenaires
Vous êtes déjà partenaire?
ConnexionAvez-vous un compte?
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment configurer Cisco Unified Contact Center Express (UCCX) pour l'utilisation de certificats auto-signés et signés.
Avant de poursuivre les étapes de configuration décrites dans ce document, assurez-vous d'avoir accès à la page Administration du système d'exploitation (OS) pour ces applications :
Un administrateur doit également avoir accès au magasin de certificats sur les PC clients de l'agent et du superviseur.
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 UCCX Version 10.0+ contiennent le nom de domaine complet (FQDN), selon le cas. Ajoutez les serveurs DNS et un domaine au cluster UCCX avant de passer à 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 signature.
Les informations décrites dans ce document sont basées sur les composants matériels et logiciels suivants :
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.
Avec l'introduction de Finesse et CUIC co-résidentes, l'intégration entre UCCX et SocialMiner pour les e-mails et les discussions, et l'utilisation de MediaSense pour enregistrer, comprendre et installer des certificats via Finesse, la capacité à dépanner les problèmes de certificat est maintenant d'une importance cruciale.
Ce document décrit l'utilisation des certificats auto-signés et signés dans l'environnement de configuration UCCX qui couvre :
Les certificats, signés ou autosignés, doivent être installés sur les applications (serveurs) de la configuration UCCX, ainsi que sur les postes de travail des clients des agents et superviseurs.
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 de devoir 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.
Cette section décrit comment configurer UCCX pour l'utilisation de certificats auto-signés et signés.
Architecture de solution UCCX valide à partir de UCCX 11.0. Diagramme de communication HTTPS.
La méthode recommandée de gestion des certificats pour la configuration UCCX est d'utiliser des certificats signés. Ces certificats peuvent être signés par une autorité de certification interne ou une autorité de certification tierce connue.
Dans les principaux navigateurs, tels que Mozilla Firefox et Internet Explorer, les certificats racine des CA tierces 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 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 d'application de configuration UCCX par une autorité de certification tierce 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.
Effectuez ces étapes pour chaque noeud des applications UCCX Publisher and Subscriber, SocialMiner et MediaSense Publisher and Subscriber Administration :
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 :
Note: Laissez le champ Distribution dans le CSR comme nom de domaine complet du serveur.
Note: Le certificat « multiserveur (SAN)" est pris en charge pour UCCX à partir de la version 11.6. Cependant, le SAN doit inclure uniquement les noeuds UCCX 1 et 2. D'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 sur les noeuds :
Note: Si vous téléchargez les certificats racine et intermédiaire sur un éditeur (UCCX ou MediaSense), il doit être automatiquement répliqué sur l'abonné. Il n'est pas nécessaire de télécharger les certificats racine ou intermédiaire 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.
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 de confiance tomcat 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 de demande.
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 l'ECDSA, reportez-vous à la section Informations connexes du lien pour comprendre et configurer les certificats ECDSA.
Tous les certificats utilisés dans la configuration UCCX sont préinstallés sur les applications de configuration et sont autosignés. Ces certificats auto-signés ne sont pas implicitement fiables 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 préinstallés auto-signés.
Pour chaque relation d'application, vous devez télécharger le certificat approprié et le télécharger vers l'application. Complétez ces étapes afin d'obtenir et de télécharger les certificats :
Afin d'installer des certificats auto-signés sur l'ordinateur client, utilisez une stratégie de groupe ou un gestionnaire de packages, ou installez-les individuellement dans le navigateur de chaque ordinateur agent.
Pour Internet Explorer, installez les certificats auto-signés côté client dans le magasin Autorités de certification racines de confiance.
Pour Mozilla Firefox, procédez comme suit :
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 réexécutées.
L'UCCX utilise l'interface de programmation d'applications (API) des services Web MediaSense REST pour deux raisons :
L'UCCX consomme l'API REST sur les noeuds d'administration MediaSense. Chaque cluster MediaSense peut en contenir deux au maximum. L'UCCX ne se connecte pas aux noeuds d'extension MediaSense via l'API REST. Les deux noeuds UCCX doivent utiliser l'API REST de MediaSense. Installez donc les deux certificats Tomcat de MediaSense sur les deux noeuds UCCX.
Téléchargez la chaîne de certificats signée ou auto-signée des serveurs MediaSense dans le magasin de clés UCCX tomcat-trust.
MediaSense consomme l'API REST des services Web Finesse afin d'authentifier les agents pour le gadget Recherche et Lecture MediaSense sur Finesse.
Le serveur MediaSense configuré sur la disposition XML Finesse du gadget Rechercher et lire doit utiliser l'API REST Finesse. Installez donc les deux certificats Tomcat UCCX sur ce noeud MediaSense.
Téléchargez la chaîne de certificats signée ou auto-signée des serveurs UCCX dans le magasin de clés MediaSense tomcat-trust.
L'UCCX consomme 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 avertis par le service de notification de SocialMiner. Installez donc le certificat Tomcat de SocialMiner sur les deux noeuds UCCX.
Téléchargez la chaîne de certificats signée ou auto-signée du serveur SocialMiner vers le magasin de clés UCCX tomcat-trust.
Le certificat client AppAdmin UCCX est utilisé pour l'administration du système UCCX. Afin d'installer le certificat AppAdmin UCCX pour les administrateurs UCCX, sur l'ordinateur client, accédez à https://<UCCX FQDN>/appadmin/main pour chacun des noeuds UCCX et installez le certificat via le navigateur.
Les services Web UCCX sont utilisés pour la livraison de contacts de discussion aux navigateurs clients. Afin d'installer le certificat UCCX Platform pour les agents et superviseurs UCCX, sur l'ordinateur client, accédez à https://<UCCX FQDN>/appadmin/main pour chacun des noeuds UCCX et installez le certificat via le navigateur.
Le service de notification CCX est utilisé par Finesse, UCCX et CUIC afin d'envoyer des informations en temps réel au bureau client via le protocole XMPP (Extensible Messaging and Presence Protocol). Il est utilisé pour les communications Finesse en temps réel ainsi que pour CUIC Live Data.
Afin d'installer le certificat client du service de notification sur le PC des agents et superviseurs ou des utilisateurs de rapports qui utilisent les données en direct, accédez à https://<UCCX FQDN>:7443/ pour chacun des noeuds UCCX et installez le certificat via le navigateur.
Le certificat client Finesse est utilisé par les ordinateurs de bureau Finesse afin de se connecter à l'instance Finesse Tomcat aux fins 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 via les invites du navigateur.
Afin d'installer le certificat Finesse pour les administrateurs Finesse, sur le PC client, accédez à https://<UCCX FQDN>:8445/cfadmin pour chacun des noeuds UCCX et installez le certificat via les invites du navigateur.
Le certificat SocialMiner Tomcat doit être installé sur l'ordinateur client. Une fois qu'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 contact client ou de discussion.
Afin d'installer le certificat SocialMiner dans le navigateur, sur le PC client, accédez à https://<SocialMiner FQDN>/ et installez le certificat via les invites du navigateur.
Le certificat CUIC Tomcat 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 dans la page Web CUIC ou dans les gadgets du bureau.
Afin d'installer le certificat CUIC Tomcat dans le navigateur, sur le PC client, accédez à https://<UCCX FQDN>:8444/ et installez le certificat via les invites du navigateur.
Certificat CUIC Live Data (depuis 11.x)
Le CUIC utilise le service d'E/S du socket pour les données en direct du serveur principal. Ce certificat 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 données en direct ou qui utilisent les gadgets de données en direct dans Finesse.
Afin d'installer le certificat d'E/S du socket dans le navigateur, sur le PC client, accédez à https://<UCCX FQDN>:12015/ et installez le certificat via les invites du navigateur.
Si un script UCCX est conçu pour accéder à un emplacement sécurisé sur un serveur tiers (par exemple, Obtenir un document URL vers une URL HTTPS ou Passer un appel de repos vers une URL REST HTTPS), téléchargez la chaîne de certificats signée ou auto-signée du service tiers dans le magasin de clés UCCX tomcat-trust. Pour obtenir ce certificat, accédez à la page Administration UCCX OS et choisissez Télécharger le certificat.
Le moteur UCCX est configuré afin de rechercher dans le magasin de clés Tomcat de la plate-forme des chaînes de certificats tierces 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.
Toute la chaîne de certificats doit être téléchargée sur 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.
Après avoir terminé ces actions, redémarrez le moteur Cisco UCCX.
Afin de vérifier que tous les certificats sont installés correctement, vous pouvez tester les fonctionnalités 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.
Les agents Finesse UCCX ne peuvent pas se connecter avec l'erreur "ID utilisateur/mot de passe non valide« .
Unified CCX lève une exception “ SSLHandshakeException “ et ne parvient pas à établir une connexion avec Unified CM.
Le téléchargement d'un certificat signé par une autorité de certification affiche l'erreur « CSR SAN and Certificate SAN not match ».
L'autorité de certification a peut-être ajouté un autre domaine parent dans le champ des noms alternatifs de sujet de certificat (SAN). Par défaut, le routeur de service de contact aura les SAN suivants :
SubjectAltName [
example.com (dNSName)
hostname.example.com (nomNSN)
]
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 (nomNSN)
www.hostname.example.com (dNSName)
]
Ceci provoque l'erreur de non-correspondance du SAN.
Dans la section 'Subject Alternate Name (SAN)' de la page UCCX 'Generate Certificate Signing Request', générez le CSR avec un champ Parent Domain 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 Domaine parent est défini par défaut sur le domaine du serveur UCCX. Par conséquent, la valeur doit être supprimée explicitement pendant la configuration des paramètres du CSR.
Lorsque vous accédez à une page Web UCCX, MediaSense ou SocialMiner, vous recevez un message d'erreur.
« 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_INVALIDE
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. »
La version 58 de Chrome a introduit une nouvelle fonctionnalité de sécurité dans laquelle elle signale que le certificat d'un site Web n'est pas sécurisé si son nom commun (CN) n'est pas également inclus en tant que SAN.
Reportez-vous à la section « Supprimer la prise en charge de la correspondance commonName dans les certificats » dans Défauts et suppressions dans Chrome 58.