Por Daniel Seveso
Intro
Como introducción repasemos primero brevemente, cómo Outlook resuelve este asunto:
Cuando leemos un mensaje firmado (signed) en Outlook, nuestro cliente realiza las verificaciones necesarias para asegurarnos que el mismo ha sido firmado utilizando un certificado válido, y emitido por una autoridad certificadora en la cual confiamos. Outlook verifica además que la cadena de certificación sea confiable hasta el primer certificado (root). En el ejemplo de abajo, el cliente que esté leyendo mi mensaje firmado, tendrá que confiar (tener sus certificados públicos instalados en el “certificate store”) en las certificadoras intermedias “Microsoft Personnel E-mail CA1” y “Microsoft Internet Authority”, asi como también en el root “GTE Cyber Trust Global Root”. Todo este proceso se realiza en forma local en en nuestro cliente.
Además de este proceso escencial para la confianza en un certificado, Outlook consulta la propiedad “CRL Distribution Points” del certificado, y baja la lista de certificados revocados o CRL. Esta lista continene los certificados que han sido dados de baja por su emisor por cualquier motivo. Para este proceso Outlook tiene que conectarse y bajar la CRL del URL indicado.
Por cada certificado en la cadena que tenga esta propiedad, Outlook se conectará, bajará y pondrá en cache local la CRL. Luego que la CRL se baja por primera vez, Outlook la efectúa las consultas subsecuentes al cache, mientras que la fecha de expiración del CRL sea mayor a la actual. A su vez, Outlook consultará sólo una vez la CRL (sea externamente o la copia en cache) por sessión de Outlook, almacenando temporalmente el resultado de la consulta al CRL en tanto Outlook siga ejecutando.
Esta operación se realiza por usuario (perfil de usuario Windows), o sea que si un nuevo usuario inicia sesión en la misma estación de trabajo, y leemos el mismo mensaje, otra copia de la CRL será bajada en el cache del perfil actualmente logueado.
Proceso en OWA (Exchange 2003)
Para poder usar firmas y encripción de mensajes en OWA, primero tenemos que instalar por única vez el control S-MIME desde la página de opciones de OWA.
Si ya está instalado, veremos lo siguiente:
El proceso de instalación del control, se realiza por cada usuario (perfil de usuario Windows).
La diferencia fundamental en contraste con Outlook, es que tanto el proceso de validación del certificado como de consulta al CRL se realizan desde el servidor de Exchange 2003 donde reside el mailbox. Si estamos conectados a un ambiente “Front-End / Back-End” el proceso de validación ocurre en el servidor Back-End. Al igual que en Outlook la validación del certificado es local y la consulta al CRL puede consistir en su bajada desde Internet o consulta al cache local.
Exchange 2003 consulta la validez del certificado del remitente y valida la CRL mediante un componente llamado ExDAV, controlado por el proceso store.exe (Microsoft Exchange Information Store). Este detalle es importante, porque el contexto de seguridad en el que corre el proceso store.exe es la cuenta del servidor “Local System”, por lo tanto, todas las CRL bajadas por consultas de usuarios a mensajes firmados, se almacenarán en el cache de este perfil. Al correr con “Local System” la conexión para bajar la CRL también será hecha con este contexto de seguridad. En caso de tener un servidor proxy que requiera autenticación para permitir la salida a Internet, este es un aspecto a tener en cuenta.
Troubleshooting
1) Al igual que con Outlook, para empezar podemos verificar que todos los certificados de la cadena sean confiados por la el servidor de Exchange. Eso lo podemos confirmar abriendo el snap-in “Certificates” del servidor Exchange y verificando que los certificados públicos de cada autoridad certificadora (CA) estén en los contenedores apropiados. Siguiendo con el caso de mi certificado, en el servidor deberías encontrar lo siguiente:
2) Así como Outlook consulta la CRL una vez por sesión, el store.exe hace lo mismo, por lo que si abrimos un mensaje que cuya CRL ya ha sido consultada por otro usuario, la misma no se volverá a consultar al cache o a Internet si la fecha es anterior a su fecha de expiración. A efectos de troubleshooting, una acción práctica que podemos realizar si fuese necesario, es reiniciar el servicio Microsoft Exchange Information Store para provocar una nueva consulta al cache o a Internet.
Si la CRL se encuentra en Cache, se consultará del mismo. Sólo se consultará externamente si la fecha actual es mayor que su fecha de expiración. Si la fecha del día es posterior a la fecha “Next Update” de la CRL, Outlook o el Store.exe bajaran una nueva versión de la URL correspondiente.
3) Certutil es una herramienta que puede ayudarnos en el troubleshooting de problemas bajando el CRL. Certutil se incluye en Windows 2003 Server, y podemos usarla por ejemplo para lo siguiente:
¿Cómo sabemos si la CRL está en cache? –> certutil –urlcache CRL
Considerando que el cache es por usuario, como consulto el cache de la cuenta “Local System”? –> tienes que correr la herramienta en el contexto de la cuenta de máquina. Una forma es utilizar el servicio de scheduler para abrir una ventana de comandos CMD en el contexto de Local Sytem usando el comando –> AT hh:mm /interactive cmd (tienes que estar logueado a la consola del servidor o en una session de terminal de consola (mstsc /console)).
¿Como podemos borrar el cache para provocar un nuevo download? –> certutil –urlcache CRL delete (recuerda que deberías reiniciar el Information Store si el CRL ya fue consultado desde que el servicio se inició por última vez)
¿Como podemos confirmar que estamos llegando a la crl desde nuestro servidor? –> certutil –url <dirección del CRL>
por ejemplo: certutil –url http://www.public-trust.com/cgi-bin/CRL/2018/cpd.crl
¿Como sé la fecha de expiración del CRL? –> una forma es abrir el archvo.crl que bajamos de la autoridad certificadora.
Otra forma de consultar la fecha de expiración es usando el comando –> certutil –dump <archivo.CRL>
4) Si sospechamos de problemas de conectividad con los sitios externos, lo mejor es utilizar Network Monitor para verificar los intentos de resolución de nombres DNS y posterior intento de conexión al sitio indicado en “CRL Distribution Points”.
5) Verifica que el proxy utilizado para conexión a Internet no esté afectando la conexión del servidor a la CRL. Recuerda que para el caso de OWA el contexto de seguridad de esta conexión es “Local System” y si usamos un proxy que requiera autenticación de salida, la conexión fallará. Este caso puede ser remediado creando una regla de protocolo anónima para la dirección IP del servidor Exchange.
6) En caso que por política de empresa el servidor de Exchange NO tenga acceso a Internet, la CRL no podrá ser consultada (creo qeu es bastante obvio). Lo que quiero remarcar en este caso, es que podemos configurar un valor de registry en el servidor para que Exchange excluya la consulta al CRL como parte de la validación del certificado. El resto de los controles de validación seguirán siendo efectuados normalmente. Esta clave de registry evitará que el cliente reciba el aviso
Inglés: "The validity of the digital ID can't be determined because the
server that provides this information can't be contacted"
Portugués: "A validade da identificação digital não pode ser
determinada, pois o servidor que fornece essa informação não pode ser
contactado."
(no pude encontrar el mensaje exacto en Español. Por favor si alguien lo tiene envíenlo a través de nuestros comentarios)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeWeb\OWA
DisableCRLCheck (DWord) =1
Espero que sea de utilidad y les ahorre algún tiempo en su troubleshooting!
