Protocolo de estado de certificados en línea (OCSP) frente a listas de revocación de certificados (CRL)

Introducción

Cada certificado TLS de confianza pública conlleva una promesa: si se ve comprometido, se pierde o se emite por error, puede revocarse antes de su fecha de vencimiento prevista. El Protocolo de estado de certificados en línea (OCSP) y las Listas de revocación de certificados (CRL) son los dos mecanismos que hacen posible esta promesa, y la elección entre ellos ha cambiado significativamente en los últimos dos años. Esta guía explica cómo funciona cada método, por qué la recomendación del sector ha cambiado desde que se redactó esta comparación por primera vez y cómo decidir qué enfoque se adapta mejor a un entorno determinado.

En resumen: OCSP vs. CRL

Tanto OCSP como las CRL se utilizan para comprobar si un certificado ha sido revocado antes de su vencimiento. OCSP consulta en tiempo real al respondedor de una Autoridad de Certificación (CA) para conocer el estado de un certificado específico, devolviendo si está vigente, revocado o si se desconoce. Una CRL es una lista firmada y descargable de todos los certificados que una CA ha revocado, que un cliente consulta localmente sin necesidad de contactar directamente con la CA para cada consulta.

Instantánea: ¿Qué ha cambiado desde que se escribió esta comparación por primera vez?

• OCSP comprueba el estado de un único certificado en tiempo real; una CRL es una lista completa que un cliente descarga y comprueba localmente.
• Let's Encrypt, la autoridad de certificación responsable de aproximadamente la mitad de los certificados TLS de la web, cerró por completo sus respondedores OCSP el 6 de agosto de 2025, pasando a utilizar exclusivamente listas de revocación de certificados (CRL).
• El principal factor determinante no era el rendimiento, sino la privacidad: cada solicitud OCSP le indica a la CA qué dirección IP está visitando el sitio web de qué certificado, en tiempo real.
• La menor duración de los certificados según el nuevo calendario de validez del CA/Browser Forum reduce, pero no elimina, el período en el que la comprobación de revocación resulta relevante.
• La elección correcta sigue dependiendo de quién controle ambos extremos de la conexión: una CA pública que presta servicios a navegadores arbitrarios tiene restricciones diferentes a las de una implementación interna de Servicios de certificados de Active Directory (AD CS) que presta servicios a clientes conocidos.

Por qué esta comparación se interpreta de manera diferente en 2026

La señal más clara de que este tema ha cambiado provino de la propia Let's Encrypt. En un anuncio de diciembre de 2024, la CA sin fines de lucro presentó una eliminación gradual de OCSP: las nuevas solicitudes OCSP Must-Staple dejaron de ser aceptadas el 30 de enero de 2025, las URL de OCSP se eliminaron de los certificados recién emitidos antes del 7 de mayo de 2025, y sus respondedores OCSP se cerraron por completo el 6 de agosto de 2025. El razonamiento expuesto por Let's Encrypt fue directo sobre el costo de privacidad de OCSP: una CA que responde a las consultas OCSP sabe, en tiempo real, qué direcciones IP visitan los sitios de sus titulares de certificados, información que podría verse obligada a conservar o divulgar. Las CRL, por el contrario, se descargan en bloque y se verifican localmente, por lo que la CA nunca ve una consulta por visita.

La encuesta Trust Pulse de DigiCert, publicada el 2 de julio de 2025, reveló que casi la mitad de las empresas sufrieron una interrupción relacionada con certificados durante el último año. El 37.5 % de esos incidentes estuvieron vinculados específicamente a certificados caducados, y el 18.5 % de las organizaciones afectadas reportaron pérdidas superiores a 250 000 dólares. Una comprobación de revocación lenta o poco fiable, ya sea por un respondedor OCSP sobrecargado o una caché CRL obsoleta, agrava este tipo de riesgo de interrupción, en lugar de afectar únicamente a la seguridad.

La duración de los certificados se está reduciendo al mismo tiempo que cambian las prácticas de revocación. Según la propuesta SC-081v3 del Foro CA/Navegador , aprobada el 11 de abril de 2025, la validez de los certificados TLS de confianza pública se reduce de 398 a 200 días a partir del 15 de marzo de 2026, luego a 100 días desde el 15 de marzo de 2027 y a 47 días desde el 15 de marzo de 2029 en adelante. Un certificado válido por 47 días simplemente tiene un período más corto en el que la revocación tiene alguna relevancia, lo que explica en parte por qué algunas autoridades de certificación ahora consideran que las listas de revocación de certificados (CRL) son suficientes por sí solas, en lugar de añadirles OCSP.

