Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Générer le CSR

Étape 1. Structure de syntaxe.

Étape 2. Générez des CSR callbridge, xmpp, webadmin et webbridge.

Étape 3. Générez le CSR du cluster de base de données et utilisez l'autorité de certification intégrée pour les signer.

Étape 4. Vérifiez les certificats signés.

Étape 5. Appliquez des certificats signés aux composants sur les serveurs CMS.

Chaînes et ensembles de certificats de confiance

Dépannage

Informations connexes

Introduction

Ce document décrit comment générer une demande de signature de certificat (CSR) et télécharger des certificats signés vers Cisco Meeting Server (CMS).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- Connaissances de base du serveur CMS

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

- Putty ou logiciel similaire

- CMS version 2.9 ou ultérieure

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.

Générer le CSR

Il existe deux façons de générer un CSR : l'une consiste à générer le CSR directement sur le serveur CMS à partir de l'interface de ligne de commande (CLI) avec un accès administrateur, l'autre consiste à le faire avec une autorité de certification tierce externe, telle qu'Open SSL.

Dans les deux cas, le CSR doit être généré avec la syntaxe correcte pour que les services CMS fonctionnent correctement.

Étape 1. Structure de syntaxe.

pki csr <key/cert basename> <CN:value> [OU:<value>] [O:<value>] [ST:<-value>] [C:<value>] [subjectAltName:<value>]

- <key/cert basename> est une chaîne qui identifie la nouvelle clé et le nom CSR. Il peut contenir des caractères alphanumériques, des traits d'union ou des traits de soulignement. Ce champ est obligatoire.

- <CN : value> est le nom commun. Il s'agit du nom de domaine complet (FQDN) qui spécifie l'emplacement exact du serveur dans le système de noms de domaine (DNS). Ce champ est obligatoire.

- [OU : <valeur>] est le nom de l'unité organisationnelle ou du service. Par exemple, Support, informatique, Ingénieur, Finance. Ce champ est facultatif.

- [O : <valeur>] est le nom de l'organisation ou de l'entreprise. Habituellement le nom légalement constitué d'une société. Ce champ est facultatif.

- [ST : <valeur>] est la province, la région, le comté ou l'état. Par exemple, Buckinghamshire en Californie. Ce champ est facultatif.

- [C:<valeur>] est le pays. Code ISO (International Organization for Standardization) de deux lettres pour le pays dans lequel votre organisation est située. Par exemple, US, GB, FR. Ce champ est facultatif.

- [subjectAltName:<value>] est le nom alternatif du sujet (SAN). À partir de la version 3 de X509 (RFC 2459), les certificats SSL (Secure Socket Layers) sont autorisés à spécifier plusieurs noms auxquels le certificat doit correspondre. Ce champ permet au certificat généré de couvrir plusieurs domaines. Il peut contenir des adresses IP, des noms de domaine, des adresses e-mail, des noms d'hôte DNS standard, etc., séparés par des virgules. S'il est spécifié, vous devez également inclure le CN dans cette liste. Bien qu'il s'agisse d'un champ facultatif, le champ SAN doit être renseigné pour que les clients XMPP (Extensible Messaging and Presence Protocol) puissent accepter un certificat, sinon les clients XMPP affichent une erreur de certificat.

Étape 2. Générez des CSR callbridge, xmpp, webadmin et webbridge.

1. Accédez à l'interface de ligne de commande de CMS avec Putty et connectez-vous avec le compte admin.

2. Exécutez les commandes suivantes afin de créer CSR pour chaque service requis sur CMS. Il est également acceptable de créer un certificat unique avec un caractère générique (*.com) ou avec le nom de domaine complet du cluster comme CN, les noms de domaine complets de chaque serveur CMS et l'URL de jointure si nécessaire.

Service

Commande

Webadmin

pki csr <cert name> CN:<server FQDN>

Webbridge

pki csr <cert name> CN:<Server FQDN> subjectAltName:<Join Url>,<XMPP domain>

Pont d’appel

TOURNER

Équilibreur de charge

pki csr <cert name> CN:<Server FQDN’s>

3. Si le CMS est mis en grappe, exécutez les commandes suivantes.

Service

Commande

Pont d’appel

TOURNER

Équilibreur de charge

pki csr <cert name> CN:<cluster FQDN> subjectAltName:<Peer FQDN’s>

XMPP

pki csr <cert name> CN:<Cluster FQDN> subjectAltName:<XMPP Domain>,<Peer FQDN’s>

Étape 3. Générez le CSR du cluster de base de données et utilisez l'autorité de certification intégrée pour les signer.

Depuis CMS 2.7, vous devez disposer de certificats pour votre cluster de base de données.  Dans la version 2.7, nous avons inclus une autorité de certification intégrée qui peut être utilisée pour signer les certificats de base de données.

1. Sur tous les coeurs, exécutez database cluster remove .

1. Sur le routeur principal, exécutez pki selfsigned dbca CN . Exemple :  Pki selfsigned dbca CN:tplab.local

1. Sur le routeur principal, exécutez pki csr dbserver CN:cmscore1.example.com subjectAltName . Exemple :  cmscore2.example.com,cmscore3.example.com

1. Sur le routeur principal, créez un certificat pour le client pki csr dbclient CN:postgres  de base de données.

1. Sur le serveur principal, utilisez dbca pour signer le certificat  pki sign dbserver dbca   dbserver.

1. Sur le routeur principal, utilisez dbca pour signer le certificat dbclient pki sign dbclient dbca .

