¿Qué es el OCSP (Protocolo de estado de certificados en línea)?

Antes de la llegada del OCSP, el método principal para comprobar el estado de revocación consistía en descargar unalista de revocación de certificados (CRL), un archivo publicado periódicamente que contenía el número de serie de todos los certificados revocados. Las CRL funcionan, pero requieren que el cliente descargue la lista completa, la analice y compruebe si hay alguna coincidencia. A medida que aumentaban las implementaciones de PKI, también lo hacía el tamaño de estas listas, lo que generaba problemas de ancho de banda y latencia que hacían que la validación en tiempo real resultara poco práctica en muchos entornos.

El protocolo OCSP resuelve este problema invirtiendo el modelo. En lugar de descargar una lista completa, el cliente envía una solicitud sencilla para conocer el estado de un único certificado. El servidor OCSP devuelve una respuesta firmada digitalmente en la que se confirma si dicho certificado es válido, ha sido revocado o es desconocido. El resultado es una comprobación de revocación más rápida y eficiente, capaz de adaptarse a los entornos modernos.

Para ver una comparación detallada de ambos enfoques, incluyendo cuándo utilizar cada uno, lee«CRL frente a OCSP: lo que necesitas saber».

Cómo funciona el OCSP

Una transacción OCSP sigue un patrón sencillo de solicitud y respuesta. Cuando un cliente (como un navegador, una pasarela VPN o una aplicación) se encuentra con un certificado que necesita validar, localiza la URL del servidor OCSP incluida en la extensión «Authority Information Access» (AIA) del certificado. A continuación, el cliente elabora una solicitud, la envía a esa URL a través de HTTP y recibe una respuesta firmada.

A continuación se describe el proceso paso a paso:

1. El cliente recibe un certificadodurante un TLS u otra operación de la infraestructura de clave pública (PKI).
2. El cliente extrae la URL del servidor de respuesta OCSPde la extensión AIA del certificado.
3. El cliente genera una solicitud OCSPque contiene la información identificativa del certificado.
4. El servidor de respuesta OCSP comprueba el estado del certificadocotejándolo con su fuente de datos de revocación.
5. El servidor de respuesta devuelve una respuesta firmada digitalmentecon el estado actual del certificado.

Por lo general, todo el proceso se completa en milisegundos, lo que proporciona al cliente datos de revocación casi en tiempo real sin la carga que supone descargar una CRL completa.

La solicitud y la respuesta OCSP

Una solicitud OCSP identifica el certificado en cuestión mediante una estructura CertID definida en el RFC 6960. Esta estructura contiene cuatro campos:

• Algoritmo de hash:el algoritmo utilizado para calcular los hash que figuran a continuación (normalmente SHA-1 o SHA-256).
• Hash del nombre del emisor:un hash del nombre distinguido de la CA emisora.
• Hashde la clave del emisor:un hash de la clave pública de la CA emisora.
• Número de serie:El número de serie único del certificado que se está comprobando.

En conjunto, estos campos identifican de forma única un certificado concreto sin que sea necesario que el cliente envíe el certificado completo al destinatario.

El servidor OCSP evalúa la solicitud y devuelve una respuesta firmada que contiene uno de estos tres valores de estado:

• Bien:El certificado es válido y no ha sido revocado.
• Revocado:El certificado ha sido revocado, y la respuesta incluye la hora de la revocación y (opcionalmente) el motivo.
• Desconocido:El servidor no dispone de información sobre el certificado solicitado.

Cada respuesta incluye además marcas de tiempo: «producedAt» (momento en que se generó la respuesta), «thisUpdate» (momento en que se confirmó por última vez el estado) y «nextUpdate» (momento en que el cliente debe volver a comprobarlo). Estas marcas de tiempo permiten a los clientes almacenar las respuestas en caché y determinar su vigencia.

Si el servidor no puede procesar la solicitud, devuelve un código de estado de error. Entre los códigos más habituales se encuentran MALFORMED_REQUEST (no se ha podido analizar la solicitud), INTERNAL_ERROR (el servidor ha detectado un problema), TRY_LATER (el servidor no está disponible temporalmente) y UNAUTHORIZED (el cliente no tiene permiso para realizar consultas a este servidor).