A largo plazo, el NIST finalizó sus estándares de criptografía postcuántica, FIPS 203, 204 y 205, el 13 de agosto de 2024. Actualmente, ni las respuestas OCSP ni las CRL se firman habitualmente con algoritmos postcuánticos, pero a medida que las CA planifican una infraestructura de firma criptográfica ágil, los datos de revocación son un elemento más que eventualmente necesitará una ruta de migración junto con los certificados que describe.

¿Qué es OCSP?

El Protocolo de estado de certificados en línea (OCSP) es un protocolo de Internet que permite a un cliente preguntar al respondedor de una Autoridad de Certificación si un certificado específico sigue siendo válido, sin necesidad de descargar una lista completa de todos los certificados que dicha Autoridad de Certificación ha revocado.

Cómo funciona una solicitud y una respuesta de OCSP

Un cliente OCSP envía una solicitud de estado a un respondedor OCSP y espera una respuesta firmada antes de continuar. La solicitud incluye la versión del protocolo, el tipo de servicio solicitado, un identificador para el certificado de destino y cualquier extensión opcional. El respondedor verifica que el mensaje esté bien formado, que esté configurado para responder en nombre de la CA en cuestión y que la solicitud incluya la información necesaria; luego, devuelve una respuesta definitiva o un error.

Una respuesta OCSP básica incluye la versión de la sintaxis de respuesta, un identificador para el respondedor, la hora en que se generó la respuesta, un estado para cada certificado solicitado, extensiones opcionales, el identificador de objeto (OID) del algoritmo de firma y una firma calculada sobre un hash de la respuesta para que el cliente pueda verificar que proviene de la CA sin alteraciones. Son posibles tres valores de estado: bueno, lo que significa que el certificado no ha sido revocado hasta donde sabe el respondedor; revocado, lo que significa que el certificado fue revocado explícitamente o la CA no tiene registro de haberlo emitido; y desconocido, lo que significa que el respondedor no reconoce al emisor de ese certificado.

Grapado OCSP

OCSP Stapling aborda directamente la mayor debilidad de OCSP: en lugar de que el cliente contacte a la CA, el propio servidor web obtiene periódicamente una respuesta OCSP firmada y con marca de tiempo, y la adjunta al protocolo de enlace TLS. De esta forma, los navegadores visitantes obtienen el estado de revocación sin necesidad de contactar a la CA. Esto elimina el viaje de ida y vuelta adicional y la exposición a la privacidad que supone una consulta a la CA por visitante, ya que la CA solo ve las solicitudes de actualización periódicas del servidor web, en lugar de las de cada visitante individual. Sin embargo, Stapling no está implementado universalmente y no elimina los demás costes operativos de OCSP; una CA aún debe mantener una infraestructura de respuesta capaz de gestionar el tráfico de actualización a gran escala.

¿Qué es una lista de revocación de certificados (CRL)?

Una Lista de Revocación de Certificados (CRL, por sus siglas en inglés) es una lista firmada, publicada por la CA emisora, de todos los certificados que han sido revocados antes de su fecha de vencimiento programada y que ya no deben considerarse confiables. Los clientes obtienen la CRL de un Punto de Distribución de CRL, una extensión de certificado X.509v3 que apunta a una ubicación HTTP o LDAP, y verifican localmente si el certificado que están validando aparece en ella.

Revocado vs. Estados de retención

Una entrada en la CRL puede reflejar uno de dos estados. Un certificado revocado se elimina de forma irreversible, generalmente debido a una vulneración de clave, una vulneración de la CA, un cambio de afiliación u otro motivo definido en los códigos de motivo de revocación X.509; no se puede restablecer. Un certificado suspendido se suspende temporalmente en lugar de revocarse permanentemente. Por ejemplo, si una clave privada que se creía perdida aparece a salvo, el certificado puede dejar de estar suspendido y volver a ser válido, lo que supone una diferencia operativa significativa con respecto a una revocación irreversible.

Cómo funciona la distribución de CRL en la práctica

Una CRL funciona de forma muy similar a una lista negra. Un cliente recupera la CRL actual del punto de distribución publicado por la CA y comprueba que el certificado en cuestión no aparezca en ella. Dado que es necesario descargar y analizar la lista completa, una CRL extensa puede consumir muchos más recursos del cliente y de la red que una sola consulta OCSP, y publicar una nueva CRL tras una revocación suele ser más lento que la capacidad de respuesta en tiempo real de un respondedor OCSP. La mayoría de las pilas TLS también están configuradas para funcionar en caso de fallo: si un cliente no puede descargar la CRL, por defecto confía en el certificado en lugar de bloquear la conexión, lo cual es una compensación conocida y no un defecto.

