Guide d'utilisation complet de Jabber pour la validation des certificats

Introduction

Ce document combine plusieurs ressources Cisco dans un guide de procédures complet et unifié qui est utilisé pour mettre en oeuvre toutes les exigences de validation de certificat dans Cisco Jabber. Cela est nécessaire car Cisco Jabber nécessite désormais l'utilisation de la validation des certificats afin d'établir des connexions sécurisées avec les serveurs. Cette exigence implique de nombreuses modifications qui pourraient être nécessaires pour les environnements utilisateur.

Note: Ce guide concerne uniquement les déploiements sur site. Aucune modification n'est actuellement requise pour les déploiements de services cloud, car ils sont validés par l'autorité de certification publique.

Quels clients Jabber sont affectés par cette modification ?

Voici un tableau qui répertorie tous les clients qui implémentent la validation de certificat :

Tableau 1 :

Clients de bureau	Clients mobiles et tablettes
Jabber pour Macintosh version 9.2 (septembre 2013)	Jabber pour iPhone version 9.5 (octobre 2013)
Jabber pour Microsoft (MS) Windows Version 9.2.5 (septembre 2013)	Jabber pour iPhone et iPad version 9.6 (novembre 2013)
	Jabber pour Android version 9.6 (décembre 2013)

Qu'est-ce que cela signifie pour l'environnement Jabber ?

Lorsque vous installez ou mettez à niveau un client répertorié dans le tableau 1, la validation obligatoire des certificats avec les serveurs est utilisée pour les connexions sécurisées. Essentiellement, lorsque les clients Jabber tentent d'établir une connexion sécurisée maintenant, les serveurs présentent à Cisco Jabber des certificats. Cisco Jabber tente ensuite de valider ces certificats par rapport au magasin de certificats du périphérique. Si le client ne peut pas valider le certificat, il vous invite à confirmer que vous voulez accepter le certificat et à le placer dans son magasin Enterprise Trust.

Quels certificats sont requis ?

Voici une liste des serveurs sur site et des certificats qu'ils présentent à Cisco Jabber afin d'établir une connexion sécurisée :

Tableau 2

Serveur	Certificat
Cisco Unified Presence	HTTP (Tomcat) XMPP
Messagerie instantanée et présence de Cisco Unified Communications Manager	HTTP (Tomcat) XMPP
Solutions Cisco Unified Communications Manager	HTTP (Tomcat)
Cisco Unity Connection	HTTP (Tomcat)
Serveur de réunions Cisco WebEx	HTTP (Tomcat)

Voici quelques points importants à noter :

• Appliquez la dernière mise à jour de service (SU) pour Cisco Unified Presence (CUP) ou Cisco Unified Communications Manager (CUCM) IM and Presence avant de commencer le processus de signature de certificat.
• Les certificats requis s'appliquent à toutes les versions de serveur. Par exemple, CUP version 8.x et CUCM IM and Presence version 9.x et versions ultérieures présentent au client des certificats XMPP (Extensible Messaging and Presence Protocol) et HTTP.
• Chaque noeud d'un cluster, les abonnés et les éditeurs, exécute un service Tomcat et peut présenter au client un certificat HTTP. Prévoyez de signer les certificats pour chaque noeud du cluster.
• Afin de sécuriser la signalisation SIP (Session Initiation Protocol) entre le client et CUCM, utilisez l'inscription CAPF (Certification Authority Proxy Function).

Quelles méthodes sont disponibles pour la validation de certificat ?

Il existe actuellement plusieurs méthodes de validation de certification qui peuvent être utilisées.

Méthode 1 : Les utilisateurs cliquent simplement sur Accepter pour toutes les fenêtres de certificat. Il s'agit peut-être de la solution idéale pour les environnements plus petits. Si vous cliquez sur Accepter, les certificats sont placés dans le magasin Enterprise Trust du périphérique. Une fois les certificats placés dans le magasin Enterprise Trust, les utilisateurs ne sont plus invités à se connecter au client Jabber sur ce périphérique local.