¿Qué es un servidor de respuesta OCSP?

Un servidor de respuesta OCSP es un servidor que recibe solicitudes de estado de certificados y devuelve una respuesta firmada digitalmente en la que se indica si un certificado concreto es válido, ha sido revocado o su estado es desconocido.El servidor de respuesta es gestionado por la autoridad de certificación (CA) que emitió el certificado, o en nombre de esta.

Existen dos modelos principales de servicios de primera intervención:

• Respuesta integrada en la CA:La propia CA firma las respuestas OCSP utilizando su propia clave privada. Se trata del modelo más sencillo, pero implica que la clave de firma de la CA debe estar en línea y ser accesible, lo que plantea algunas consideraciones de seguridad.
• Respondedor delegado:La CA emite un certificado de firma OCSP independiente a un respondedor dedicado. Este certificado debe incluir el uso de clave «Firma digital» y el uso de clave ampliado «OCSPSigner». Los respondedores delegados permiten que la clave raíz o intermedia de la CA permanezca fuera de línea sin dejar de proporcionar información de estado en tiempo real.

En entornos PKI empresariales, un único servidor OCSP puede responder a las consultas de varias autoridades de certificación (CA). Las organizaciones que necesitan una alta disponibilidad suelen implementar varios nodos de respuesta, cada uno con su propia copia de los datos de revocación, detrás de un equilibrador de carga. Esta arquitectura garantiza que la validación de certificados continúe incluso si algún nodo concreto sufre un tiempo de inactividad.

Explicación del «stapling» de OCSP

El protocolo OCSP estándar exige que el navegador se ponga en contacto con el servidor de respuesta OCSP de la autoridad de certificación (CA) durante cada TLS . A gran escala, esto introduce latencia, crea una dependencia de infraestructuras de terceros y plantea cuestiones relacionadas con la privacidad. El «OCSP stapling», definido en el RFC 6066, resuelve estas tres cuestiones al trasladar la responsabilidad de recuperar la respuesta OCSP del navegador al servidor web.

Cómo funciona el «stapling» de OCSP

Con el «stapling» de OCSP, el servidor web obtiene periódicamente una respuesta OCSP del servidor de respuesta de la CA y la almacena en caché localmente. Cuando un navegador inicia un TLS , el servidor incluye (o «adjunta») esa respuesta OCSP almacenada en caché junto con el certificado en el mensaje de estado TLS . El navegador valida la firma digital de la respuesta adjunta y comprueba sus marcas de tiempo de vigencia, todo ello sin realizar una solicitud de red independiente a la CA.

El proceso funciona de la siguiente manera:

1. El servidor web envía una solicitud OCSP al servidor de respuesta de la CA, normalmente a intervalos regulares (por ejemplo, cada pocas horas).
2. El servidor de respuesta de la CA devuelve una respuesta OCSP firmada.
3. El servidor almacena la respuesta en caché.
4. Durante cada TLS , el servidor envía la respuesta almacenada en caché al cliente que se conecta como parte del protocolo de enlace.
5. El cliente verifica la firma y las marcas de tiempo de la respuesta y, a continuación, establece la conexión.

Dado que el servidor se encarga de la consulta OCSP, el navegador nunca tiene que ponerse en contacto directamente con la CA para obtener datos de revocación durante la conexión.

Ventajas de la grapado OCSP

El «stapling» de OCSP ofrece tres ventajas clave con respecto al OCSP tradicional:

• Rendimiento mejorado.
  El navegador recibe el estado de revocación del certificado como parte del TLS , lo que elimina la ida y vuelta al servidor OCSP de la CA. Esto reduce el tiempo de establecimiento de la conexión, especialmente para los usuarios que se encuentran geográficamente alejados de la infraestructura de la CA.
• Mayor seguridad.
  Al eliminar la necesidad de que el navegador realice una solicitud OCSP independiente, el «stapling» reduce la superficie de ataque. Además, minimiza el riesgo de falsos positivos que pueden producirse cuando no se puede acceder a los servidores de respuesta OCSP y los clientes recurren a un comportamiento de «fallo suave».