OCSP vs. CRL: Cara a cara

Factor	OCSP	CRL
Lo que comprueba	Estado de un certificado específico por solicitud	Lista completa de todos los certificados que la CA ha revocado.
Dónde se realiza el control	El cliente consulta directamente al respondedor OCSP de la CA, a menos que esté vinculado.	El cliente descarga la lista una vez y la verifica localmente.
Exposición de la privacidad	La CA ve la dirección IP de cada cliente y qué certificado está comprobando, a menos que esté adjunta.	CA no ve las consultas individuales por visita.
Carga de red y de clientes	Bajo por solicitud, pero los respondedores deben manejar un alto volumen de consultas.	La descarga puede resultar pesada para listas extensas de certificados revocados.
Comportamiento de falla	Una interrupción del servicio de respuesta puede bloquear o omitir silenciosamente la validación dependiendo de la configuración del cliente.	La ausencia de la CRL normalmente provoca un fallo en la apertura, optando por confiar en el certificado por defecto.
Orientación del sector en 2026	Las principales autoridades de certificación, incluida Let's Encrypt, lo eliminarán gradualmente a partir del 6 de agosto de 2025.	Cada vez se posiciona más como el mecanismo de revocación principal o único, a veces combinado con certificados de corta duración.

Matriz de decisión: Elección de una estrategia de verificación de revocación

Caso de uso	Impacto en la seguridad	Esfuerzo Operacional	Ajuste de automatización	Propietario recomendado
Certificados TLS públicos emitidos por una CA pública	Los periodos de validez medios y más cortos reducen la ventana de exposición.	Es bajo, la mayoría de las autoridades de certificación públicas ahora gestionan esto de forma centralizada.	Alto, gestionado en gran medida por CA	Equipos de plataforma
AD CS interno o PKI privado que presta servicios a clientes conocidos	Alto, un certificado interno comprometido puede afectar la autenticación de forma generalizada.	Nivel medio, requiere ejecutar y escalar un rol de respondedor en línea.	Medio, requiere configuración pero es estable una vez ajustado.	Administradores de PKI
Flotas de dispositivos que no son navegadores ni dispositivos IoT	De nivel medio a alto, depende de cómo se autentiquen los dispositivos.	La distribución de CRL a gran escala requiere planificación.	La obtención programada de CRL de tamaño medio suele ser más sencilla que OCSP para dispositivos con recursos limitados.	Equipos de plataforma
Entornos de alta seguridad que requieren comprobaciones de revocación casi instantáneas.	Alto, el retraso en la propagación de la revocación es en sí mismo un riesgo	Alto, requiere OCSP Stapling más una ruta de reserva CRL	Medio, requiere que ambos mecanismos estén configurados correctamente.	Arquitectos de seguridad
Clientes heredados o con restricciones sin compatibilidad con OCSP Stapling	Media	La comprobación de CRL es ampliamente compatible sin configuración especial.	Alto, las CRL funcionan como un respaldo universal.	Cumplimiento, Equipos de plataforma

Cómo elegir entre OCSP y CRL

No existe una única respuesta universalmente correcta, pero la decisión generalmente depende de quién controla ambos extremos de la conexión, de la sensibilidad del momento de la revocación y de lo que la población de clientes pueda soportar realmente.

Una guía de decisiones rápidas

1. Si tanto el cliente como la CA admiten OCSP Stapling, utilice Stapling como mecanismo principal, con una CRL como alternativa documentada para los clientes que no lo admitan.
2. Si minimizar la información que la CA puede observar sobre el comportamiento de los visitantes es una prioridad, se recomienda usar CRL o combinar certificados de corta duración con CRL para que el período de exposición se mantenga reducido incluso sin comprobaciones en tiempo real.
3. Si la población de clientes incluye software que no es un navegador, dispositivos IoT o dispositivos de red que no pueden implementar la vinculación de datos, las CRL suelen ser la opción más sencilla y con mayor soporte universal.
4. Si el entorno es una implementación interna de AD CS o una PKI privada donde la organización controla tanto la CA como a cada cliente, OCSP con una función de Respondedor en línea adecuadamente escalada sigue siendo una opción práctica, ya que la preocupación por la privacidad que motivó la decisión de Let's Encrypt se aplica principalmente a las CA públicas que prestan servicios a clientes desconocidos.

Pros y contras de un vistazo