Méthode 2 : Les certificats requis (Tableau 2) sont téléchargés à partir des serveurs individuels (par défaut, il s'agit de certificats auto-signés) et installés dans le magasin Enterprise Trust du périphérique utilisateur. Cette solution peut être idéale si votre environnement n'a pas accès à une autorité de certification privée ou publique pour la signature de certificats.

Plusieurs méthodes peuvent être utilisées pour pousser ces certificats vers les utilisateurs, mais une méthode rapide consiste à utiliser le Registre Microsoft Windows :

1. À partir de l'une des machines, acceptez tous les certificats qui sont présentés à Jabber dans le magasin de fiducie d'entreprise.
2. Afin de vérifier que les certificats sont présents, entrez la commande Certmgr.msc et accédez à Enterprise Trust > Certificates.
3. Ouvrez Regedit avec une commande run et accédez à HKCU > Software > Microsoft > SystemCertificates > trust > Certificates.
4. Cliquez avec le bouton droit de la souris et exportez le dossier Certifates du Registre sous la forme d'un fichier .reg.
5. Diffuser ce fichier via l'objet de stratégie de groupe (GPO) à tous les utilisateurs (ou toute autre méthode préférée).

L'installation des certificats Enterprise Trust pour Jabber est terminée et les utilisateurs ne sont plus invités.

Méthode 3 : Une AC publique ou privée (tableau 2) signe tous les certificats requis. Il s'agit de la méthode recommandée par Cisco. Cette méthode nécessite qu'une demande de signature de certificat (CSR) soit générée pour chacun des certificats, soit signée, rechargée sur le serveur, puis importée dans le magasin d'autorités de certification racine de confiance sur les périphériques utilisateur. Reportez-vous à la section Générer un CSR et à la section Comment obtenir des certificats aux magasins de certificats des périphériques utilisateur ? pour plus d'informations.

Note: Dans le cas d'une autorité de certification publique, le certificat racine doit déjà se trouver dans le magasin d'approbation du client.

Il est important de se rappeler que les autorités de certification publiques ont généralement besoin de RSE pour se conformer à des formats spécifiques. Par exemple, une autorité de certification publique peut uniquement accepter des CSR qui :

• Sont codés en base64
• Ne pas contenir certains caractères, tels que @& !, dans l'organisation, l'unité d'organisation ou d'autres champs
• Utiliser des longueurs de bits spécifiques dans la clé publique pour le serveur

De même, si vous envoyez des CSR à partir de plusieurs noeuds, les CA publiques peuvent exiger que les informations soient cohérentes dans tous les CSR.

Afin d'éviter des problèmes avec vos CSR, passez en revue les exigences de format de l'autorité de certification publique à laquelle vous prévoyez d'envoyer les CSR. Assurez-vous ensuite que les informations que vous entrez lorsque vous configurez votre serveur sont conformes au format requis par l'autorité de certification publique.

Voici une condition requise possible :

Un certificat par nom de domaine complet : Certaines autorités de certification publiques ne signent qu'un seul certificat par nom de domaine complet (FQDN).

Par exemple, pour signer les certificats HTTP et XMPP pour un noeud de messagerie instantanée et de présence CUCM unique, vous devrez peut-être envoyer chaque CSR à différentes CA publiques.

Vérifier si un certificat est autosigné ou signé par l'autorité de certification

Note: Cet exemple concerne CUCM version 8.x. Le processus peut varier d'un serveur à l'autre.

1. Accédez à Cisco Unified OS Administration.
2. Choisissez Security > Certificate Management.
3. Recherchez et cliquez sur le fichier Tomcat-Trust Certificate .pem.
4. Cliquez sur Télécharger, puis Enregistrer.
5. Accédez au fichier et renommez-le avec l'extension .cer.
6. Ouvrez et affichez ce fichier (utilisateurs MS Windows).
7. Vérifiez le champ Émis par. S'il correspond au champ Émis à, le certificat est auto-signé (voir l'exemple).

Exemple : Certificat auto-signé/privé signé par l'autorité de certification

                                      Auto-signé                                                                                               Signé par une autorité de certification privée

Générer une requête de signature de certificat (CSR)

Note: Cet exemple concerne CUCM version 8.x. Le processus peut varier d'un serveur à l'autre.

