Certificados Revocados y Lync o Skype For Business

La revocación de un certificado es anular su validez, además desde el mismo momento en que es revocado. Este proceso es muy común cuando se ha comprometido la seguiridad del certificado, y creemos que alguien conoce las claves privadas del mismo. O también porque queremos simplemente darlo de baja porque dejará de estar vigente y no queremos tener problemas con el mismo. Os comento esto por lo siguiente, es posible que tengáis que renovar vuestro certificado y a alguien se le de por revocar el certificado antes de tiempo … Son dos procesos que pueden ir por separado sin problema, puesto que si nosotros tenemos que renovar nuestro certificado  (para Lync o Skype For Business por ejemplo) el hacerl no invalida el que está a punto de caducar. Por lo que podemos renovar el certificado x días de antes de que expire el actual certificado, y este seguirá funcionando sin problema. Y si instalamos el nuevo certificado también funcionará sin problemas, el antiguo lo hará hasta que expire. El proceso “normal” sería renovar el certificado y si el anterior no ha expirado, pues revocarlo e instalar el nuevo en los servicios que lo necesitemos. La revocación en una CA Pública (DigiCert, Verisign, Geotrust, etc..) es responsabilidad suya, y si configuramos una CA interna clarament es algo que podemos hacer nosotros mismos.

Dicho todo esto, veamos que ocurre cuando se aplica esto a Lync o Skype For Business en el proceso de la federación. Pensemos que tenemos todo nuestro escenario implementado y está funcioando sin problemas, pero llega el momento de renovar el certificado y mientras estamos esperando a que el proveedor nos haga llegar el certificado nuevo nos damos cuenta de que la federación no funciona y porqué …. puesto por cosas como esto:

Y aquí es donde no hay que volverse loco revisando y cambiando todo lo que está a nuestro alcance, si hasta la fecha ha funcionado sin problema, empecemos por revisar algo básico:

Este evento es del servidor EDGE el cual quiere conectarse al otro EDGE el cual tiene el certificado revocado, y como vemos no los dice claramente: 0X80092010 (CRYP_E_REVOKED).

Aquí no hay lugar a duda, puesto que como sabéis en el proceso de conexión y verificación del certificado los sistemas siempre comprueban varias cosas antes de dar como bueno el certificado presentado por el servidor al que nos queremos conectar:

• Si el certificado no está expirado en base a la validez del certificado, que esto lo vemos en las propiedades del mismo (Válido desde xx/xx/xxxx hasta xx/xx/xxxx

• Si el certificado es de confianza para nosotros, para ello necesitaremos tener el certificado raíz de la entidad certificadora que ha emitido el certificado para el servidor de destino en nuestro almacén local de certificados. Porque sino es así, es cuando nos encontramos el error de que no podemos verificar el certificado que nos presenta el servidor y no podremos conectarnos (para ver el almacén local de certificados de equipo abriremos la consolsa certlm.msc). Si nos vamos a la capeta certificados dentro de Entidades de certificación de Confianza podemos ver las entidades públicas y privadas (las instaladas por nosotros) más importantes, por eso los equipos se conectan a sitios públicos con SSL, TLS, etc.. sin que nos muestre el error de que no confiamos en el certificado porque no podamos verificarlo por su ruta de certificación). En el caso que os muestro, el certificado es uno wildcard (*.asirsl.com) que ha sido emitido por DigiCert y que nosotros en nuestro almacén local de certificados tenemos el certificado raíz de la CA que ha emitido nuestro certificado.

Pero el problema es más “simple”, porque nos lo indica de forma clara, el certificado ha sido revocado, por lo que el proceso de federación no se puede completar. Eso es justamente lo que tiene que hacer, además de todo lo anterior, verificiar que el certificado no esté revocado. Para ello se conectará a las CRL o OCSP para ver si el número de serie del certificado presentado por el servidor al que queremos conectarnos está incluido en dicha lista, si lo está, es que ha sido revocado, en caso contrario nuestro servidor lo vería como válido (siempre y cuando los puntos anteriores se verificasen con éxito: Fecha y Entidad Raíz de Confianza). La información  de la comprobación de la CRL (Certificate Revocation List)  o OCSP (Online Certificate Status Protocol) en donde se encuentra? .. esa información la tenemos en el certificado y que los sistemas la consultará para saber donde están las CRL  (sistema bastante precario en la actualidad, es un fichero que se actualiza en modo “offline” (es mucho más que eso, pero eso lo comentaremos en otro artículo)) o OCSP (más moderno y actual, es un sistema “online” de comprobar los certificados (es mucho más que eso, pero eso lo comentaremos en otro artículo)). Si vamos a la pestaña Detalles dentro de las propiedades del certificado podemos ver las URL de las CRL y OCSP de la CA que ha emitido este certificado, las cuales están disponibles para que los sistemas puedan connectarse y ver si el certificado está o no en dichas listas.

Ahora como siempre, vamos a ver que realmente esto es así , para ello utilizaremos nuestro amigo Wireshark para que podemos ver de forma “gráfica” el resultado de la consulta de la CRL u OCSP. Aquí teneís una traza de wireshark en donde ya tenemos la consulta al OCSP de la CA (Thawte SSL CA) que ha emitido el certificado que nos muestra el otro EDGE con el que queremos federarnos y vemos claramente el resultado: