Créer de nouveaux certificats à partir de certificats CA signés

Introduction

Ce document décrit comment régénérer les certificats signés par une autorité de certification (CA) dans Cisco Unified Communications Manager (CUCM).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Outil de surveillance en temps réel (RTMT)
• Certificats CUCM

Composants utilisés

• CUCM versions 14.x et 15.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.

Impact commercial

Ce tableau affiche l'impact commercial de chaque renouvellement de certificat dans votre opération. Examinez attentivement les informations. Renouveler les certificats requis après les heures d'ouverture ou pendant les périodes de silence, en fonction du niveau de risque de chaque certificat.

Informations de pré-vérification

Remarque : Pour la régénération de certificat auto-signé, référez-vous au Guide de régénération de certificat. Pour la régénération de certificat multi-SAN signé par l'autorité de certification, reportez-vous au Guide de régénération de certificat multi-SAN

Chaque type de demande de signature de certificat (CSR) a différentes utilisations de clé et celles-ci sont requises dans le certificat signé. Le Guide de sécurité inclut un tableau avec les utilisations de clés requises pour chaque type de certificat.

Pour modifier les paramètres d'objet (emplacement, état, unité d'organisation, etc.), exécutez cette commande :

• set web-security orgunit orgname locality state [pays] [nomhôte secondaire] 

Le certificat Tomcat est régénéré automatiquement après l'exécution de la commande set web-security. Le nouveau certificat auto-signé n'est pas appliqué, sauf si le service Tomcat est redémarré. Reportez-vous à ces guides pour plus d'informations sur cette commande :

• Guide de référence de la ligne de commande
• Lien vers les étapes de la communauté Cisco
• Vidéo

Configuration et régénération des certificats

Les étapes de régénération des certificats de noeud unique dans un cluster CUCM signé par une autorité de certification sont répertoriées pour chaque type de certificat. Il n'est pas nécessaire de régénérer tous les certificats du cluster s'ils n'ont pas expiré. 

Certificat Tomcat 

Avertissement : L'expiration du certificat Tomcat ou un processus incorrect dans le renouvellement peut entraîner : Si la connexion SSO échoue, les téléphones ne peuvent pas accéder aux services HTTP hébergés sur le noeud CUCM, tels que le répertoire d'entreprise. CUCM peut présenter divers problèmes Web, tels que l'impossibilité d'accéder aux pages de service à partir d'autres noeuds du cluster. Problèmes de mobilité des postes (EM) ou de mobilité des postes entre clusters. Expressway Traversal Zone down (TLS Verify est activé). Si Unified Contact Center Express (UCCX) est intégré, en raison d'une modification de sécurité de CCX, il est nécessaire d'avoir téléchargé le certificat Tomcat de CUCM (auto-signé) ou le certificat racine et intermédiaire de Tomcat (pour CA signé) dans le magasin UCCX tomcat-trust, car cela affecte les connexions de bureau Finesse.

Attention : vérifiez que l'authentification unique est désactivée dans le cluster (CM Administration > System > SAML Single Sign-On). Si l'authentification unique est activée, elle doit être désactivée, puis activée une fois le processus de régénération de certificat Tomcat terminé.

Sur tous les noeuds (CallManager et IM&P) du cluster :

Étape 1. Accédez à Cisco Unified OS Administration > Security > Certificate Management > Find and verify the expiration date of the Tomcat certificate.

Étape 2. Cliquez sur Generate CSR > Certificate Purpose : tomcat. Sélectionnez les paramètres souhaités pour le certificat, puis cliquez sur Générer. Attendez que le message de réussite s'affiche et cliquez sur Fermer.

Étape 3. Téléchargez le CSR. Cliquez sur Download CSR, sélectionnez Certificate Purpose : tomcat, puis cliquez sur Télécharger.

Étape 4. Envoyez le CSR à l’autorité de certification.

Étape 5. L’autorité de certification renvoie deux fichiers ou plus pour la chaîne de certificats signée. Téléchargez les certificats dans l'ordre suivant :

• Certificat d'autorité de certification racine comme tomcat-trust. Accédez à Certificate Management > Upload certificate > Certificate Purpose : tomcat-trust. Définissez la description du certificat et parcourez le fichier de certificat racine.
• Certificat intermédiaire comme tomcat-trust (facultatif). Accédez à Certificate Management > Upload certificate > Certificate Purpose : tomcat-trust. Définissez la description du certificat et parcourez le fichier de certificat intermédiaire.