1. Accédez à Cisco Unified OS Administration.
2. Choisissez Security > Certificate Management.
3. Cliquez sur Generate CSR, puis sélectionnez Tomcat dans la liste déroulante.
4. Cliquez sur Generate CSR, puis sur Close.
5. Cliquez sur Télécharger CSR, puis sélectionnez Tomcat dans la liste déroulante.
6. Cliquez sur Télécharger CSR, puis enregistrez le fichier.
7. Envoyez le fichier .csr à signer par votre serveur d'autorité de certification privée ou une autorité de certification publique.
   

   Note: Une fois que vous avez ce fichier CSR, le processus varie en fonction de votre environnement.

8. Cliquez sur Upload Certificate/Certificate Chain sous Security > Certificate Management Afin de recharger les nouveaux certificats signés qui ont été émis sur votre serveur.

Comment importer des certificats dans les magasins de certificats de périphérique utilisateur ?

Chaque certificat de serveur doit avoir un certificat racine associé présent dans le magasin d'approbation sur le périphérique utilisateur. Cisco Jabber valide les certificats que les serveurs présentent par rapport aux certificats racine dans le magasin d'approbation.

Importer les certificats racine dans le magasin de certificats MS Windows si :

• Les certificats sont signés par une autorité de certification qui n'existe pas déjà dans le magasin de confiance, par exemple une autorité de certification privée. Si c'est le cas, vous devez importer le certificat d'autorité de certification privée dans le magasin Autorités de certification racines de confiance.
• Les certificats sont auto-signés. Si c'est le cas, vous devez importer des certificats auto-signés dans le magasin Enterprise Trust.

Vous pouvez utiliser n'importe quelle méthode appropriée pour importer des certificats dans le magasin de certificats MS Windows, par exemple :

