Génération de CSR et application de certificats à CMS

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 CN:
Webbridge	pki csr CN: subjectAltName: ,
Pont d’appel  TOURNER Équilibreur de charge	pki csr CN:

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

Service	Commande
Pont d’appel  TOURNER Équilibreur de charge	pki csr CN: subjectAltName:
XMPP	pki csr CN: subjectAltName: ,

É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 .
2. Sur le routeur principal, exécutez  pki selfsigned dbca CN . Exemple :  Pki selfsigned dbca CN:tplab.local
3. Sur le routeur principal, exécutez  pki csr dbserver CN:cmscore1.example.com subjectAltName .  Exemple :  cmscore2.example.com,cmscore3.example.com
4. Sur le serveur principal, créez un certificat pour le client de base de données pki csr dbclient CN:postgres .
5. Sur le serveur principal, utilisez dbca pour signer le certificat dbserver  pki sign dbserver dbca  .
6. Sur le serveur principal, utilisez dbca pour signer le certificat dbclient pki sign dbclient dbca .
7. Copiez le fichier dbclient.crt sur tous les serveurs qui doivent se connecter à un noeud de base de données
8. 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)
9. Copiez le fichier dbca.crt sur tous les serveurs.
10. 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 le dbca.crt  comme root ca-cert .
11. Sur le serveur de base de données principale, exécutez  database cluster localnode a .
12. Sur le serveur de base de données principale, exécutez  database cluster initialize .
13. Sur le serveur de base de données principale, exécutez  database cluster status .  Doit voir Noeuds : (me) : Connected Primary.
14. 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 .
15. 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 .
16. 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 .
17. Coeurs ON connectés (non colocalisés avec une base de données) :
    • couler 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  .
• Vous pouvez vérifier qu'un certificat correspond à une clé privée, puis exécuter la commande  pki match  .
• 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  .

É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 effectuez  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 auprès de database cluster status  qui est la base de données principale et, sur tous les noeuds, exécutez la commande  database cluster remove .  Vous pouvez ensuite suivre 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.

Informations connexes

• Assistance technique de Cisco et téléchargements