• Mayor privacidad para el usuario.
  Con el OCSP tradicional, la CA recibe una solicitud por cada certificado que el usuario valida, lo que revela sus hábitos de navegación. Con el «stapling», la CA solo recibe solicitudes del servidor web, no de los usuarios individuales.

¿Qué es «OCSP Must-Staple»?

OCSP Must-Staple es una extensión de certificado definida en el RFC 7633 que indica a los navegadores que exijan una respuesta OCSP válida y adjunta durante el TLS .Si el servidor no proporciona una respuesta adjunta, el navegador debe rechazar la conexión en lugar de continuar sin los datos de revocación.

Esta extensión subsana una importante carencia del modelo OCSP estándar. Sin la función «Must-Staple», la mayoría de los navegadores utilizan un enfoque de «fallo suave»: si no pueden conectarse con el servidor de respuesta OCSP (o si el servidor no «grapa» una respuesta), permiten la conexión de todos modos. Esto significa que un certificado comprometido podría ser aceptado si un atacante bloquea el tráfico OCSP entre el cliente y la CA.

Must-Staple aplica una política de «fallo irremediable» para los certificados que incluyen la extensión. La contrapartida es que los operadores de los servidores deben asegurarse de que su configuración de OCSP stapling sea fiable, ya que una respuesta de stapling ausente o caducada provocará que las conexiones legítimas fallen.

Ventajas del protocolo OCSP frente a las listas CRL

El protocolo OCSP ofrece varias ventajas operativas que lo hacen especialmente adecuado para entornos en los que es importante disponer de datos de revocación oportunos y garantizar la eficiencia de los recursos:

• Estado en tiempo real.
  El protocolo OCSP comprueba el estado de un certificado en el momento en que se realiza la solicitud, en lugar de basarse en una lista publicada periódicamente. Esto significa que la información sobre revocaciones está tan actualizada como lo permita la fuente de datos del servidor de respuesta.
• Cargas útiles de respuesta más pequeñas.
  Una respuesta OCSP se refiere a un único certificado, por lo que es considerablemente más pequeña que una CRL, que enumera todos los certificados revocados emitidos por una CA. Esto hace que el protocolo OCSP resulte especialmente adecuado para dispositivos con recursos limitados, como smartphones, IoT y sistemas embebidos, que cuentan con memoria y potencia de procesamiento limitadas.
• Ancho de banda reducido.
  Dado que los clientes solo solicitan el estado de los certificados con los que se encuentran, el protocolo OCSP elimina la necesidad de descargar y analizar archivos CRL de gran tamaño. Esto resulta especialmente útil en entornos con miles o millones de certificados activos.
• Más adecuado para casos de uso en los que el tiempo es un factor crítico.
  En escenarios como el control de acceso a la red (NAC), en los que las decisiones de acceso deben tomarse de forma inmediata, las consultas OCSP en tiempo real ofrecen una capacidad de respuesta que los intervalos de almacenamiento en caché de las CRL no pueden igualar.

Para ver una comparación detallada entre OCSP y las CRL, incluido un marco de decisión sobre cuándo utilizar cada una, consulta«CRL frente a OCSP: lo que necesitas saber».

Limitaciones y consideraciones relacionadas con el protocolo OCSP

A pesar de sus ventajas, el protocolo OCSP plantea una serie de retos operativos que las organizaciones deben comprender antes de recurrir a él como mecanismo principal de revocación.

Cuestiones relacionadas con la privacidad

En el modelo OCSP estándar, el cliente envía el número de serie del certificado al servidor de respuesta OCSP de la CA por cada certificado que valida. Esto significa que la CA (o quienquiera que gestione el servidor de respuesta) puede observar qué certificados están comprobando los usuarios, lo que puede revelar la actividad de navegación y otros patrones de uso. El «stapling» de OCSP se desarrolló específicamente para mitigar este problema, pero no todos los servidores tienen esta función activada.

Dependencia de disponibilidad

El protocolo OCSP introduce una dependencia en tiempo real de la disponibilidad del servidor de respuesta. Si el servidor de respuesta OCSP deja de funcionar, los clientes deben decidir qué hacer. La mayoría de los navegadores y aplicaciones utilizan un enfoque de «fallo suave», lo que significa que permiten que la conexión continúe aunque no puedan verificar el estado de revocación del certificado. Este comportamiento hace que, en la práctica, el protocolo OCSP sea opcional durante las interrupciones del servicio, lo que merma el valor de seguridad de la comprobación de revocación.