• Ventajas de OCSP: comprueba únicamente el certificado en cuestión en lugar de una lista completa y devuelve una respuesta en tiempo real cuando el respondedor está en buen estado.
• Desventajas de OCSP: expone las direcciones IP de los visitantes y las visitas al sitio a la CA a menos que se incluyan de forma predeterminada, y las interrupciones del servicio de respuesta se han gestionado históricamente de forma inconsistente entre los clientes.
• Ventajas de las CRL: no requieren consultas a la CA por visita, funcionan como un mecanismo de reserva fiable en todas partes y ahora son el mecanismo principal o único en las CA del tamaño de Let's Encrypt.
• Desventajas de la CRL: las descargas de listas completas pueden ser muy grandes para una CA con muchas revocaciones, y los retrasos en la publicación significan que una revocación muy reciente puede no aparecer de inmediato.

¿A quién debería importarle esto?

El abandono del OCSP en las principales autoridades de certificación públicas modifica decisiones operativas concretas para diversas funciones.

Administradores de PKI

Configure y mantenga los puntos de distribución de CRL o del Respondedor en línea de los que depende su CA. Acción: confirme cuáles de sus certificados aún hacen referencia a URL OCSP de una CA que ha dejado de ofrecer dicho servicio y verifique que los puntos de distribución de CRL sean accesibles y estén actualizados.

Arquitectos de seguridad

Defina el protocolo de verificación de revocación para sistemas de alta seguridad. Acción: documente una ruta de respaldo para cualquier sistema que aún asuma la disponibilidad de OCSP, dado que los respondedores de algunas CA públicas ya no existen.

Equipos de plataforma

Controla la configuración del cliente en todos los servidores, balanceadores de carga y flotas de dispositivos. Acción: verifica que los puntos de terminación TLS que esperan respuestas OCSP Stapling tengan configurada una reserva de CRL en lugar de fallar silenciosamente.

Equipos de cumplimiento

Confirme que la evidencia de verificación de revocación aún coincide con la forma en que se validan los certificados en producción. Acción: actualice la documentación de auditoría que aún menciona OCSP como mecanismo predeterminado si la CA correspondiente ha migrado a CRL.

CISO

Analice las ventajas y desventajas en cuanto a privacidad y confiabilidad de la verificación de revocación como parte de la estrategia general del ciclo de vida de los certificados. Acción recomendada: pregunte si la reducción en la duración de los certificados según el calendario del CA/Browser Forum modifica la inversión que la organización debe realizar en infraestructura de revocación en tiempo real en comparación con la verificación basada en CRL.

Nuestra opinión: Cómo la consultoría en cifrado respalda la revocación de certificados y la gestión del ciclo de vida.

Tanto si un entorno se basa en OCSP, CRL o una combinación de ambos, el requisito fundamental es el mismo: saber qué certificados existen, cómo se validan y si esa ruta de validación sigue coincidiendo con la forma en que opera actualmente la CA emisora.

Nuestra plataforma CertSecure Manager ofrece a los equipos un inventario completo de identidades de máquinas y detección de certificados en todo el entorno, de modo que un cambio en el nivel de CA, como la finalización de OCSP de Let's Encrypt, no se presente como una interrupción inesperada. Para los equipos que evalúan si mantener la gestión de la infraestructura de revocación internamente, nuestra plataforma PKI-as-a-Service ejecuta la jerarquía de CA, incluida la publicación de revocaciones, en claves respaldadas por HSM FIPS 140-3 Nivel 3, mientras que su organización conserva la propiedad y el control. Para obtener una visión más detallada de los mecanismos de revocación relacionados, consulte nuestras guías sobre el Número Mágico de OCSP , un umbral específico de Windows que cambia silenciosamente de la comprobación de OCSP a la de CRL, y los códigos de motivo de CRL , que explican el significado práctico de cada código de revocación. En lo que respecta a la criptoagilidad, nuestro Centro de Excelencia PQC y la Evaluación de Preparación PQC ayudan a los equipos a planificar un futuro en el que los propios datos de revocación necesiten una firma segura post-cuántica, y nuestra plataforma de descubrimiento e inventario criptográfico CBOM Secure ofrece a los arquitectos de seguridad visibilidad sobre qué certificados en un entorno aún dependen de un respondedor OCSP obsoleto.

Conclusión

OCSP y las CRL resuelven el mismo problema: confirmar que un certificado no ha sido revocado, aunque con diferentes compensaciones entre precisión en tiempo real, privacidad y simplicidad operativa. Lo que realmente ha cambiado desde que esta comparación resultó útil por primera vez es que la respuesta predeterminada del sector se ha invertido: el cierre total de OCSP por parte de Let's Encrypt el 6 de agosto de 2025 demuestra que las CRL, antes consideradas la opción más antigua y compleja, son ahora el mecanismo principal a nivel de CA que emite más certificados que cualquier otro. Los equipos que aún asumen que OCSP está disponible universalmente, o que no han comprobado si su CA ha seguido el ejemplo de Let's Encrypt, deberían considerar esto como una revisión de configuración pendiente en lugar de una suposición establecida.