Remarque : Certaines autorités de certification ne fournissent pas de certificat intermédiaire. Si seul le certificat racine a été fourni, cette étape peut être omise.

• Certificat CA signé en tant que tomcat. Accédez à Certificate Management > Upload certificate > Certificate Purpose : tomcat. Définissez la description du certificat et parcourez le fichier de certificat signé par l'autorité de certification pour le noeud CUCM actuel.

Remarque : À ce stade, CUCM compare le CSR et le certificat CA signé chargé. Si les informations correspondent, le CSR disparaît et le nouveau certificat signé par l'autorité de certification est téléchargé. Si vous recevez un message d'erreur après le téléchargement du certificat, reportez-vous à la section Messages d'erreur courants du téléchargement du certificat.

Étape 6. Pour que le nouveau certificat soit appliqué au serveur, le service Cisco Tomcat doit être redémarré via l'interface de ligne de commande (commencez par Publisher, puis les abonnés, un par un). Utilisez la commande utils service restart Cisco Tomcat.

Pour valider que le certificat Tomcat est maintenant utilisé par CUCM, accédez à la page Web du noeud et sélectionnez Informations sur le site (icône de verrouillage) dans le navigateur. Cliquez sur l'option de certificat et vérifiez la date du nouveau certificat.

Certificat IPSec 

Avertissement : L'expiration du certificat IPsec ou un processus incorrect dans le renouvellement peut entraîner : Le système de reprise après sinistre (DRS)/le cadre de reprise après sinistre (DRF) ne peut pas fonctionner correctement. Les tunnels IPsec vers la passerelle (GW) ou vers d'autres clusters CUCM ne fonctionnent pas.

Mise en garde : Une tâche de sauvegarde ou de restauration ne doit pas être active lorsque le certificat IPSec est régénéré.

Pour tous les noeuds (CallManager et IM&P) du cluster :

Étape 1. Accédez à Cisco Unified OS Administration > Security > Certificate Management > Find and verify the expiration date of the ipsec certificate.

Étape 2. Cliquez sur Generate CSR > Certificate Purpose : ipsec. Sélectionnez les paramètres souhaités pour le certificat, puis cliquez sur Générer. Attendez que le message de réussite s'affiche, puis cliquez sur Fermer.

Étape 3. Téléchargez le CSR. Cliquez sur Télécharger CSR. Sélectionnez Certificate Purpose ipsec et cliquez sur Download.

Étape 4. Envoyez le CSR à l’autorité de certification.

Étape 5. L’autorité de certification renvoie deux fichiers ou plus pour la chaîne de certificats signée. Téléchargez les certificats dans l'ordre suivant :

• Certificat d'autorité de certification racine comme ipsec-trust. Accédez à Certificate Management > Upload certificate > Certificate Purpose : ipsec-trust. Définissez la description du certificat et parcourez le fichier de certificat racine.
• Certificat intermédiaire comme ipsec-trust (facultatif). Accédez à Certificate Management > Upload certificate > Certificate Purpose : tomcat-trust. Définissez la description du certificat et parcourez le fichier de certificat intermédiaire.

Remarque : Certaines autorités de certification ne fournissent pas de certificat intermédiaire. Si seul le certificat racine a été fourni, cette étape peut être omise.

• Certificat signé par l'autorité de certification en tant qu'ipsec. Accédez à Certificate Management > Upload certificate > Certificate Purpose : ipsec. Définissez la description du certificat et parcourez le fichier de certificat signé par l'autorité de certification pour le noeud CUCM actuel.

Remarque : À ce stade, CUCM compare le CSR et le certificat CA signé chargé. Si les informations correspondent, le CSR disparaît et le nouveau certificat signé par l'autorité de certification est téléchargé. Si vous recevez un message d'erreur après le téléchargement du certificat, reportez-vous à la section Messages d'erreur courants du téléchargement du certificat< /strong>.

Étape 6. Pour que le nouveau certificat soit appliqué au serveur, les services requis doivent être redémarrés (uniquement si le service s’exécute et est actif). Naviguez jusqu’à l’adresse :

• Cisco Unified Serviceability > Outils > Control Center - Services réseau > Cisco DRF Master (Publisher)
• Cisco Unified Serviceability > Outils > Control Center - Services réseau > Cisco DRF Local (Éditeur et Abonnés)

Certificat CAPF

