Recevoir et publier le certificat
Dernière rubrique modifiée : 2010-12-13
L’étape suivante du processus de connexion correspond à l’envoi par l’appareil d’une demande de signature de certificat aux services Web. L’appareil se sert de ce certificat pour fournir un canal de communication plus sécurisé qui utilise le protocole TLS (Transport Layer Security) avec les services Web ou le serveur d’inscriptions.
L’appareil envoie une demande de signature de certificat (CSR) SOAP (Simple Object Access Protocol) aux services Web. Les services Web répondent en retournant un certificat pour l’utilisateur de cet appareil, signé par la clé privée des services Web. De plus, ce certificat sera publié dans le magasin de données du pool d’accueil de l’utilisateur.
Problème 1 : impossible de publier le certificat
Problème : les services Web ne peuvent pas publier le certificat demandé par l’appareil car ils ne peuvent pas se connecter au magasin de données des services d’utilisateurs sur le pool sur lequel l’utilisateur est hébergé. Un événement est inscrit dans le journal des événements IIS, remarquant que le magasin de données ne peut pas être atteint : « Magasin de données indisponible ». Cela peut se produire chaque fois que le magasin de données des services d’utilisateurs n’est pas situé sur le même serveur que les services Web.
Résolution : il peut s’agit d’une erreur sporadique indiquant un problème de connectivité entre le serveur d’inscriptions auquel est connecté l’appareil, ou peut-être un problème régulier. Dans le premier cas, réitérez la requête de l’appareil en redémarrant ce dernier. Pour ce faire, débranchez le cordon d’alimentation de l’appareil, patientez quelques secondes, puis rebranchez le cordon d’alimentation. L’appareil recommence le processus de connexion, avant d’envoyer à nouveau la demande de publication du certificat. Cette fois, les services Web sont en mesure de publier le certificat de l’utilisateur dans le pool d’accueil de ce dernier et retourne le certificat à l’appareil. Pour déterminer s’il s’agit d’un problème plus important et qui n’est pas lié à l’appareil, exécutez la transaction synthétique test-CsPhoneBootstrap :
test-CsPhoneBootstrap -PhoneorExt <phone or ext of user> -PIN <user's PIN> -UserSipAddress <user's SIP URI> -verbose
Cette transaction démontre que le numéro de téléphone de l’utilisateur et le code confidentiel correspondent à l’URI de l’utilisateur.
Vous pouvez ajouter les paramètres –TargetCertProvWSURL <URL des services Web> et –TargetFqdn <Nom de domaine complet (FQDN) du serveur d’inscriptions> pour contourner la détection DHCP.
Problème 2 : impossible de publier le certificat en raison d’un problème du serveur d’inscriptions
Problème : le certificat qui est généré par les services Web ne peut pas être généré ou publié en raison d’un problème sur le serveur d’inscriptions.
Résolution : vérifiez l’état du serveur d’inscriptions en consultant d’abord le pack d’administration de Microsoft System Center Operations Manager afin de détecter des alertes liées au serveur d’inscriptions auquel l’appareil est en train de se connecter. Dans System Center Operations Manager, naviguez jusqu’au serveur d’inscriptions et affichez toutes alertes critiques ou modifications d’état indiquant un problème non critique. Suivez les instructions afin de résoudre le problème. Si Operations Manager n’est pas disponible, effectuez une vérification en utilisant la transaction synthétique suivante.
$cred = get-credential
test-CsClientAuth -UserSipAddress <sip address> -UserCredential $cred -TargetFQDN
.gif "note") Remarque : |
|---|
| Si vous voulez utiliser la détection DHCP, ne spécifiez pas –TargetFQDN. Si vous ne voulez pas utiliser la détection DHCP, fournissez le nom de domaine complet (FQDN) de la destination dans la transaction synthétique ce qui aura pour effet de contourner la détection DHCP. Le résultat devrait vous indiquer le stade auquel l’authentification a échoué (par exemple, le message de détection DHCP ne reçoit pas forcément de réponse). Suivez les instructions figurant dans le résultat de la transaction pour résoudre le problème. Vous pouvez vérifier si le serveur Web est en cours d’exécution en consultant le journal certprov.log dans Ocslogger (c’est-à-dire, généré sur chacune des instances rtcsrv au sein du pool). Vous devez obtenir des journaux de tous les serveurs dans le pool car, en effet, à ce stade, nous ne savons pas vers lequel l’appareil est dirigé. Une fois les problèmes résolus, redémarrez l’appareil pour déclencher une nouvelle tentative de connexion. Cette fois, le certificat doit être publié sur le pool sur lequel l’utilisateur est hébergé et retourné à l’appareil. |
Problème 3 : impossible de vérifier le certificat des services Web
Problème : l’appareil ne peut pas vérifier le certificat présenté par les services Web pour les communications TLS. Il utilise la chaîne de certificats racine qui est téléchargée lorsque l’appareil se connecte pour la première fois au serveur Web. Si cette chaîne n’a pas le chemin d’approbation complet de l’autorité de certification au serveur Web, le certificat présenté par le serveur Web est impossible à vérifier.
Résolution : l’appareil dispose d’un nombre de certificats d’autorités de certification réputées lors de sa livraison. Il est important que le certificat utilisé pour identifier le serveur Web émis par une autorité de certification dispose d’une chaîne d’approbation jusqu’à l’une de ces autorités de certification racine. Dans le cas contraire, l’appareil ne sera pas en mesure de valider le certificat que le serveur présente pour les communications TLS.
Informations complémentaires
Vous pouvez contourner l’étape de réception et de publication du certificat à l’aide d’un câble USB pour connecter l’appareil à un ordinateur exécutant Lync. Ce processus se charge de l’obtention et de la publication du certificat et installera également le certificat sur l’appareil.