Preguntas frecuentes

¿Cuál es la principal conclusión sobre el Protocolo de estado de certificados en línea (OCSP) frente a las listas de revocación de certificados (CRL)?

OCSP comprueba el estado de un único certificado en tiempo real, pero expone la actividad del visitante a la CA a menos que esté vinculada a un certificado físico, mientras que las CRL son una lista descargable que se comprueba localmente. Las principales CA, incluida Let's Encrypt desde el 6 de agosto de 2025, han pasado de OCSP a las CRL como mecanismo principal.

¿Por qué es importante esto para los equipos de PKI empresariales?

Es posible que las configuraciones y la documentación de auditoría redactadas cuando OCSP era la configuración predeterminada ya no coincidan con la forma en que una CA determinada valida los certificados en la actualidad, lo que puede crear lagunas silenciosas en la comprobación de revocación.

¿Qué riesgos aumentan si la verificación de la revocación se realiza manualmente o no se revisa?

Los sistemas pueden acabar confiando silenciosamente en certificados que deberían haber sido rechazados, ya sea porque un respondedor OCSP del que dependen ha sido desactivado o porque una caché CRL obsoleta nunca se actualiza, y nadie se da cuenta hasta que ocurre un incidente.

¿Qué equipos deberían asumir la responsabilidad de esta decisión?

Los administradores de PKI son responsables de la configuración del punto de respuesta y distribución, los arquitectos de seguridad establecen la postura de verificación de revocación para sistemas sensibles, los equipos de plataforma son responsables de la configuración del lado del cliente, el departamento de cumplimiento verifica que la documentación coincida con la realidad y el CISO evalúa el equilibrio general entre privacidad y confiabilidad.

¿Cómo se relaciona esto con la gestión del ciclo de vida de los certificados?

La verificación de revocación es una etapa del ciclo de vida de un certificado, junto con su emisión, renovación y vencimiento. Las herramientas de gestión del ciclo de vida de los certificados, que ofrecen un descubrimiento e inventario completos, permiten saber qué certificados dependen de qué mecanismo de revocación antes de que una CA modifique su infraestructura.

¿Cómo deberían las organizaciones medir si su estrategia de verificación de revocaciones está funcionando?

Realizar un seguimiento para comprobar si algún certificado sigue haciendo referencia a URL OCSP de una CA que ha dejado de ofrecer el servicio, confirmar que los puntos de distribución de CRL se resuelven y están actualizados, y supervisar las interrupciones relacionadas con comprobaciones de revocación fallidas o lentas, en lugar de limitarse a realizar un seguimiento de la caducidad de los certificados.

¿Qué se debe auditar o supervisar periódicamente?

Confirme periódicamente qué mecanismo de revocación admite realmente cada CA emisora, verifique que OCSP Stapling funcione donde esté configurado, compruebe que los intervalos de obtención de CRL sean apropiados para la población de certificados y revise las suposiciones cada vez que una CA publique un cambio en la infraestructura.

¿Cómo afecta este tema a los entornos PKI en la nube, híbridos o con múltiples autoridades de certificación?

Un entorno que combine una CA pública como Let's Encrypt con una jerarquía interna de AD CS o una CA nativa de la nube puede requerir estrategias de revocación diferentes para cada una, ya que el cambio de una CA pública a las CRL no requiere ni implica el mismo cambio para una PKI interna que presta servicios a una población de clientes conocida.

¿Qué errores comunes deben evitar los equipos?

Entre los errores comunes se incluyen asumir que OCSP está disponible universalmente sin comprobar si la CA emisora ​​sigue ejecutando un respondedor, tratar el comportamiento de apertura por fallo de una CRL faltante como un error en lugar de una compensación de diseño conocida, y no revisar nunca la configuración de revocación después de la implementación inicial.

¿Qué información debe actualizarse trimestralmente para una estrategia de verificación de revocaciones?

Revise si alguna CA emisora ​​ha anunciado cambios en su infraestructura OCSP o CRL, confirme que los inventarios de certificados estén actualizados, revise el calendario de validez publicado por el Foro CA/Navegador para detectar cambios y compruebe si la reducción de la duración de los certificados ha disminuido la necesidad práctica de realizar comprobaciones de revocación en tiempo real en un entorno determinado.