La alternativa, denominada «hard-fail», bloquea todas las conexiones cuando no se puede acceder al servidor de respuesta OCSP. Aunque esta opción es más segura, plantea riesgos de disponibilidad, ya que una interrupción del servidor de respuesta podría provocar la caída de todos los servicios que dependen de él para la validación.

Rendimiento a gran escala

Cada comprobación OCSP requiere un viaje de ida y vuelta por la red hasta el servidor de respuesta. En el caso de servicios con mucho tráfico o de clientes que validan muchos certificados en rápida sucesión, estas consultas pueden añadir una latencia apreciable. Aunque el «OCSP stapling» elimina el viaje de ida y vuelta entre el navegador y la CA, el servidor sigue teniendo que consultar al servidor de respuesta para actualizar sus respuestas almacenadas en caché.

Punto único de fallo

Si una organización gestiona un único servidor de respuesta OCSP (o un pequeño clúster sin redundancia geográfica), dicho servidor se convierte en una dependencia crítica para todos los certificados que gestiona. La infraestructura del servidor de respuesta debe estar diseñada para garantizar una alta disponibilidad, con nodos redundantes, equilibrio de carga y sistemas de supervisión que permitan detectar y responder a las interrupciones antes de que afecten a la validación de los certificados.

Cómo gestionan los navegadores el OCSP en la actualidad

La forma en que los navegadores gestionan el protocolo OCSP ha evolucionado considerablemente, y comprender el comportamiento actual de los navegadores es un contexto importante para cualquier organización que gestione una infraestructura PKI.

Google Chromeno realiza comprobaciones OCSP tradicionales para la mayoría de los certificados de confianza pública. En su lugar, Google mantiene los CRLSets, un conjunto seleccionado y comprimido de números de serie de certificados revocados que se distribuye a Chrome a través de las actualizaciones del navegador. Este enfoque evita la latencia y los problemas de privacidad que plantean las consultas OCSP en tiempo real, aunque la cobertura de los CRLSets se limita a las revocaciones de alta prioridad, en lugar de incluir todos los certificados revocados.

Mozilla Firefoxsolo admite OCSP como solución alternativa, ya que su estrategia principal ha pasado a centrarse en la validación local de certificados. El navegador ha adoptado CRLite, una tecnología que comprime el conjunto completo de datos de revocación derivados de las CRL en una estructura de datos compacta que puede distribuirse a los navegadores. CRLite permite a Firefox realizar comprobaciones de revocación locales sin necesidad de ponerse en contacto con un servidor OCSP.

Apple Safarirealiza comprobaciones OCSP como parte de su proceso de validación de certificados. Históricamente, Apple ha dependido más de OCSP que Chrome o Firefox, aunque también utiliza el almacenamiento en caché local y las comprobaciones por lotes para reducir el impacto en el rendimiento y la privacidad de las consultas en tiempo real.

La tendencia general del sector es clara: en la web pública, los navegadores están pasando de las consultas OCSP en tiempo real a los datos de revocación distribuidos localmente. Sin embargo, el OCSP sigue siendo el mecanismo de validación estándar en las PKI empresariales, las jerarquías de confianza privadas y los entornos especializados en los que no se aplica el comportamiento de los navegadores.

¿Se va a dejar de utilizar el protocolo OCSP?

En resumen, no. Sin embargo, existe una tendencia a eliminar progresivamente el protocolo OCSP de la PKI pública en la web. Los principales fabricantes de navegadores han llegado a la conclusión de que el OCSP no ofrece una protección fiable, ya que la mayoría de las implementaciones utilizan un modelo de «fallo suave»: si no se puede acceder al servidor de respuesta OCSP, el navegador continúa la conexión de todos modos. El OCSP también genera latencia, plantea problemas de privacidad (ya que el número de serie del certificado se revela al servidor de respuesta) y aumenta la complejidad operativa.

