CRL frente a OCSP es la cuestión de cómo se entera una relying party (la parte que confía en el certificado) de que un certificado se revocó antes de caducar. Una lista de revocación de certificados (RFC 5280 §5) es una lista firmada de números de serie revocados que los clientes descargan; el protocolo de estado de certificados en línea (Online Certificate Status Protocol, RFC 6960) responde a una consulta sobre un único certificado. En la PKI de la web pública, la respuesta cambió de forma decisiva a partir de 2024: las CRL pasaron a ser obligatorias, OCSP pasó a ser opcional y la mayor CA desactivó OCSP.
De un vistazo
| CRL | OCSP | |
|---|---|---|
| Especificación | RFC 5280 §5 | RFC 6960 (nonce: RFC 8954) |
| Qué recibe el cliente | Lista firmada de todos los números de serie revocados de un ámbito | Estado firmado (correcto, revocado o desconocido) de un único número de serie |
| Tamaño (medido el 20 de octubre de 2026) | Fragmento de CRL de Let's Encrypt de 62.116 bytes con 1591 entradas | Respuesta OCSP de DigiCert de 471 bytes |
| Vigencia | De thisUpdate a nextUpdate (ese fragmento: 9 días) | Validez de la respuesta (esa respuesta: 7 días) |
| Privacidad | El servidor solo sabe que se descargó una CRL | El respondedor sabe qué sitio visita el cliente |
| Dependencia de la disponibilidad | Se puede guardar en caché, replicar y precargar | Dependencia en vivo del respondedor, salvo que se grape |
| Norma de la PKI web (Baseline Requirements) | Obligatoria desde el 15 de marzo de 2024; nueva CRL al menos cada 4 días (cada 7 si todos los certificados tienen una URL de OCSP) y en las 24 horas siguientes a una revocación | Opcional desde el 15 de marzo de 2024 |
| Uso en los navegadores | Agregadas: CRLite en Firefox, CRLSets en Chrome | Firefox dejó de consultarlo para los certificados DV (versión 142); Chrome no lo consulta para la mayoría de los certificados |
| Entrega desde el servidor | No corresponde | Grapado OCSP (status_request, RFC 6066) |
Cómo funciona cada uno
Una CRL indica su emisor, incluye thisUpdate y nextUpdate, un número de CRL monótonamente creciente y una entrada por cada certificado revocado (número de serie, fecha de revocación y, opcionalmente, motivo), y está firmada por la CA. Los certificados señalan su CRL en la extensión CRL Distribution Points (puntos de distribución de CRL); las CA grandes dividen sus CRL en fragmentos para que cada archivo tenga un tamaño manejable, y las CA públicas declaran el conjunto completo de URL de sus CRL en la CCADB para que los agregadores puedan recopilar todas las revocaciones. Los clientes que comprueban las CRL las descargan y las guardan en caché, y las CRL delta (RFC 5280 §5.2.4) pueden reducir el tráfico cuando las listas son grandes.
Un cliente OCSP envía el hash del nombre del emisor, el hash de la clave del emisor y el número de serie a la URL que figura en la extensión Authority Information Access del certificado; el respondedor devuelve un estado firmado con su propio periodo de validez. Las respuestas pueden guardarse en caché hasta nextUpdate, y los servidores pueden grapar una respuesta reciente en el handshake TLS para que los clientes no tengan que contactar con la CA.
Las mediciones anteriores se tomaron en vivo: un certificado de Let's Encrypt emitido en septiembre de 2026 solo apunta a http://ye2.c.lencr.org/96.crl (sin URL de OCSP), y ese fragmento ocupaba 62 KB; un certificado de DigiCert todavía incluye http://ocsp.digicert.com, cuya respuesta ocupaba 471 bytes.
Por qué OCSP perdió terreno en la web
Tres características acabaron con OCSP en vivo en los navegadores. Privacidad: cada consulta le dice a la CA qué sitio visita un usuario y desde qué dirección IP. Disponibilidad: un respondedor lento o inaccesible o bien bloquea la carga de las páginas o bien, como los navegadores optaron por el soft-fail (seguir adelante si la consulta falla), se ignora en silencio, lo que significa que un atacante capaz de bloquear el respondedor anula la comprobación. Coste: los respondedores tienen que atender cada carga de página de internet. El grapado resolvió la privacidad y el coste, pero dependía de que cada servidor renovara las respuestas de forma fiable, y Must-Staple (RFC 7633), que habría permitido exigir el grapado, solo lo admitía Firefox.
El CA/Browser Forum respondió con la votación SC-063 (vigente desde el 15 de marzo de 2024): CRL obligatorias, OCSP opcional. Let's Encrypt eliminó las URL de OCSP de los certificados nuevos y dejó de aceptar pedidos con Must-Staple el 7 de mayo de 2025, y apagó sus respondedores el 6 de agosto de 2025. Firefox activó CRLite para todos los usuarios de escritorio en la versión 137: una codificación local compacta de todas las revocaciones de los certificados registrados en CT, que se actualiza cada 12 horas con una descarga media de unos 300 kB al día. Después, Firefox 142 dejó de hacer consultas OCSP para los certificados validados por dominio. Chrome se apoya en CRLSets, un conjunto seleccionado que se centra en las revocaciones de mayor impacto, en lugar de hacer consultas por sitio.
La tercera opción: certificados de corta duración
Un certificado válido durante unos días no necesita comprobación de revocación: para cuando una revocación llegara a propagarse, ya habría caducado. Los Baseline Requirements permiten a las CA omitir la información de revocación en los certificados de corta duración (como máximo 7 días para los emitidos desde el 15 de marzo de 2026), y Let's Encrypt ofrece desde enero de 2026 certificados de 160 horas a través de su perfil ACME shortlived. Junto con la reducción general de la vida útil a 47 días para 2029 (votación SC-081v3), la revocación se está convirtiendo en una red de seguridad más que en el control principal. La calculadora de vida útil de certificados muestra los límites según la fecha de emisión.
Cuándo elegir cada uno
- Servidores TLS públicos: no hace falta nada especial; asegúrate de que tus certificados proceden de una CA que publica CRL y no actives Must-Staple. Elimina la configuración de grapado que falla cuando no existe una URL de OCSP.
- Software cliente que verifica certificados públicos: usa el verificador de la plataforma, que aplica los conjuntos de revocaciones de los fabricantes de navegadores cuando están disponibles.
- PKI privada con muchos clientes, algunos sin conexión: CRL con un
nextUpdatecorto, servidas por HTTP con alta disponibilidad. - PKI privada con certificados de alto valor y clientes en línea: OCSP, con grapado donde el protocolo lo admita, y políticas de fallo estricto (hard-fail) si el respondedor está bajo tu control.
- Identidades de cargas de trabajo y de servicios: certificados de corta duración (de horas a días) emitidos automáticamente, sin ninguna infraestructura de revocación.
- Firma de código y firma de documentos: la revocación sigue importando para las firmas de larga duración; combina las CRL u OCSP con sellos de tiempo para que los verificadores puedan comprobar el estado en el momento de la firma.
Notas de migración
- Haz inventario de las dependencias de OCSP: configuración de grapado en los servidores, clientes que fallan de forma estricta (hard-fail) sin OCSP, monitorización que comprueba los respondedores.
- Haz que el grapado sea opcional: nginx y Apache no deben negarse a arrancar cuando un certificado no tiene URL de OCSP.
- En las CA privadas, publica primero las CRL: añade puntos de distribución de CRL a los certificados nuevos, divide en fragmentos las listas grandes, ajusta
nextUpdatea tu SLA de revocación y sírvelas por HTTP (no por HTTPS, para evitar dependencias circulares). - Acorta la vida útil donde la automatización lo permita; cada reducción disminuye la carga que recae sobre la revocación.
- Prueba la revocación de principio a fin: revoca un certificado de prueba y confirma que los clientes lo rechazan en el plazo esperado. El decodificador de CRL y el decodificador de OCSP muestran lo que verán los clientes.