Avertissement : L'expiration du certificat CAPF ou un processus incorrect dans le renouvellement peut entraîner : Problèmes de configuration de l'authentification et du chiffrement pour les terminaux (sauf en mode CAPF en ligne et hors ligne), le VPN téléphonique, 802.1x et le proxy téléphonique. CTI, JTAPI et TAPI.

Remarque : pour déterminer si le cluster est en mode mixte, accédez à Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Non-Secure ; 1 == Mixed Mode).

Remarque : le service CAPF s'exécute uniquement dans le serveur de publication et c'est le seul certificat utilisé. Il n'est pas nécessaire d'obtenir les noeuds d'abonné signés par une autorité de certification, car ils ne sont pas utilisés. Si le certificat a expiré dans les Abonnés et que vous souhaitez éviter les alertes de certificats expirés, vous pouvez régénérer les certificats CAPF des abonnés en tant que certificats auto-signés. Pour plus d'informations, consultez Certificat CAPF auto-signé.

Dans l'éditeur :

Étape 1. Accédez à Cisco Unified OS Administration > Security > Certificate Management > Find and verify the expiration date of the CAPF certificate.

Étape 2. Cliquez sur Generate CSR > Certificate Purpose : CAPF. Sélectionnez les paramètres souhaités pour le certificat, puis cliquez sur Générer. Attendez que le message de réussite s'affiche et cliquez sur Fermer.

Étape 3. Téléchargez le CSR. Cliquez sur Télécharger CSR. Sélectionnez Certificate Purpose CAPF et cliquez sur Download.

Étape 4. Envoyez le CSR à l’autorité de certification.

Étape 5. L’autorité de certification renvoie deux fichiers ou plus pour la chaîne de certificats signée. Téléchargez les certificats dans l'ordre suivant :

• Certificat d'autorité de certification racine comme CAPF-trust. Accédez à Certificate Management > Upload certificate > Certificate Purpose : CAPF-trust. Définissez la description du certificat et parcourez le fichier de certificat racine.
• Certificat intermédiaire en tant que CAPF-trust (facultatif). Accédez à Certificate Management > Upload certificate > Certificate Purpose : CAPF-trust. Définissez la description du certificat et parcourez le fichier de certificat intermédiaire.

Remarque : Certaines autorités de certification ne fournissent pas de certificat intermédiaire. Si seul le certificat racine a été fourni, cette étape peut être omise.

• Certificat CA signé en tant que CAPF. Accédez à Certificate Management > Upload certificate > Certificate Purpose : CAPF. Définissez la description du certificat et parcourez le fichier de certificat signé par l'autorité de certification pour le noeud CUCM actuel.

Remarque : À ce stade, CUCM compare le CSR et le certificat CA signé chargé. Si les informations correspondent, le CSR disparaît et le nouveau certificat signé par l'autorité de certification est téléchargé. Si vous recevez un message d'erreur après le téléchargement du certificat, reportez-vous à la section Messages d'erreur courants du téléchargement du certificat.

Étape 6. Si le cluster est en mode mixte, mettez à jour la CTL avant le redémarrage des services : Jeton ou sans jeton. Si le cluster est en mode non sécurisé, ignorez cette étape et redémarrez le service.

Étape 7. Pour que le nouveau certificat soit appliqué au serveur, les services requis doivent être redémarrés (uniquement si le service s’exécute et est actif). Naviguez jusqu’à l’adresse :

