Échec de l'enregistrement du téléphone Exp-C/VCS-C sur MRA avec des certificats d'algorithme haché MD5

Introduction

Ce document décrit un problème que vous pourriez rencontrer lors de l'enregistrement de votre téléphone via MRA (Mobile and Remote Access) si le certificat d'algorithme haché MD5 (Message Digest 5) est utilisé et offre une solution au problème.

Problème

L’enregistrement du téléphone échoue sur MRA si le certificat utilisé sur Expressway-C/Video Communication Server (VCS)-C est généré à l’aide de l’algorithme de signature MD5. 

Motif

L'utilisation de l'algorithme de hachage MD5 dans les certificats peut permettre à un attaquant de usurper le contenu, d'effectuer des attaques par hameçonnage ou d'effectuer des attaques man-in-the-Middle. Microsoft a également publié l'an dernier un avis de sécurité qui limitait l'utilisation des certificats avec l'algorithme de hachage MD5. Cette restriction est limitée aux certificats émis sous racines dans le programme de certificats racine Microsoft : Avis de sécurité Microsoft : Mise à jour pour la dépréciation de l'algorithme de hachage MD5 pour le programme de certificat racine Microsoft : 13 août 2013 

L'ID de bogue Cisco CSCuq95204 a été levé pour mettre à jour les documents VCS afin d'indiquer que Cisco ne prend pas en charge les certificats d'algorithme haché MD5.

Vérifier le problème

Cette section explique comment vérifier si votre inscription échoue en raison de ce problème.

Lorsque Jabber tente d’enregistrer un téléphone logiciel sur l’infrastructure Edge/MRA, l’enregistrement du téléphone logiciel Jabber échoue si les machines Expressway utilisent le certificat MD5 haché. Cependant, la nature de l'erreur varie et dépend de la machine qui utilise le certificat haché MD5.

Cas 1 : Expressway-C utilise le certificat MD5-Hashed et Expressway-E possède un certificat avec un algorithme SHA (Secure Hash Algorithm)

Vous rencontrez cette erreur dans les journaux de diagnostic d’Expressway-C :

2014-09-20T06:06:43+05:30 Expressway-C UTCTime="2014-09-20 00:36:43,837" Module=
"developer.cvs.server" Level="INFO" CodeLocation="cvs(132)" Detail="Certificate
verification failure" SubjectCommonName="Expressway-E.edge.com" Error="(SEC_ERROR_
CERT_SIGNATURE_ALGORITHM_DISABLED) The certificate was signed using a signature
algorithm that is disabled because it is not secure."

Après cette erreur, un message « 437 unsupport certificate » vers Expressway-E apparaît.

2014-09-20T06:06:43+05:30 Expressway-C tvcs: UTCTime="2014-09-20 00:36:43,840" 
Module="network.sip" Level="DEBUG":  Action="Sent"  Local-ip="127.0.0.1"  Local-
port="22210"  Dst-ip="127.0.0.1"  Dst-port="25011"  Msg-Hash="5047300400093470988" 
 SIPMSG:
 |SIP/2.0 437 Unsupported Certificate
 Via: SIP/2.0/TCP 127.0.0.1:5060;egress-zone=DefaultZone;branch=z9hG4bKeaaf784fd792
c156da3ff2b664a2eee751464.eb53ca5fcac328dc0f61631ec583fdf4;proxy-call-id=0e01fda1-
6704-4066-bcfd-06e2f3ded8f9;received=127.0.0.1;rport=25011
 Via: SIP/2.0/TLS 10.106.93.182:7001;egress-zone=TraversalserverzoneMRA;branch=z9hG
4bKc4ad3ddb1c5a24099882b10815ee247196.afc37861e975b930c7e624e1d5c6e967;proxy-call-id=
4436ec58-81a4-47a2-b4be-9f0b8b551209;received=10.106.93.182;rport=7001;ingress-zone=
TraversalclientzoneMRA;ingress-zone-id=1
 Via: SIP/2.0/TCP 127.0.0.1:5060;branch=z9hG4bKaa0592c35ecf47289c8efe37792f0c5095;
received=127.0.0.1;rport=25000;ingress-zone=DefaultZone
 Call-ID: 5050433d0d38b156@127.0.0.1
 CSeq: 35384 SERVICE
 From: <sip:serviceproxy@10.106.93.187>;tag=31976bf5fd009665
 To: <sip:serviceserver@10.106.93.187>;tag=f35f010a358ec6dd
 Server: TANDBERG/4130 (X8.2.1)
 Content-Length: 0

Cas 2 : Expressway-E utilise un certificat MD5-Hashed et Expressway-C possède un certificat avec un algorithme SHA

Vous rencontrez cette erreur dans les journaux de diagnostic d’Expressway-E :