1. Copiez le fichier dbclient.crt sur tous les serveurs qui doivent se connecter à un noeud de base de données

2. Copiez le fichier dbserver.crt sur tous les serveurs joints à la base de données (noeuds qui constituent le cluster de base de données)

3. Copiez le fichier dbca.crt sur tous les serveurs.

4. Sur le serveur de base de données principale, exécutez database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt . Cette commande utilise les dbca.crt comme root ca-cert .

1. Sur le serveur de base de données principale, exécutez database cluster localnode a .

1. Sur le serveur de base de données principale, exécutez database cluster initialize .

1. Sur le serveur de base de données principale, exécutez database cluster status . Doit voir Nodes: (me): Connected Primary.

1. Sur tous les autres coeurs qui sont joints au cluster de base de données, exécutez database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt .

1. Sur tous les coeurs connectés (non colocalisés avec une base de données) au cluster de base de données, exécutez database cluster certs dbclient.key cbclient.crt dbca.crt .

1. Sur les coeurs qui sont joints (colocalisés avec une base de données) :

- exécutez la commande . database cluster localnode a

- exécutez la commande .database cluster join

1. Coeurs ON connectés (non colocalisés avec une base de données) :

- ru n database cluster localnode a .

- exécutez la commande . database cluster connect

Étape 4. Vérifiez les certificats signés.

- La validité du certificat (date d'expiration) peut être vérifiée à l'aide de l'inspection du certificat. Exécutez la commande pki inspect <filename> .

- Vous pouvez vérifier qu'un certificat correspond à une clé privée, exécutez la commande pki match <keyfile> <certificate file> .

- Afin de valider qu'un certificat est signé par l'autorité de certification et que le groupe de certificats peut être utilisé pour l'affirmer, exécutez la commande pki verify <cert> <certificate bundle/Root CA> .

Étape 5. Appliquez des certificats signés aux composants sur les serveurs CMS.

1. Afin d'appliquer des certificats à Webadmin, exécutez les commandes suivantes :

webadmin disable

webadmin certs <keyfile> <certificate file> <certificate bundle/Root CA>

webadmin enable

2. Afin d'appliquer des certificats à Callbridge, exécutez les commandes suivantes :

callbridge certs <keyfile> <certificate file> <certificate bundle/Root CA>

callbridge restart

3. Afin d'appliquer des certificats à Webbridge, exécutez les commandes suivantes :

webbridge disable

webbridge certs <keyfile> <certificate file> <certificate bundle/Root CA>

webbridge enable

4. Afin d'appliquer des certificats à XMPP, exécutez les commandes suivantes :

xmpp disable

xmpp certs <keyfile> <certificate file> <certificate bundle/Root CA>

xmpp enable

5. Afin d'appliquer des certificats à la base de données ou de remplacer les certificats expirés sur le cluster de base de données actuel, exécutez les commandes suivantes :

database cluster remove (on all servers, noting who was primary before beginning)

database cluster certs <server_key> <server_certificate> <client_key> <client_certificate> <Root ca_crt>

database cluster initialize     (only on primary node)

database cluster join <FQDN or IP of primary>    (only on slave node)

database cluster connect <FQDN or IP of primary> (only on nodes that are not part of the database cluster)

6. Afin d'appliquer des certificats à TURN, exécutez les commandes suivantes :

turn disable

turn certs <keyfile> <certificate file> <certificate bundle/Root CA>

turn enable

Chaînes et ensembles de certificats de confiance

Depuis CMS 3.0, vous devez utiliser des chaînes d'approbation de certificat ou des approbations de chaîne complète.  En outre, il est important pour tout service que vous reconnaissiez comment les certificats doivent être construits lorsque vous faites des offres groupées.

Lorsque vous créez une chaîne de certificats de confiance, comme requis pour le pont Web 3, vous devez la créer comme indiqué dans l'image, avec le certificat d'entité en haut, et les intermédiaires au milieu, et l'autorité de certification racine en bas, puis un seul retour chariot.

Chaque fois que vous créez un lot, le certificat ne doit comporter qu'un seul retour chariot à la fin.

Les offres groupées CA seraient les mêmes que celles illustrées dans l'image, mais, bien sûr, il n'y aurait pas de certificat d'entité.

Dépannage

Si vous devez remplacer un certificat expiré pour tous les services, à l'exception des certificats de base de données, la méthode la plus simple consiste à télécharger de nouveaux certificats portant le MÊME nom que les anciens certificats. Dans ce cas, le service doit simplement être redémarré et vous n'avez pas besoin de le reconfigurer.

Si vous exécutez pki csr ...   et que ce nom de certificat correspond à une clé actuelle, il interrompt immédiatement le service.  Si la production est en direct et que vous créez de manière proactive une nouvelle clé et un nouveau CSR, utilisez un nouveau nom.  Vous pouvez renommer le nom actif avant de télécharger le nouveau certificat sur les serveurs.

Si les certificats de base de données ont expiré, vous devez vérifier avec database cluster status  qui est la base de données principale et, sur tous les noeuds, exécuter la commande  database cluster remove . Vous pouvez ensuite utiliser les instructions de l'étape 3. Générez le CSR du cluster de base de données et utilisez l'autorité de certification intégrée pour les signer.

Remarque : si vous devez renouveler les certificats Cisco Meeting Manager (CMM), reportez-vous à la vidéo suivante : Mise à jour du certificat SSL de gestion des réunions Cisco

Informations connexes

- Assistance technique de Cisco et téléchargements