• Utilisez l'Assistant Importation de certificats afin d'importer des certificats individuellement.
• Déployez des certificats vers des utilisateurs à l'aide de l'outil de ligne de commande CertMgr.exe sur MS Windows Server. (Cette option nécessite que vous utilisiez l'outil Certificate Manager, CertMgr.exe, et non la console de gestion MS Certificates, CertMgr.msc.)
• Déployer des certificats vers des utilisateurs avec un objet de stratégie de groupe sur MS Windows Server.

Note: Pour obtenir des instructions détaillées sur la façon d'importer des certificats, reportez-vous à la documentation de MS appropriée.

Identité du serveur dans les certificats

Dans le cadre du processus de signature, l'autorité de certification spécifie l'identité du serveur dans le certificat. Lorsque le client valide ce certificat, il vérifie que :

• Une autorité de confiance a émis le certificat.
• L'identité du serveur qui présente le certificat correspond à l'identité du serveur spécifié dans le certificat.

Note: Les autorités de certification publiques nécessitent généralement un nom de domaine complet (FQDN) comme identité de serveur et non comme adresse IP.

Champs d'identificateur

Le client vérifie ces champs d'identificateur dans les certificats du serveur pour rechercher une correspondance d'identité :

Certificats XMPP

• SubjectAltName\OtherName\xmppAddr
• SubjectAltName\OtherName\srvName
• SubjectAltName\dnsNames
• Objet CN

Certificats HTTP

• SubjectAltName\dnsNames
• Objet CN

Note: Le champ CN d'objet peut contenir un caractère générique (*) comme caractère le plus à gauche ; par exemple, *.cisco.com. Il se peut que vos serveurs CUCM, CUP et Cisco Unity Connection ne prennent pas en charge les certificats génériques. (Reportez-vous à l'amélioration de l'ID de bogue Cisco CSCta14114).

Empêcher la discordance d'identité

Lorsqu'un client Jabber tente de se connecter à un serveur avec une adresse IP et que le certificat du serveur identifie le serveur avec un nom de domaine complet (FQDN), le client ne peut pas identifier le serveur comme étant approuvé et invite l'utilisateur. Par conséquent, si vos certificats de serveur identifient les serveurs avec des noms de domaine complet (FQDN), vous devez spécifier le nom de serveur en tant que nom de domaine complet (FQDN) à de nombreux endroits de vos serveurs.

Le tableau 3 répertorie tous les emplacements qui doivent spécifier le nom de serveur tel qu'il apparaît dans le certificat, qu'il s'agisse d'une adresse IP ou d'un nom de domaine complet (FQDN). 

Tableau 3

Serveur	Emplacement (le paramètre doit correspondre au certificat)
Clients Cisco Jabber	Adresse du serveur de connexion (Différents pour les clients, généralement sous Paramètres de connexion)
CUP (version 8.x et antérieure)	** Tous les noms de noeuds (Système > Topologie de cluster) **Attention : Assurez-vous que si vous changez ceci en FQDN, vous pouvez résoudre ceci via DNS ou les serveurs restent dans l'état de démarrage ! Serveurs TFTP (Application > Cisco Jabber > Paramètres) Téléphone IP Cisco Call Manager principal et secondaire (CCMCIP) (Application > Cisco Jabber > Profil CCMCIP) Nom d'hôte de la messagerie vocale (Application > Cisco Jabber > Serveur de messagerie vocale) Nom de la banque de messages (Application > Cisco Jabber > Mailstore) Nom d'hôte de conférence (Application > Cisco Jabber > Serveur de conférence) (Meeting Place uniquement) Domaine XMPP (voir la section Fournir le domaine XMPP aux clients)
Messagerie instantanée et présence CUCM (versions 9.x et ultérieures)	**Tous les noms de noeuds (Système > Topologie de cluster) **Attention : Assurez-vous que si vous changez ceci en FQDN, vous pouvez résoudre ceci via DNS ou les serveurs restent dans l'état de démarrage ! Serveurs TFTP (Application > Clients hérités > Paramètres) CCMCIP principal et secondaire (Application > Clients hérités > Profil CCMCIP) Domaine XMPP (voir la section Fournir le domaine XMPP aux clients)
CUCM (version 8.x et antérieure)	Nom du serveur (Système > Serveur)
CUCM (version 9.x et ultérieure)	Nom du serveur (Système > Serveur) Serveur de messagerie instantanée et de présence (Gestion des utilisateurs > Paramètres utilisateur > Service UC > Messagerie instantanée et présence) Nom d'hôte de la messagerie vocale (Gestion des utilisateurs > Paramètres utilisateur > Service UC > Messagerie vocale) Nom de la banque de messages (Gestion des utilisateurs > Paramètres utilisateur > Service UC > Magasin de messages) Nom d'hôte de conférence ((Gestion des utilisateurs > Paramètres utilisateur > Service UC > Conférence) (Meeting Place uniquement)
Cisco Unity Connection (toutes versions)	Aucune modification requise

Fournir un domaine XMPP aux clients

Le client identifie les certificats XMPP avec le domaine XMPP, plutôt qu'avec le nom de domaine complet (FQDN). Les certificats XMPP doivent contenir le domaine XMPP dans un champ d'identificateur.

Lorsque le client tente de se connecter au serveur de présence, le serveur de présence fournit le domaine XMPP au client. Le client peut ensuite valider l'identité du serveur de présence par rapport au certificat XMPP.

Complétez ces étapes afin de vous assurer que le serveur de présence fournit le domaine XMPP au client :

1. Ouvrez l'interface d'administration de votre serveur de présence, soit l'interface d'administration de la messagerie instantanée et de la présence de Cisco Unified CM, soit l'interface d'administration de Cisco Unified Presence.
2. Accédez à Système > Sécurité > Paramètres.
3. Recherchez la section Paramètres du certificat XMPP.
   
4. Spécifiez le domaine du serveur de présence dans le champ Nom de domaine de l'objet de certificat XMPP serveur à serveur.
5. Cochez la case Utiliser le nom de domaine pour l'autre nom du sujet du certificat XMPP.
6. Click Save.
7. Après avoir enregistré cette modification, vous devez régénérer le certificat cup-xmpp sur le serveur.
8. Redémarrez le routeur XCP afin que la modification prenne effet.
   
   

   Attention : Redémarrage du service d'impact du routeur XCP.

La validation du certificat est maintenant terminée !

Informations connexes

• Notes de version de Cisco Jabber 9.2.5
• Cisco Jabber : Note technique sur la validation obligatoire des certificats de serveur
• Support et documentation techniques - Cisco Systems