Como consecuencia, los ecosistemas de los navegadores están evolucionando hacia mecanismos de revocación alternativos. Chrome lleva mucho tiempo basándose en datos de revocación gestionados por el propio navegador, en lugar de consultas OCSP en tiempo real, mientras que Firefox ha adoptado CRLite. Este cambio se ve acelerado aún más por la reducción de la vigencia de los certificados —incluida la tendencia haciacertificados de 47 días— y por la decisión de las principales autoridades de certificación (CA) de dejar de ofrecer compatibilidad con OCSP.

Sin embargo, el protocolo OCSP no está desapareciendo de la PKI en su conjunto. Sigue utilizándose ampliamente en las PKI empresariales, las infraestructuras gubernamentales, los sistemas de autenticación de VPN, los ecosistemas de firma de código y otros entornos gestionados en los que los clientes y los servidores de respuesta están bajo un control centralizado. En estos entornos, el protocolo OCSP sigue proporcionando información oportuna sobre revocaciones y da respuesta a requisitos de validación que no abordan las alternativas centradas en los navegadores.

Para las organizaciones que gestionan su propia PKI, la conclusión práctica es la siguiente: el protocolo OCSP está evolucionando, no desapareciendo. Su infraestructura OCSP seguirá desempeñando un papel fundamental en entornos PKI empresariales y privados, aunque los navegadores web públicos utilicen mecanismos diferentes.

Supervisión y disponibilidad de OCSP

Para las organizaciones que utilizan el protocolo OCSP para la validación de certificados, supervisar la disponibilidad del servidor de respuesta OCSP no es opcional. Un servidor de respuesta OCSP que no responda puede tener efectos en cadena en todo el entorno, desde TLS fallidas hasta el bloqueo del acceso a la VPN o la interrupción de los flujos de trabajo de las aplicaciones.

Las consecuencias de una interrupción en el servicio del servidor de respuesta OCSP dependen de cómo estén configurados tus clientes. En un entorno de «soft-fail», una interrupción puede pasar desapercibida, ya que los clientes omiten de forma silenciosa la comprobación de revocación. Esto crea un punto ciego en el que podrían aceptarse certificados revocados. En un entorno de «hard-fail» (o cuando se utiliza la opción «Must-Staple» de OCSP), una interrupción en el servicio del servidor de respuesta provoca directamente fallos en la conexión.

Cualquiera de los dos escenarios plantea problemas. En el primer caso, se pierde la garantía de seguridad que ofrece la comprobación de revocaciones. En el segundo, se producen interrupciones en la disponibilidad que pueden afectar a toda la infraestructura.

La supervisión proactiva del OCSP aborda ambos riesgos. Al comprobar continuamente si los puntos finales del OCSP responden, se pueden detectar interrupciones antes de que afecten a los usuarios y activar alertas automáticas para el equipo de operaciones. Las herramientasde automatización del ciclo de vida de los certificadosofrecen esta capacidad como parte de un enfoque más amplio de la gestión de la infraestructura de certificados, lo que proporciona a su equipo visibilidad sobre el estado del OCSP, además de sobre la caducidad, la emisión y la renovación de los certificados.

Cómo Keyfactor con el protocolo OCSP

La gestión de la infraestructura OCSP a gran escala requiere algo más que poner en marcha un servidor de respuesta. Requiere visibilidad, automatización y una plataforma PKI que considere la revocación como una prioridad operativa fundamental.

EJBCA, la plataforma PKI Keyfactor, incluye un componente de autoridad de validación (VA) integrado que admite tanto los respondedores OCSP como la publicación de listas CRL. El respondedor OCSP EJBCAes compatible con modelos de firma integrados en la CA y delegados, implementaciones con múltiples CA y arquitecturas de alta disponibilidad con varios nodos de respondedor.

Keyfactor Command ofrece supervisión y alertas continuas de los puntos finales OCSP como parte de su plataforma de automatización del ciclo de vida de los certificados. Su equipo puede realizar un seguimiento de la disponibilidad de los servidores de respuesta OCSP en tiempo real, recibir notificaciones cuando los puntos finales dejen de responder y correlacionar el estado de los servidores de respuesta con el estado general de su entorno de certificados.

PKI como servicio ofrece una PKI totalmente gestionada que incluye una infraestructura de respuesta OCSP, de modo que las organizaciones pueden liberarse de la carga operativa que supone gestionar y supervisar su propia infraestructura de revocación.