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.
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) |
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.
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 :
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 :
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.
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 :
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.
Exemple : Certificat auto-signé/privé signé par l'autorité de certification
Auto-signé Signé par une autorité de certification privée
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 :
Vous pouvez utiliser n'importe quelle méthode appropriée pour importer des certificats dans le magasin de certificats MS Windows, par exemple :
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 :
Le client vérifie ces champs d'identificateur dans les certificats du serveur pour rechercher une correspondance 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 |
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 :
La validation du certificat est maintenant terminée !