• Cisco Unified Serviceability > Tools > Control Center - Network Services > Cisco Trust Verification Service (Tous les noeuds où le service est exécuté.)
• Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco TFTP (Tous les noeuds où le service s'exécute.)
• Cisco Unified Serviceability > Outils > Control Center - Services de fonctionnalités > Fonction proxy Cisco Certificate Authority (Éditeur)

Étape 8. Réinitialisez tous les téléphones :

• Accédez à Cisco Unified CM Administration > System > Enterprise Parameters > Reset. Une fenêtre contextuelle s'affiche avec l'instruction « Vous êtes sur le point de réinitialiser tous les périphériques du système ». Cette action ne peut pas être annulée. Continuer ? sélectionnez OK, puis cliquez sur Réinitialiser.

Remarque : Surveillez l'enregistrement des périphériques via RTMT. Une fois que tous les téléphones se sont réinscrits, vous pouvez passer au type de certificat suivant.

Certificat CallManager 

Avertissement : L'expiration du certificat du gestionnaire d'appels ou un processus incorrect dans le renouvellement peut entraîner : Problèmes d'enregistrement téléphonique. Les téléphones cryptés/authentifiés ne s’enregistrent pas. Le protocole TFTP (Trivial File Transfer Protocol) n'est pas approuvé (les téléphones n'acceptent pas les fichiers de configuration signés et/ou les fichiers ITL). Les liaisons SIP (Secure Session Initiation Protocol) ou les ressources multimédias (ponts de conférence, point de terminaison multimédia (MTP), codeurs XC, etc.) ne s'enregistrent pas et ne fonctionnent pas. La requête AXL échoue.

Mise en garde : Ne régénérez pas CallManager et les certificats TVS en même temps. Cela entraîne une non-correspondance irrécupérable avec l'ITL installé sur les points d'extrémité, ce qui nécessite la suppression de l'ITL de TOUS les points d'extrémité du cluster. Terminez le processus complet pour CallManager et, une fois les téléphones réenregistrés, démarrez le processus pour le TVS.

Remarque : pour déterminer si le cluster est en mode mixte, accédez à Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Non-Secure ; 1 == Mixed Mode).

Pour tous les noeuds CallManager du cluster :

Étape 1. Accédez à Cisco Unified OS Administration > Security > Certificate Management > Find and verify the expiration date of the CallManager certificate.

Étape 2. Cliquez sur Generate CSR > Certificate Purpose : CallManager. Sélectionnez les paramètres souhaités pour le certificat, puis cliquez sur Générer. Attendez que le message de réussite s'affiche et cliquez sur Fermer.

Étape 3. Téléchargez le CSR. Cliquez sur Télécharger CSR. Sélectionner le rôle du certificat : CallManager et cliquez sur Download. 

Étape 4. Envoyez le CSR à l’autorité de certification .

Étape 5. L’autorité de certification renvoie deux fichiers ou plus pour la chaîne de certificats signée. Téléchargez les certificats dans l'ordre suivant :

• Certificat d'autorité de certification racine comme CallManager-trust. Accédez à Certificate Management > Upload certificate > Certificate Purpose : CallManager-trust. Définissez la description du certificat et parcourez le fichier de certificat racine.
• Certificat intermédiaire en tant que CallManager-trust (facultatif). Accédez à Certificate Management > Upload certificate > Certificate Purpose : CallManager-trust. Définissez la description du certificat et parcourez le fichier de certificat intermédiaire.

Remarque : Certaines autorités de certification ne fournissent pas de certificat intermédiaire. Si seul le certificat racine a été fourni, cette étape peut être omise.

• Certificat signé par l'autorité de certification comme CallManager. Accédez à Certificate Management > Upload certificate > Certificate Purpose : CallManager. Définissez la description du certificat et parcourez le fichier de certificat signé par l'autorité de certification pour le noeud CUCM actuel.

Remarque : À ce stade, CUCM compare le CSR et le certificat CA signé chargé. Si les informations correspondent, le CSR disparaît et le nouveau certificat signé par l'autorité de certification est téléchargé. Si vous recevez un message d'erreur après le téléchargement du certificat, reportez-vous à la section Messages d'erreur courants du téléchargement du certificat.

Étape 6. Si le cluster est en mode mixte, mettez à jour la CTL avant le redémarrage des services : Jeton ou sans jeton. Si le cluster est en mode non sécurisé, ignorez cette étape et redémarrez les services.

Étape 7. Pour que le nouveau certificat soit appliqué au serveur, les services requis doivent être redémarrés (uniquement si le service s’exécute et est actif). Naviguez jusqu’à l’adresse :

• Cisco Unified Serviceability > Outils > Centre de contrôle - Services réseau > Service de vérification de la confiance Cisco
• Cisco Unified Serviceability > Outils > Control Center - Services de fonctionnalités > Cisco TFTP
• Cisco Unified Serviceability > Outils > Control Center - Services de fonctionnalités > Cisco CallManager
• Facilité de maintenance unifiée Cisco > Outils > Centre de contrôle - Services de fonctionnalités > Cisco TIManager 

Étape 8. Réinitialisez tous les téléphones :

• Accédez à Cisco Unified CM Administration > System > Enterprise Parameters > Reset. Une fenêtre contextuelle s'affiche avec l'instruction « Vous êtes sur le point de réinitialiser tous les périphériques du système ». Cette action ne peut pas être annulée. Continuer ? sélectionnez OK , puis cliquez sur Réinitialiser .

Remarque : Surveillez l'enregistrement des périphériques via RTMT. Une fois que tous les téléphones se sont réinscrits, vous pouvez passer au type de certificat suivant.

Certificat TVS  

Avertissement : l'expiration d'un certificat TVS ou un processus défectueux entraîne des problèmes d'enregistrement du téléphone ; Les nouveaux téléphones ne peuvent pas s'enregistrer auprès de Cisco UCM. Les périphériques enregistrés dans CUCM ne peuvent pas accéder aux applications telles que les services EM, le répertoire et MIDlet lorsque HTTPS est utilisé. L'authentification des TL et des fichiers de configuration (cfg) échoue également.

Mise en garde : Ne régénérez pas CallManager et les certificats TVS en même temps. Cela entraîne une non-correspondance irrécupérable avec l'ITL installé sur les points d'extrémité, ce qui nécessite la suppression de l'ITL de TOUS les points d'extrémité du cluster. Terminez le processus complet pour CallManager et, une fois les téléphones réenregistrés, démarrez le processus pour le TVS.

Pour tous les noeuds TVS du cluster :

Étape 1. Accédez à Cisco Unified OS Administration > Security > Certificate Management > Find and verify the expiration date of the TVS certificate.

Étape 2. Cliquez sur Generate CSR > Certificate Purpose : TVS. Sélectionnez les paramètres souhaités pour le certificat, puis cliquez sur Générer. Attendez que le message de réussite s'affiche et cliquez sur Fermer.

Étape 3. Téléchargez le CSR. Cliquez sur Télécharger CSR. Sélectionnez Certificate Purpose TVS et cliquez sur Download.

Étape 4. Envoyez le CSR à l’autorité de certification.

Étape 5. L’autorité de certification renvoie deux fichiers ou plus pour la chaîne de certificats signée. Téléchargez les certificats dans l'ordre suivant :

• Certificat d'autorité de certification racine comme TVS-trust. Accédez à Certificate Management > Upload certificate > Certificate Purpose : TVS-trust. Définissez la description du certificat et parcourez le fichier de certificat racine.
• Certificat intermédiaire de confiance TVS (facultatif). Accédez à Certificate Management > Upload certificate > Certificate Purpose : TVS-trust. Définissez la description du certificat et parcourez le fichier de certificat intermédiaire.

Remarque : Certaines autorités de certification ne fournissent pas de certificat intermédiaire. Si seul le certificat racine a été fourni, cette étape peut être omise.

• Certificat CA signé comme TVS. Accédez à Certificate Management > Upload certificate > Certificate Purpose : TVS. Définissez la description du certificat et parcourez le fichier de certificat signé par l'autorité de certification pour le noeud CUCM actuel.

Remarque : À ce stade, CUCM compare le CSR et le certificat CA signé chargé. Si les informations correspondent, le CSR disparaît et le nouveau certificat signé par l'autorité de certification est téléchargé. Si vous recevez un message d'erreur après le téléchargement du certificat, reportez-vous à la section Messages d'erreur courants du téléchargement du certificat.

Étape 6. Pour que le nouveau certificat soit appliqué au serveur, les services requis doivent être redémarrés (uniquement si le service s’exécute et est actif). Naviguez jusqu’à l’adresse :

• Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco TFTP (Tous les noeuds où le service s'exécute.)
• Cisco Unified Serviceability > Tools > Control Center - Network Services > Cisco Trust Verification Service (Tous les noeuds où le service est exécuté.)

Étape 7. Réinitialisez tous les téléphones :

• Accédez à Cisco Unified CM Administration > System > Enterprise Parameters > Reset. Une fenêtre contextuelle s'affiche avec l'instruction « Vous êtes sur le point de réinitialiser tous les périphériques du système ». Cette action ne peut pas être annulée. Continuer ? sélectionnez OK, puis cliquez sur Réinitialiser.

Remarque : Surveillez l'enregistrement des périphériques via RTMT. Une fois que tous les téléphones se sont réinscrits, vous pouvez passer au type de certificat suivant.

Dépanner les messages d'erreur de certificat téléchargés courants

Cette section répertorie certains des messages d'erreur les plus courants lors du téléchargement d'un certificat signé par une autorité de certification.

Le certificat CA n'est pas disponible dans le Trust-Store

Cette erreur signifie que le certificat racine ou intermédiaire n'a pas été téléchargé sur le CUCM. Vérifiez que ces deux certificats ont été téléchargés en tant que trust-store avant le téléchargement du certificat de service.

Le fichier /usr/local/platform/.security/tomcat/keys/tomcat.csr n'existe pas

Cette erreur apparaît lorsqu'il n'existe pas de CSR pour le certificat (tomcat, callmanager, ipsec, capf, tvs). Vérifiez que le CSR a été créé avant et que le certificat a été créé en fonction de ce CSR. Points importants à garder à l'esprit :

• Un seul CSR par serveur et type de certificat peut exister. Cela signifie que si une nouvelle RSE est créée, l'ancienne est remplacée.
• CUCM ne prend pas en charge les certificats génériques.
• Il n'est pas possible de remplacer un certificat de service actuellement en place sans un nouveau CSR.
• Une autre erreur possible pour le même problème est « Le fichier /usr/local/platform/upload/certs//tomcat.der n'a pas pu être chargé. » Cela dépend de la version de CUCM.

Clé publique CSR et clé publique de certificat ne correspondent pas

Cette erreur apparaît lorsque le certificat fourni par l'autorité de certification a une clé publique différente de celle envoyée dans le fichier CSR. Les raisons possibles sont :

• Le certificat incorrect (provenant peut-être d'un autre noeud) est chargé.
• Le certificat CA a été généré avec un CSR différent.
• Le CSR a été régénéré et a remplacé l'ancien CSR utilisé pour obtenir le certificat signé.

Pour vérifier la correspondance entre le CSR et la clé publique de certificat, plusieurs outils sont disponibles en ligne, tels que SSL. 

Une autre erreur possible pour le même problème est « Le fichier /usr/local/platform/upload/certs//tomcat.der n'a pas pu être chargé. » Cela dépend de la version de CUCM.

Le nom alternatif de l'objet CSR (SAN) et le certificat SAN ne correspondent pas

Les SAN entre le CSR et le certificat doivent être identiques. Cela empêche la certification pour les domaines qui ne sont pas autorisés. Pour vérifier la non-concordance du SAN, procédez comme suit :

1. Décoder le CSR et le certificat (base 64). Différents décodeurs sont disponibles en ligne, tels que le Decoder. 

2. Comparez les entrées SAN et vérifiez qu'elles correspondent toutes. L'ordre n'est pas important, mais toutes les entrées du CSR doivent être identiques dans le certificat. 

Par exemple, le certificat signé par une autorité de certification comporte deux entrées SAN supplémentaires, le nom commun du certificat et une adresse IP supplémentaire.

3. Une fois que vous avez identifié que le réseau SAN ne correspond pas, vous avez deux options pour résoudre ce problème :

1. Demandez à votre administrateur CA d'émettre un certificat avec les mêmes entrées SAN que celles envoyées dans le CSR.
2. Créez un CSR dans CUCM qui correspond aux exigences de l'autorité de certification.

Pour modifier le CSR créé par CUCM :

1. Si l'autorité de certification supprime le domaine, un CSR dans CUCM peut être créé sans le domaine. Lors de la création de CSR, supprimez le domaine qui est renseigné par défaut.
2. Si un certificat Multi-SAN est créé, il y a des CA qui n'acceptent pas les -ms dans le nom commun. L'option -ms peut être supprimée de la CSR lors de sa création. 

3. Pour ajouter un autre nom en plus de ceux remplis automatiquement par CUCM :

1. Si le certificat Multi-SAN est utilisé, d'autres noms de domaine complets peuvent être ajoutés. (Les adresses IP ne sont pas acceptées.)

b. Si le certificat est Single Node, utilisez la commande set web-security. Cette commande s'applique même aux certificats multi-SAN. (Tout type de domaine peut être ajouté, les adresses IP sont également autorisées.)

Pour plus d'informations, consultez le Guide de référence de la ligne de commande.

Les certificats de confiance avec le même CN ne sont pas remplacés

CUCM a été conçu pour stocker un seul certificat avec le même nom commun et le même type de certificat. Cela signifie que si un certificat tomcat-trust existe déjà dans la base de données et doit être remplacé par un certificat récent avec le même CN, CUCM supprime l'ancien certificat et le remplace par le nouveau.

Dans certains cas, CUCM ne remplace pas l'ancien certificat :

1. Le certificat téléchargé a expiré : CUCM ne vous permet pas de télécharger un certificat arrivé à expiration.
2. L'ancien certificat a une date FROM plus récente que le nouveau certificat. CUCM conserve le certificat le plus récent, et la date FROM plus ancienne est cataloguée comme plus ancienne. Pour ce scénario, il est nécessaire de supprimer le certificat indésirable, puis de télécharger le nouveau.