Bonjour !
Dans la leçon précédente, nous avons finalisé la cartographie des dépendances de votre infrastructure en identifiant les services critiques comme DNS, NTP, LDAP, la messagerie vocale et les intégrations CTI. Nous avons notamment vu que les connexions sécurisées, comme LDAPS, introduisent une dépendance de certificat.
Aujourd'hui, nous concluons notre module d'audit en nous concentrant sur ce sujet essentiel. L'objectif de cette leçon est d'identifier les certificats de sécurité (TLS) en usage et leurs dépendances entre les systèmes. Pour un projet de décommissionnement et de migration, une maîtrise parfaite de la gestion des certificats n'est pas une option, c'est une nécessité. Chaque trunk SIP sécurisé, chaque interface d'administration web, chaque service applicatif s'appuie sur une relation de confiance matérialisée par des certificats. Comprendre qui fait confiance à qui est la clé pour éviter les pannes brutales et garantir une transition fluide vers Webex Calling.
1. Les Fondamentaux : Identité, Confiance et Chaînes de Confiance
Avant de plonger dans les interfaces de vos systèmes, il est crucial de valider vos connaissances sur le rôle des certificats. Dans un environnement de communications unifiées, les certificats remplissent deux fonctions principales :
- Identité : Un certificat d'identité est comme la carte d'identité d'un serveur. Il prouve que le serveur est bien celui qu'il prétend être (par exemple, que
cucm-pub.votreentreprise.comest bien le serveur à cette adresse). - Confiance : Un certificat de confiance (ou certificat d'autorité, CA) est utilisé pour vérifier l'identité d'autres serveurs. C'est comme avoir un spécimen de la signature d'une autorité pour pouvoir vérifier les cartes d'identité qu'elle a émises.
On distingue principalement deux types de certificats.
Lecture - 38 | How to Regenerate the Certificates , Self Signed and CA - Signed Certificates
Pour bien saisir la différence fondamentale entre les certificats auto-signés et ceux signés par une autorité (CA), regardez cette courte explication. L'analogie avec un diplôme est particulièrement parlante.
Concentrez-vous sur la partie de 00:16 à 07:08. La vidéo explique : Ce qu'est un certificat auto-signé (self-signed) : le serveur se porte garant de sa propre identité. Pratique pour les tests ou les réseaux internes, mais pas digne de confiance pour des systèmes externes. Ce qu'est un certificat signé par une autorité (CA-signed) : un tiers de confiance (comme DigiCert, GoDaddy, ou votre propre autorité de certification d'entreprise) valide et signe l'identité du serveur. Pourquoi cette notion de confiance est primordiale pour les services publics ou critiques.
Cette confiance est établie via une chaîne de confiance. Un serveur présente son certificat d'identité, qui a été signé par une autorité de certification (CA). Pour que la connexion soit acceptée, le client doit posséder le certificat de cette CA (ou de la CA racine qui a signé cette CA) dans son "magasin de confiance" (Trust Store).
Diagramme de la chaîne de confiance d'un certificat
Ce diagramme (slide 23) illustre parfaitement la hiérarchie d'une chaîne de confiance : le certificat du serveur est signé par une autorité intermédiaire, qui est elle-même signée par une autorité racine. Pour valider le certificat du serveur, un système doit faire confiance à l'autorité racine.
2. L'Inventaire : Où Trouver les Certificats ?
Maintenant que les concepts sont clairs, passons à la pratique. Votre tâche consiste à localiser et à documenter les certificats sur chaque maillon de la chaîne : CUCM, SME, et les SBC AudioCodes.
A. Sur Cisco Unified Communications Manager (CUCM) et SME
L'interface de gestion des certificats est le point central de votre audit. Étant donné votre expérience, vous connaissez probablement déjà cet endroit, mais une révision systématique est nécessaire.
- Accédez à Cisco Unified OS Administration.
- Naviguez vers Security > Certificate Management.
Vous y trouverez une liste de tous les certificats. Ils sont classés par leur fonction et s'il s'agit d'un certificat d'identité (le nom du service, ex: tomcat, CallManager) ou de confiance (-trust, ex: tomcat-trust, CallManager-trust).
Les certificats les plus importants à auditer sont :
- Tomcat/Tomcat-trust : Utilisés pour les services web (interfaces d'administration, services AXL, UDS pour Jabber, etc.). Le certificat
tomcatest l'identité du serveur web CUCM. Le magasintomcat-trustcontient les CA en lesquelles CUCM a confiance pour établir des connexions HTTPS sortantes (ex: vers un serveur LDAP sécurisé). - CallManager/CallManager-trust : Utilisés pour les services de signalisation SIP et SCCP sécurisés (TLS). Le certificat
CallManagerest l'identité du CUCM pour les trunks SIP TLS et les téléphones sécurisés. Le magasinCallManager-trustcontient les CA en lesquelles CUCM a confiance pour valider les certificats des autres systèmes (SBC, autres CUCM). - IPSec/IPSec-trust : Utilisés pour les tunnels IPSec, notamment pour la réplication DRS.
- CAPF : Utilisé pour signer les certificats LSC des téléphones (Locally Significant Certificates).
Security Guide for Cisco Unified Communications Manager - Certificates
Le guide de sécurité officiel de Cisco est la référence absolue pour comprendre le rôle de chaque certificat. Il est essentiel de l'avoir sous la main.
Consultez ces deux sections pour une description détaillée : 'Server Certificate Types' : Décrit les différents types de certificats serveurs que vous trouverez dans l'interface. 'Certificate Names and Descriptions' (Table 7) : C'est une section cruciale. Elle liste les principaux certificats d'identité (tomcat, CallManager, ipsec, etc.), leur rôle, et les services qui doivent être redémarrés après une modification. Utilisez cette table comme une checklist.
Une expiration de certificat peut avoir des conséquences graves. La vidéo suivante, bien que plus longue, détaille l'impact d'une expiration sur chaque service, ce qui justifie l'importance de votre audit.
Lecture - 38 | How to Regenerate the Certificates , Self Signed and CA - Signed Certificates
Cette section de vidéo détaille l'impact d'une expiration sur les services CUCM. C'est une excellente ressource pour justifier l'importance de cet audit auprès des parties prenantes.
Regardez la partie de 19:46 à 23:39. Elle explique ce qui se passe lorsque les certificats CallManager.pem, Tomcat.pem, CAPF.pem, etc., expirent. Par exemple, une expiration de CallManager.pem peut empêcher les trunks SIP sécurisés de fonctionner.
B. Sur les SBC AudioCodes
Sur vos SBC AudioCodes, la gestion des certificats et de la confiance se fait au niveau des TLS Contexts. Un TLS Context est un profil de sécurité qui est ensuite appliqué à une entité SIP (comme un SIP Trunk).
- Connectez-vous à l'interface web du SBC.
- Naviguez vers
Setup > IP Network > Security > TLS Contexts. - Pour chaque TLS Context utilisé :
- Vérifiez le certificat du serveur (
Server Certificate) configuré. C'est l'identité que le SBC présentera. - Cliquez sur Trusted Root Certificates. C'est le magasin de confiance de ce contexte. Il doit contenir les certificats des CA qui ont signé les certificats des systèmes auxquels le SBC doit se connecter (ex: CUCM).
- Vérifiez le certificat du serveur (
3. Cartographie des Dépendances de Confiance
Maintenant que vous savez où trouver les certificats, l'étape la plus importante est de relier les points pour cartographier les dépendances. Le principe est simple : pour qu'une connexion TLS fonctionne, le client doit faire confiance au serveur.
Prenons un exemple concret : un Trunk SIP sécurisé (TLS) entre votre CUCM et votre SBC AudioCodes.
- Le SBC présente son identité : Le Trunk SIP sur le SBC est associé à un TLS Context. Ce contexte définit le certificat (
sbc.votreentreprise.com) que le SBC envoie au CUCM lors de l'établissement de la connexion TLS. Supposons que ce certificat soit signé par votre autorité de certification interne "Entreprise-CA". - Le CUCM vérifie l'identité : Pour que le CUCM accepte cette connexion, il doit faire confiance à "Entreprise-CA". Vous devez donc vérifier que le certificat de "Entreprise-CA" est bien présent dans le magasin de confiance
CallManager-trustde votre CUCM. - Et vice-versa : Si votre Trunk SIP est configuré pour que le SBC vérifie également le certificat du CUCM, la logique s'inverse. Le CUCM présentera son certificat
CallManager. Si ce certificat est signé par la même "Entreprise-CA", le magasin "Trusted Root Certificates" du TLS Context sur le SBC doit également contenir le certificat de "Entreprise-CA".
Testez votre compréhension !
Vous diagnostiquez un Trunk SIP TLS entre CUCM et SME qui ne monte pas. Dans les logs du CUCM, vous trouvez une erreur tlsv1 alert unknown ca. Le SME présente un certificat signé par une autorité nommée "SME-Cluster-CA". Quelle est la cause la plus probable du problème et comment le corriger ?
Voir la réponse
La cause la plus probable est que le certificat de l'autorité "SME-Cluster-CA" n'est pas présent dans le magasin de confiance du CUCM pour la signalisation SIP. Pour corriger cela, il faut importer le certificat de "SME-Cluster-CA" dans le magasin CallManager-trust sur CUCM, puis redémarrer les services concernés si nécessaire (ici, le service Cisco CallManager).
4. Simplification et Bonnes Pratiques : Les Certificats Multi-Serveurs (SAN)
Dans un cluster CUCM, gérer un certificat par serveur et par service peut devenir un cauchemar. C'est pourquoi Cisco supporte les certificats multi-serveurs, ou SAN (Subject Alternative Name). Un seul certificat peut contenir les noms de tous les serveurs du cluster et être déployé sur tous les nœuds pour un service donné.
C'est une pratique essentielle à vérifier lors de votre audit. Si vous n'utilisez pas de certificats SAN, c'est peut-être une opportunité de simplification avant même la migration.
Unified Communications Manager Cluster Certificates
Cette vidéo est une démonstration pratique et complète de la génération et de l'installation d'un certificat SAN pour le service Tomcat sur un cluster CUCM. C'est un excellent moyen de valider votre compréhension du processus complet.
Regardez la vidéo en entier (environ 16 minutes). Elle couvre tout le flux de travail : Génération du CSR (06:20) : L'ingénieur génère une seule requête de signature de certificat (CSR) depuis le Publisher en choisissant l'option 'multi server SAN'. Signature par la CA (08:44) : Il utilise une CA Microsoft pour signer le CSR et obtient le certificat d'identité et le certificat de la CA racine. Importation sur CUCM (11:15) : Il importe le certificat racine dans tomcat-trust et le certificat d'identité signé dans tomcat. Vérification (12:19) : Il montre que les certificats se sont automatiquement répliqués sur tous les autres nœuds du cluster (Subscribers, IM&P). Redémarrage des services (14:35) : L'étape finale consiste à redémarrer le service Cisco Tomcat sur tous les nœuds pour que la modification soit prise en compte.
Conclusion de la Leçon
Excellent travail ! Vous avez maintenant toutes les clés pour réaliser un audit complet des certificats de sécurité de votre infrastructure.
Points clés à retenir :
- Identité vs Confiance : Chaque système a ses propres certificats d'identité et des magasins de confiance pour valider l'identité des autres.
- La Chaîne de Confiance est la Clé : Une connexion TLS ne peut aboutir que si le client fait confiance à l'autorité qui a signé le certificat du serveur.
- Chaque Système a son Emplacement : Vous savez maintenant où chercher les certificats et les magasins de confiance sur CUCM (
Security > Certificate Management) et sur les SBC AudioCodes (Security > TLS Contexts). - L'Audit est une Cartographie : Votre objectif est de créer un tableau recensant chaque certificat, sa date d'expiration, son émetteur, et surtout, les systèmes qui en dépendent.
- Simplifiez avec les SAN : Les certificats multi-serveurs sont une bonne pratique pour réduire la complexité de gestion sur un cluster.
Cet inventaire des certificats et de leurs dépendances conclut notre phase d'audit. Il est non seulement indispensable pour planifier le décommissionnement sans coupure de service, mais il vous sera aussi directement utile lorsque vous configurerez la connexion sécurisée entre vos SBC et Webex Calling.
Prochaine étape :
Maintenant que notre audit de l'infrastructure existante est terminé, nous allons nous tourner vers l'avenir. La prochaine leçon entamera un nouveau module en s'attaquant à l'architecture cible : Décrire l'architecture Webex Calling Local Gateway et son rôle dans une migration hybride. Nous commencerons à construire la solution de demain.