OCSP frente a una CRL: cómo funciona realmente cada comprobación de revocación

Una de estas dos comprobaciones de revocación devuelve una respuesta firmada sobre un solo certificado, y la otra devuelve una lista firmada que se descarga entera. Ambas deben decir a un verificador si una credencial sigue siendo de confianza, y ambas fallan de maneras que no se parecen en nada. El orden siguiente sigue lo que un operador encuentra realmente en producción, empezando por los bytes en el cable y terminando con una puerta de enlace que rechaza una conexión. Saltarse un paso es la forma en que un despliegue acaba con una política de revocación que solo existe en el papel.

Paso 1: Qué devuelve cada comprobación y cuánto tiempo sigue siendo utilizable

Una CRL se publica como un único objeto firmado que cubre todos los certificados que un emisor ha revocado, así que un verificador la descarga una vez y la reutiliza hasta que pasa el nextUpdate de la lista. Una respuesta OCSP es más estrecha: responde exactamente por un certificado y lleva thisUpdate, producedAt y normalmente también nextUpdate. Esa diferencia gobierna todo lo demás. Una CRL en caché caduca en silencio, porque el archivo todavía se analiza y su firma todavía se verifica, mientras que una respuesta OCSP caducada es obviamente inútil en el momento en que se leen sus marcas de tiempo.

Por eso el almacenamiento en caché es lo primero que hay que fijar: qué componente guarda la copia y a qué techo obedece esa copia. En una puerta de enlace el techo debería ser nextUpdate menos un margen de seguridad, nunca lo que sugiera por casualidad una cabecera de caché HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate imprime ambas fechas, y una lista cuyo nextUpdate ya está en el pasado debe tratarse como ausente y no solo como antigua.

Paso 2: Hacia dónde apunta el certificado al cliente

El certificado hoja suele llevar dos pistas: una extensión de punto de distribución de CRL y una entrada de acceso a la información de la autoridad para OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints imprime la primera, y la segunda está bajo la sección AIA de openssl x509 -in client.pem -noout -text. Cualquiera de las dos extensiones es un puntero, no una obligación. Un cliente que nunca implementa la comprobación de revocación se conectará perfectamente a un certificado cuyas extensiones nombran un respondedor que lleva un año muerto.

Los puntos de distribución suelen nombrar un host interno que solo resuelve dentro de un segmento de red, y algunos clientes antiguos rechazan las URL ldap sin más. Pruebe la accesibilidad desde el host que termina el túnel, no desde su propio portátil, porque ese es el único punto de vista cuya falla realmente importa.

Paso 3: Elija fail-closed o fail-open antes de la caída

Un respondedor inalcanzable o una lista caducada obligan a decidir: rechazar la conexión, o aceptarla y registrar el hueco. El subcomando verify de OpenSSL hace explícita la opción estricta, porque añadir -crl_check convierte una CRL no disponible en unable to get certificate CRL y una verificación fallida. El soft-fail en la mayoría de las pilas no es una bandera en absoluto, es la ausencia de la comprobación, y por eso mismo llega por accidente.

Para ver qué comportamiento tiene realmente un cliente, quite el respondedor y vuelva a conectar. Si el túnel sigue levantándose, busque la línea de registro que anotó la comprobación omitida y pregúntese si alguien leería esa línea durante un incidente. El mismo proveedor puede diferir por protocolo, con un cliente IKEv2 y un cliente OpenVPN en una máquina leyendo ajustes de configuración no relacionados.

Paso 4: Demuestre que la comprobación se ejecuta donde se admite el tráfico

Encuentre el proceso que termina o autoriza la conexión y pregúntele por la línea de configuración que habilita la comprobación de revocación. Una puerta de enlace que valida la cadena pero nunca pregunta por la revocación aplica una política distinta de la que hay en su documentación, y ninguna captura de pantalla de una cadena de certificados demuestra lo contrario. OpenVPN escribe la opción como crl-verify; strongSwan mantiene las búsquedas de CRL y OCSP bajo la configuración de la CA, donde se establecen crl_uris o ocsp_uris. Si no puede señalar ninguna de las dos, suponga que la comprobación está ausente.

Una respuesta OCSP solo cuenta cuando la ha firmado la CA emisora, o cuando la ha firmado un respondedor que tiene el uso de clave extendido OCSPSigning delegado por esa CA, así que una respuesta de un servicio no relacionado no demuestra nada. Si usted mismo ejecuta el respondedor, monitorícelo como una dependencia dura, porque un solo servicio muerto se convierte en una caída para cada cliente fail-closed a la vez.

Paso 5: Revoque un certificado a propósito

Tome un certificado de prueba, revóquelo por el mismo canal que usa producción y pregunte directamente al respondedor. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text debería informar de Cert Status: revoked junto con una hora de revocación, y una respuesta good significa que su revocación no llegó al respondedor que consultan sus clientes. Después ejecute openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem para ver la misma decisión por la ruta de la lista. Lea la cadena del motivo en lugar del código de salida, porque un rechazo por revocación y un error de cadena acaban ambos en fallo.

El paso que realmente importa es el último: vuelva a conectar con el perfil antiguo contra el punto de aplicación real y confirme que el rechazo viene de la revocación. Después vuelva a conectar con un certificado nuevo y válido para demostrar que no se ha limitado a romper el oyente. Borrar el perfil en el cliente no demuestra nada sobre la decisión del servidor, y tampoco lo hace una ejecución correcta de openssl verify en una máquina que nunca termina un túnel. RFC 6960 define qué contiene una respuesta OCSP conforme, incluidos los valores de estado que lee esta prueba.