Dans cet article, nous allons voir comment gérer les certificats numériques dans la solution de conferencing Cisco Meeting Server lorsqu’un déploiement existant nécessite une extension, c’est-à-dire l’ajout d’un nouveau nœud dans le cluster.
Dans ce scenario, nous avons un cluster de base de données et de callbridges ainsi que le service webbridge déployés dans trois CMS (CMS1, CMS2, CMS3). Le concept Multi-SAN est utilisé afin de faciliter la gestion des certificats, en d’autres termes le concept Multi-SAN permet d’utiliser un seul certificat pour tous les services. Et c’est la méthode recommandée par Cisco.
Par la suite nous souhaitons ajouter un autre nœud avec les services CallBridge et WebBridge CMS4 dans le cluster. L’analyse des certificats existants et une bonne conception pour la mise œuvre sont primordiales afin d’intégrer un nouveau serveur.
Après une analyse, j’ai abouti à deux méthodes de mise en œuvre des certificats numériques afin d’intégrer le nouveau serveur CMS4. Pour déterminer quelle est la solution la plus adéquate à votre architecture, il est impératif d’analyser les certificats numériques :
Comment les common name et les SAN (Subject Alternative Name) sont-ils définis ?
Est que le service scheduler est activé dans la solution existante ?
Première méthode :
1-Générer un CSR pour le nouveau CMS avec les informations suivantes en utilisant le FQDN du CMS4 dans le champ Common Name :
Common Name = cms4.lab.local.
Subject Alternative Name =
DNS Name=join.lab.local
DNS Name=meet.lab.local
DNS Name=lab.local
Commandes MMP.
cms4> pki csr cms4cer CN:cms4.lab.local OU:CCNP O:Collaboration L:lab ST:local C:US subjectAltName:join.lab.local,meet.lab.local,lab.local
2-Générer le certificat du nouveau CallBridge CMS4 à partir du CSR.
3-Créer une chaine de certificat à partir du certificat créé précédemment et le certificat Bundle qui lui contient le certificate d’un CA intermédiaire et le certificat racine Root-CA.
Ci-dessous comment créer le bundle.
Ci-dessous comment créer la chaine de certificate pour le webbridge et le callbridge.
Cette méthode nécessite seulement de configurer le certificat dans le nouveau CMS4 pour les services CallBridge et WebBridge, sans modifier les certificats existants.
Deuxième méthode :
1-Générer un nouveau CSR pour tous les CMS avec les informations suivantes, cette fois-ci le FQDN du CMS4 sera renseigné dans le SAN (Subject Alternative Name) :
Common Name = cms1.lab.local
Subject Alternative Name =
DNS Name=cms2.lab.local
DNS Name=cms3.lab.local
DNS Name=cms4.lab.local
DNS Name=join.lab.local
DNS Name=meet.lab.local
cms4> pki csr onecert CN:cms1.lab.local OU:CCNP O:Collaboration L:lab ST:local C:US subjectAltName:cms2.lab.local,cms3.lab.local,cms4.lab.local,join.lab.local,meet.lab.local,lab.local,10.1.5.0/24
2-Générer le certificat à partir du CSR.
3-Créer une chaine de certificat à partir du certificat créé précédemment et le certificat Bundle qui lui contient le certificate d’un CA intermédiaire et le certificat racine Root-CA.
Cette méthode nécessite de configurer le certificat dans tous les CMS (CMS1, CMS2, CMS3 et CMS4) pour les services CallBridge et WebBridge.
L’implémentation en utilisant la première méthode
- Uploader le certificat et la chaine de certificat dans le nouveau CMS.
- Uploader les certificats database dans le nouveau CMS.
- Uploader la chaine de certificat dans tous les CMS.
- Activer les services WebAdmin, CallBridge et WebBridge du nouveau CMS.
- Connecter le nouveau CallBridge au Cluster Database (commande : database cluster connect <FQDN du nœud primaire database 10.1.5.61>)
- Ajouter le nouveau CallBridge dans le cluster CallBridge existant.
- Configurer la connexion WebBridge to CallBridge c2w://<cms4.lab.local:9999>
Dans le nouveau CMS4 :
Dans un déploiement avec des callbridges dediés, c’est-à-dire sans le service de base de données, il faut les connecter avec la commande database cluster connect afin de récupérer la configuration comme les spaces, le dial plan et les profiles, aussi les certificats de base données existants doivent être configurés afin de permettre aux callbridge de s’authentifier avec les nœuds de base de données.
Cms4>database cluster certs dbcert.key dbcert.cer dbclt.key dbclt.cer Root-CA.cer
Cms4>database cluster localnode a
Cms4>database cluster connect 10.1.5.61
Cette méthode est simple, en dédiant un certificat pour le nouveau CMS4 sans toucher les certificats existants, il suffit d’activer les services dans le nouveau CMS et le connecter à la base de données.
L’implémentation en utilisant deuxième méthode
- Uploader le certificat et la chaine de certificat dans tous les serveurs CMS.
- Uploader les certificats database dans le nouveau CMS.
- Activer les services WebAdmin, CallBridge et WebBridge dans tous les serveurs CMS.
- Connecter le nouveau CallBridge au Cluster Database (commande : database cluster connect <FQDN du nœud primaire database 10.1.5.61>
- Ajouter le nouveau CallBridge dans le cluster CallBridge existant.
- Configurer la connexion WebBridge to CallBridge c2w://cms4.lab.local:9999>
- Vérifier la réplication de la configuration.
Commandes MMP sur CMS1.
Commandes MMP sur CMS2.
Commandes MMP sur CMS3.
Commandes MMP sur CMS4.
Cette deuxième méthode nécessite la reconfiguration de tous les certificats et la réactivation des services sur l’ensemble du cluster.
Mais parfois dans votre déploiement vous avez le service scheduler activé sur un callbridge, comme dans le cas de cet exemple (CMS1). Dans cette situation, la deuxième méthode qui consiste à reconfigure tous les certificats et l’activation des services sur l’ensemble du cluster est nécessaire et impérative, en effet, lorsque le scheduler initie le connexion c2w (CallBridge to WebBridge) vers les webbridges, il doit faire confiance au certificat présenté par ces derniers (webbridges) et vice versa, pour faire confiance au certificat, chaque service doit présenter son FQDN dans le Common Name ou le SAN.
Comme dans la première méthode, les webbridges CMS1, CMS2 et CMS3 utilisent un seul certificat tandis que le CMS4 utilise un certificat dédié, le scheduler cms1 se connectera seulement aux webbridges CMS1, CMS2 et CMS3, la négociation SSL avec le webbridge CMS4 échouera lors de la tentative d’authentification par certificats car le FQDN cms4.lab.local est manquant dans le certificat des webbridges CMS1, CMS2 et CMS3.
Ce scenario est inspiré d’un déploiement réel.
