Vérifier la non-correspondance entre CSR et certificat pour UC

Introduction

Ce document décrit comment identifier si le certificat signé par l'autorité de certification (AC) correspond à la demande de signature de certificat (CSR) existante pour les serveurs d'applications Cisco Unified.

Conditions préalables

Conditions requises

Cisco vous recommande de connaître X.509/CSR.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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. If your network is live, make sure that you understand the potential impact of any command.

Produits connexes

Ce document peut également être utilisé avec les versions de matériel et de logiciel suivantes :

• Gestionnaire de communications unifiées de Cisco (version CUCM)
• Messagerie instantanée et présence Cisco Unified
• Cisco Unified Unity Connection
• CUIS
• Solution Cisco
• Cisco Unified Contact Center Express (UCCX)

Informations générales

Une demande de certification se compose d'un nom unique, d'une clé publique et d'un ensemble facultatif d'attributs signés collectivement par l'entité qui demande la certification. Les demandes de certification sont envoyées à une autorité de certification qui transforme la demande en certificat de clé publique X.509. Sous quelle forme l'autorité de certification renvoie le certificat nouvellement signé n'entre pas dans le champ d'application de ce document.  Un message PKCS #7 est une possibilité.(RFC : 2986).

Gestion des certificats de Cisco Communications Manager

L'intention d'inclure un ensemble d'attributs est double :

• Afin de fournir d'autres informations sur une entité donnée, ou un mot de passe de confirmation par lequel l'entité peut demander ultérieurement la révocation de certificat.
• Afin de fournir des attributs à inclure dans les certificats X.509. Les serveurs Unified Communications (UC) actuels ne prennent pas en charge un mot de passe de confirmation.

Les serveurs Cisco UC actuels nécessitent ces attributs dans un CSR, comme indiqué dans ce tableau :

Informations	Description
unité d'orbite	unité organisationnelle
orgname	nom de l'organisation
localité	emplacement de l'organisation
province	état de l'organisation
pays	le code pays ne peut pas être modifié
autre nom d’hôte	autre nom d'hôte

Problème

Lorsque vous prenez en charge les communications unifiées, vous pouvez rencontrer de nombreux cas où le certificat signé de l'autorité de certification ne peut pas être téléchargé sur les serveurs UC. Vous ne pouvez pas toujours identifier ce qui s'est produit au moment de la création du certificat signé, car vous n'êtes pas la personne qui a utilisé le CSR pour créer le certificat signé. Dans la plupart des scénarios, la nouvelle signature d'un nouveau certificat prend plus de 24 heures. Les serveurs UC tels que CUCM n'ont pas de journal/trace détaillé afin d'aider à identifier pourquoi le téléchargement de certificat échoue, mais ils donnent simplement un message d'erreur. L'objectif de cet article est de réduire le problème, qu'il s'agisse d'un problème de serveur UC ou de CA.

Pratique générale pour les certificats signés CA dans CUCM

CUCM prend en charge l'intégration avec les CA tierces à l'aide d'un mécanisme CSR PKCS#10 accessible à l'interface utilisateur graphique de Cisco Unified Communications Operating System Certificate Manager. Les clients qui utilisent actuellement des CA tierces doivent utiliser le mécanisme CSR pour émettre des certificats pour Cisco CallManager, CAPF, IPSec et Tomcat.

Étape 1. Modifiez l'identification avant de générer le CSR.

L'identité du serveur CUCM afin de générer un CSR peut être modifiée avec l'utilisation de la commande set web-security comme illustré dans cette image.

Si vous avez de l'espace dans les champs ci-dessus, utilisez “ ” afin d'exécuter la commande comme indiqué dans l'image.

Étape 2. Générez CSR comme l'illustre l'image.

Étape 3. Téléchargez le CSR et obtenez-le signé par l’AC, comme l’illustre l’image.

Étape 4. Téléchargez le certificat signé par l'autorité de certification sur le serveur.

Une fois que le CSR est généré et que le certificat est signé et que vous ne l'avez pas téléchargé avec un message d'erreur « Erreur de lecture du certificat » (comme illustré dans cette image), vous devez vérifier si le CSR est régénéré ou si le certificat signé est la cause du problème.

Il existe trois façons de vérifier si le CSR est régénéré ou si le certificat signé lui-même est la cause du problème.

Solution 1. Utiliser la commande OpenSSL dans root (ou linux)

Étape 1. Connectez-vous à la racine et accédez au dossier comme indiqué dans l'image.

Étape 2. Copiez le certificat signé dans le même dossier avec Secure FTP (SFTP). Si vous ne parvenez pas à configurer un serveur SFTP, le téléchargement sur le dossier TFTP peut également obtenir le certificat sur le CUCM, comme le montre l'image.

3. Vérifiez le MD5 pour le CSR et le certificat signé, comme indiqué sur l'image.

Solution 2. Utiliser n'importe quelle correspondance de clé de certificat SSL à partir d'Internet

Solution 3. Comparer le contenu d'un décodeur CSR à partir d'Internet

Étape 1. Copiez les informations détaillées du certificat de session pour chaque type, comme indiqué dans cette image.

Étape 2. Comparez-les dans un outil tel que le Bloc-notes++ avec le plug-in Comparer comme illustré dans cette image.