2014-11-28T20:17:38+05:30 Expressway-E UTCTime="2014-11-28 14:47:38,393" Module=
"developer.cvs.server" Level="INFO" CodeLocation="cvs(132)" Detail="Certificate 
verification failure" SubjectCommonName="Expressway-C.edge.local" Error="(SEC_ERROR_
CERT_SIGNATURE_ALGORITHM_DISABLED) The certificate was signed using a signature 
algorithm that is disabled because it is not secure."

Après cette erreur, le message « 403 Forbidden » au client Jabber s'affiche.

2014-11-28T20:17:38+05:30 Expressway-E tvcs: UTCTime="2014-11-28 14:47:38,395" 
Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="10.106.93.182" Local-
port="5061" Dst-ip="10.106.93.185" Dst-port="49174" Msg-Hash="8732905073947938174" 
 SIPMSG:
 |SIP/2.0 403 Forbidden
 Via: SIP/2.0/TLS 10.106.93.185:49174;branch=z9hG4bK00006db3;received=10.106.93.185
 Call-ID: 005056ad-6bf90002-000038a2-00003b0a@10.106.93.185
 CSeq: 104 REGISTER
 From: <sip:8002@10.106.93.187>;tag=005056ad6bf9000200007e3c-000005e2
 To: <sip:8002@10.106.93.187>;tag=baa86af3aca9e844
 Server: TANDBERG/4130 (X8.2.1)
 Content-Length: 0

Cas 3 : Expressway-E et Expressway-C utilisent tous deux le certificat MD5-Hashed

Vous rencontrez cette erreur dans les journaux de diagnostic d’Expressway-C :

2014-11-28T20:50:44+05:30 Expressway-C UTCTime="2014-11-28 15:20:44,943" Module=
"developer.cvs.server" Level="INFO" CodeLocation="cvs(132)" Detail="Certificate 
verification failure" SubjectCommonName="Expressway-E.edge.com" Error="(SEC_ERROR_
CERT_SIGNATURE_ALGORITHM_DISABLED) The certificate was signed using a signature 
algorithm that is disabled because it is not secure."

Après cette erreur, le message « 437 unsupport certificate » to Expressway-E apparaît.

2014-11-28T20:50:44+05:30 Expressway-C tvcs: UTCTime="2014-11-28 15:20:44,945"
 Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="127.0.0.1" Local-
port="22210" Dst-ip="127.0.0.1" Dst-port="25753" Msg-Hash="136016498284976281" 
 SIPMSG:
 |SIP/2.0 437 Unsupported Certificate
 Via: SIP/2.0/TCP 127.0.0.1:5060;egress-zone=DefaultZone;branch=z9hG4bK22df47
ed2281a3bf3d88ece09bfbbc3a231977.0dbe343429e681275f6160e8c8af25fe;proxy-call-
id=2ee40ecc-4a1b-4073-87a6-07fbc3d7a6be;received=127.0.0.1;rport=25753
 Via: SIP/2.0/TLS 10.106.93.182:7001;egress-zone=TraversalserverzoneMRA;branch=
z9hG4bK35a8b2cbb77db747c94e58bbf1d16cf1108.1c42f037f9ac98c59766cb84d0d3af10;
proxy-call-id=a8938902-2e0c-4a49-b900-a3b631920553;received=10.106.93.182;rport=
7001;ingress-zone=TraversalclientzoneMRA;ingress-zone-id=1
 Via: SIP/2.0/TCP 127.0.0.1:5060;branch=z9hG4bKb2da522d9f1b5ad1bc2f415f5f01d0d2107;
received=127.0.0.1;rport=25000;ingress-zone=DefaultZone
 Call-ID: 019ed17f1344e908@127.0.0.1
 CSeq: 54313 SERVICE
 From: <sip:serviceproxy@10.106.93.187>;tag=3426bb81de53e3b6
 To: <sip:serviceserver@10.106.93.187>;tag=2128ce8a1f90cb7b
 Server: TANDBERG/4130 (X8.2.1)
 Content-Length: 0

Vérifier l'algorithme de certificat

Cette capture d'écran montre comment vérifier l'algorithme de certificat utilisé.

Solution

Normalement, l'autorité de certification ne fournit plus de certificats avec l'algorithme MD5. Mais parfois, les clients utilisent une approche mixte dans laquelle le certificat sur Expressway-C est généré avec leur autorité de certification Microsoft Enterprise et Expressway-E utilise un certificat émis par une autorité de certification publique telle que GoDaddy.

Si l'autorité de certification racine Microsoft d'entreprise utilise l'algorithme MD5, ce problème se produit. Vous pouvez modifier l'autorité de certification racine afin d'utiliser l'algorithme SHA1 si vous avez des services d'autorité de certification qui s'exécutent sur Microsoft Windows Server 2008. Reportez-vous à la section Est-il possible de modifier l'algorithme de hachage lorsque je renouvelle l'article de l'autorité de certification racine afin de modifier l'algorithme de hachage.