Error en la comprobación de revocación a la hora de arrancar una entidad certificadora
Hola a todos. Soy Tolu Igbon, del equipo de Directorio Activo.
Un caso común que tratamos en el área de soporte de Directory Services es el siguiente error al intentar arrancar una entidad certificadora (CA) subordinada:
The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)
El comportamiento puede producirse nada más intentar arrancar la CA por primera vez, o pasado un tiempo (semanas, meses) tras haber estado funcionando con normalidad.
Antes de comenzar con el diagnóstico del error, vamos a comenzar por recordar algunos conceptos básicos sobre el funcionamiento de certificados:
Basic Certificate Validation:
For a certificate to function properly, the following items must validate correctly (at a minimum):
1. Subject name: The subject of the certificate must match the resource subject that is being used. For example, when using https the subject in the certificate being used on the web server must match the https URL that users will use to connect to the https website. Subject name is analogous to the name on a driver’s license.
2. Validity Period: The (Valid From) and (Valid To) must be within the time frame the certificate is planning on being used. This is much like the expiration of a driver’s license. Validity period is analogous to the expiration date on a driver’s license.
3. Trust: The certificate must be used by a trusted Certificate Authority. Trust is analogous to the State that issued a driver’s license. Because the State that issued the license is a member of the union that makes up the United States we trust the issuer of the license.
4. Chain Building: Chain building is the process of building a trust chain, or certification path, from the end certificate to a root CA that is trusted by the security principal. The chain-building process will validate the certification path by checking each certificate in the certification path from the end certificate to the root CA’s certificate.
5. Key Usage: To help control the usage of a certificate outside of its intended purpose, the optional Enhanced Key Usage extension can be included in the certificate by the CA. The Enhanced Key Usage extension contains a list of usages for which the certificate is valid. These usages, also known as intended purposes, are displayed on the General tab of the certificate dialog box. This is important when evaluating why a certificate may not be working correctly. Key Usage is analogous to driver’s license endorsements (types of vehicles that can be driven with this license).
6. Revocation Checking: Each certificate in the certificate chain is verified to ensure that none of the certificates are revoked. A certificate can be revoked prior to the expiration date to disavow the certificate. Revocation Checking is analogous to checking a driver’s license against a State database to verify that a driver’s license has not been revoked for a violation.
En el caso que nos interesa hoy, el punto clave es el 6, donde se habla sobre la comprobación de revocación.
El certificado de la CA subordinada, al igual que cualquier certificado de usuario/cliente, viene con un campo/atributo “CRL Distribution Points” (CDP) donde se especifican uno o varios
· Puntos de acceso al directorio activo (rutas LDAP),
· Servidores web (direcciones http/https) o
· Recursos compartidos de red.
En estos CDP el cliente puede encontrar una lista de certificados revocados firmada por su CA emisora y comprobar si su propio certificado es válido o no.
El error recibido en el caso que estamos tratando nos indica que no se puede comprobar el estado de revocación de nuestro certificado (el de la propia CA Subordinada) porque o bien el servidor de revocación (donde comprobamos la lista de certificados revocados) está fuera de línea (apagado) o no se puede acceder a él.
En este caso, esto impide que arranquen los servicios de la CA, mientras que en otros escenarios, como en el inicio de sesión a través de tarjetas inteligentes (SmartCard), podría implicar que el usuario no pueda iniciar sesión en el dominio.
Troubleshooting/Solución
En el escenario que tratamos hoy, tenemos varias opciones para el diagnóstico/resolución del problema, en función de cómo esté configurado nuestro entorno:
1. Podría ser que la CA raíz que actualiza las listas de revocación (CRLs) realmente esté “offline” (y que la CRL que tiene la CA subordinada esté caducada)
· Es una práctica común mantener una CA Raíz apagada e inaccesible por cuestiones de seguridad
· Para resolver el problema, debería ser suficiente con volver a arrancar la CA raíz y publicar una nueva CRL. Normalmente, la CA Raíz publicará su lista (de larga duración) en un servidor web que se mantendrá en línea para que los clientes (la CA subordinada) puedan verificar la CRL por HTTP.
2. La CA Raíz o, en su defecto, el servidor donde se publican las CRLs sí está en línea y tiene publicada una CRL actualizada pero nuestro cliente (la CA Subordinada) no puede acceder a ella
· Normalmente, para verificar si podemos acceder correctamente a un CDP por HTTP podemos:
o Intentar navegar a la URL en una ventana de Internet Explorer
P.ej https://ServidorWeb/Crl/Archivo.crl
o Utilizar la herramienta Certutil para comprobar si podemos acceder
P.ej certutil -URL [URL]
certutil -URL https://ServidorWeb/Crl/Archivo.crl
o O podemos exportar una copia del certificado cuya revocación queremos comprobar y ejecutar el comando
certutil -url <exportedcert.cer>
En el cuadro de dialogo “Verify and Retrieve” que nos aparece, seleccionamos “From CDP” y verificamos el resultado
En el 99% de los casos, nosotros (el usuario con el que hemos hecho las pruebas) podremos acceder correctamente a la CRL por los métodos anteriores.
Entonces, la pregunta sería: ¿por qué el mensaje de error indica que el servidor de revocación esta fuera de línea? La clave está en el contexto de seguridad con el que se intenta acceder al CDP.
La CA funciona bajo el contexto de la cuenta Local System, o dicho de otra manera, de la propia cuenta de máquina. Por lo tanto, deberemos verificar si la cuenta de maquina puede acceder a los CDP al igual que nuestro usuario puede hacerlo.
Esta vez, para realizar las comprobaciones anteriormente descritas, utilizaremos la herramienta AT.exe (el programador de tareas de Windows Server 2003) para poder ejecutar los comandos en el contexto de Local System.
(NOTA: La correcta ejecución de las pruebas con AT.exe depende de que el programador de tareas este configurado para ejecutarse bajo la cuenta Local System – configuración por defecto en Windows)
· Programamos una tarea para lanzar una ventana de comandos a las 15:00:
AT 15:00 /INTERACTIVE CMD.EXE
· A las 15:00 se lanza una ventana de comandos en el contexto de Local System
· Desde esta ventana de comandos lanzamos Internet Explorer (iexplore.exe) y ejecutamos Certutil de nuevo para comprobar si la cuenta de maquina puede acceder correctamente a los CDP por http
Bajo el supuesto que estamos tratando hoy, en la mayoría de los casos, Certutil fallará al intentar verificar la URL especificada, e Internet Explorer mostrará un error de acceso o un cuadro de diálogo solicitando credenciales para acceder a la URL a través del proxy.
En este punto, ya habríamos determinado el origen del problema: La CA Subordinada efectivamente no puede acceder a la información de revocación porque la cuenta de maquina no puede acceder a la URL a través del proxy.
La solución suele radicar en dar permisos a nivel de proxy para que la máquina pueda acceder correctamente, o modificar las opciones de Proxy en la configuración de Internet Explorer (en el contexto de Local System)
Una vez hechos los cambios pertinentes, podemos comprobar que la maquina ya accede correctamente al CDP, y la CA ya podrá arrancar correctamente.
Enlaces de interés:
· Certificate Revocation and Status Checking
· Basic CRL checking with Certutil
· Troubleshooting Certificate Status and Revocation
- Tolu Igbon