Revocación con CRL y OCSP

Hay dos formas de saber si un certificado sigue siendo válido antes de su fecha de caducidad. La lista de revocación (CRL, perfil del RFC 5280) es un documento firmado por la autoridad con las series revocadas; el cliente la descarga y la guarda hasta su fecha de «siguiente actualización» (nextUpdate). El protocolo OCSP (RFC 6960) hace lo contrario: el cliente pregunta por UN certificado y un respondedor contesta «bueno», «revocado» o «desconocido», con una respuesta firmada y con su propia vigencia.

La lista es sencilla y funciona sin conexión mientras esté al día, pero crece y puede ir por detrás de la realidad. La consulta es más fresca, a costa de depender de que el respondedor esté vivo. Con el grapado OCSP (status_request, RFC 6066), el propio servidor TLS adjunta la respuesta reciente al saludo, y el cliente no tiene que consultar a nadie.

Cada CRL declara dos fechas: cuándo se generó y cuándo debe haber otra. Pasada la segunda, la lista caducó: ya no se puede confiar en que sea completa, porque nadie sabe qué se revocó desde entonces. Una lista vencida es un fallo operativo silencioso: no hay error visible, solo que las revocaciones nuevas no llegan a quien las necesita.

Abre crl-estado.txt, mira las dos fechas de cada lista y compara con el corte del 1 de octubre de 2026.

La revocación solo protege si quien valida la comprueba, y qué hace cuando no puede es una decisión de configuración. Un sistema que rechaza cuando no logra comprobar falla cerrado: se corta el servicio pero no se acepta nada dudoso. Uno que acepta falla abierto: el servicio sigue, y también siguen pasando los certificados que ya deberían estar fuera. Muchos clientes toleran el fallo abierto por disponibilidad, pero un sistema interno de acceso remoto tiene otro equilibrio entre servicio y riesgo.

Cruza dos documentos: qué lista usa cada sistema en clientes-de-validacion.txt y qué hace cuando no puede comprobar.

La autoridad registra cada revocación en su base de datos, pero el registro no es lo que consultan los clientes: lo que consultan es la lista publicada. Entre el momento de revocar y el de publicar hay un intervalo, y si la publicación se detiene, el certificado revocado sigue aceptándose en los sistemas que dependen de ella.

Lee revocaciones.txt: la última columna dice si cada revocación ya está en una lista publicada. El caso grave es el de una persona que ya no trabaja en la empresa y cuyo certificado de cliente sigue siendo aceptado.

El hallazgo es doble: la lista no se regeneró y el sistema acepta cuando no puede comprobar. Arreglar solo la lista sin vigilar su fecha lo deja igual de frágil: volverá a ocurrir. Cambiar la pasarela a fallo cerrado sin tener la lista al día cortaría el acceso remoto de toda la empresa. El orden sensato es regenerar y publicar ahora, vigilar nextUpdate como se vigila una caducidad, y después decidir con el dueño del servicio si el fallo abierto sigue siendo aceptable o se pasa a fallo cerrado con una excepción documentada.