El número mágico de OCSP

El Protocolo de estado de certificados en línea (OCSP) es uno de los componentes más críticos de una infraestructura de clave pública (PKI) moderna. Proporciona a los clientes un método rápido y en tiempo real para determinar si un certificado sigue siendo confiable sin descargar una lista de revocación de certificados (CRL) completa. En la mayoría de los entornos empresariales, la eficiencia es importante. La autenticación con tarjeta inteligente, el acceso VPN, las conexiones TLS, la autenticación Wi-Fi y los flujos de trabajo de registro de dispositivos dependen de revocación de certificado Las comprobaciones se realizan de forma rápida y fiable entre bastidores.

Oculto dentro del motor de revocación de Windows hay un comportamiento menos conocido que puede cambiar silenciosamente cómo certificado La validación se realiza en el sistema del cliente. Los profesionales de PKI suelen referirse a este umbral como el Número Mágico de OCSP. Una vez que un cliente Windows almacena en caché más de un cierto número de respuestas OCSP del mismo respondedor, CryptoAPI puede dejar de priorizar OCSP y empezar a preferir las CRL. Por defecto, este umbral es de tan solo 50 respuestas OCSP almacenadas en caché.

En algunos entornos, este comportamiento es inofensivo e incluso beneficioso. En otros, especialmente en organizaciones que implementaron OCSP específicamente para evitar listas de revocación de certificados (CRL) extensas o para admitir la verificación de revocación determinista, puede generar problemas operativos y de seguridad extremadamente difíciles de diagnosticar. Lo que complica aún más la situación es que la transición se produce de forma silenciosa. El propio respondedor OCSP permanece en buen estado, no aparece ningún error evidente en los registros de eventos de Windows y es posible que los administradores no tengan ninguna indicación de que los clientes hayan cambiado sus métodos de revocación.

Para comprender el número mágico de OCSP, es necesario entender cómo Windows gestiona la comprobación de revocación de certificados internamente. Una vez que se comprende cómo CryptoAPI decide entre OCSP y CRL, muchos comportamientos de revocación que parecen inconsistentes o impredecibles en entornos de Servicios de certificados de Active Directory (AD CS) empresariales resultan mucho más fáciles de explicar y solucionar. Esto es lo que todo administrador de PKI debe saber al respecto.

¿Qué es el OCSP?

El Protocolo de estado de certificado en línea (OCSP) se estandarizó por primera vez en el RFC 2560 en 1999 y posteriormente se actualizó al RFC 6960 en junio de 2013, que sigue siendo el estándar actual. Proporciona a las partes que confían en él una forma de comprobar si se ha emitido un certificado X.509 específico. revocado en tiempo real, sin necesidad de descargar una lista completa de revocación de certificados (CRL).

La diferencia fundamental entre ambos es sencilla. Lista de revocación de certificados (CRL) es una lista publicada periódicamente de todos los certificados que han sido revocados mientras aún se encuentran dentro de su período de validez. La CRL es emitida por el Autoridad de certificación (CA) y los clientes la descargan íntegramente para su validación. En entornos empresariales de gran tamaño, las CRL pueden alcanzar un tamaño considerable (desde megabytes hasta más), lo que aumenta el uso del ancho de banda y retrasa la vigencia de la revocación hasta el siguiente ciclo de publicación.

En cambio, OCSP es un mecanismo basado en solicitudes que realiza la validación de cada certificado individualmente. El cliente envía una solicitud específica que contiene el hash del nombre del emisor, el hash de la clave del emisor y el número de serie del certificado a un respondedor OCSP, que devuelve una respuesta firmada digitalmente y con marca de tiempo que indica uno de tres estados: Válido, Revocado o Desconocido. Las respuestas OCSP suelen ser pequeñas (alrededor de 2 KB), lo que las hace significativamente más eficientes en términos de uso de la red.

Esto hace que OCSP sea significativamente más eficiente que la revocación basada en CRL, especialmente en grandes implementaciones de PKI donde el tamaño de las CRL genera problemas reales de red y rendimiento. Además, permite respuestas de revocación en tiempo real que las CRL simplemente no pueden proporcionar.

¿Cuál es el número mágico de OCSP?

Cuando un cliente de Windows realiza una comprobación de revocación de certificados y un certificado contiene tanto una URL OCSP como una URL CRL, CryptoAPI no utiliza simplemente OCSP en todos los casos. La URL OCSP se publica en el Acceso a la información de la autoridad (AIA) extensión del certificado, mientras que la URL de la CRL se publica en la extensión CDP. CryptoAPI evalúa ambas durante la comprobación de revocación y toma una decisión en función de cuántas respuestas OCSP ya ha almacenado en caché de ese respondedor para esa CA.

De acuerdo con Documentación de Microsoft En la sección "Cómo funciona la revocación de certificados", CryptoAPI calcula el número total de respuestas OCSP almacenadas en caché desde una única URL de respuesta OCSP y compara ese recuento con un umbral predefinido conocido como recuento mágico. Por defecto, ese umbral está establecido en 50.

CryptoAPI aplica entonces tres reglas basadas en ese recuento. Si el número es menor o igual al recuento mágico, las URL OCSP se procesan en el orden que indica la extensión de Acceso a la Información de la Autoridad. Si el número es mayor que el recuento mágico, las URL CRL se procesan en el orden que indica la extensión del punto de distribución de CRL. Y si ninguna de las URL OCSP de la extensión de Acceso a la Información de la Autoridad tiene éxito, el cliente recurre al uso de CRL.

También es importante comprender que el número mágico no es la única condición que puede activar esta opción de reserva. La documentación de Microsoft identifica un segundo desencadenante: una directiva de grupo configurada explícitamente para dar preferencia a las CRL sobre OCSP para la comprobación de revocación. Cuando esta directiva está activa, el cliente recurre a las CRL independientemente de cuántas respuestas OCSP se hayan almacenado en caché, omitiendo por completo la lógica basada en el recuento.

Los dos desencadenantes son independientes entre sí. El número mágico controla la opción de reserva automática que se activa según el volumen de caché. La directiva de grupo controla la opción de reserva administrativa que una organización puede implementar deliberadamente. Ambas opciones tienen el mismo resultado: las consultas OCSP se detienen y se activa la comprobación de la lista de revocación de certificados (CRL).

¿Por qué Microsoft lo introdujo?

El número mágico no es un error. Microsoft documentó claramente la razón de ser de esto, y es una razón razonable en escenarios específicos.

Consideremos un controlador de dominio que gestiona inicios de sesión con tarjetas inteligentes. Cada evento de autenticación activa una comprobación de revocación. Según la documentación de Microsoft, una respuesta OCSP típica tiene un tamaño aproximado de 2 KB.

En un escenario donde decenas de miles de usuarios, por ejemplo, 50 000, se autentican mediante tarjeta inteligente dentro de un único período de revocación, esas respuestas individuales acumularían aproximadamente 100 MB de datos de respuesta OCSP en caché. Una lista de revocación de certificados (CRL) que cubra esas mismas entradas ocuparía aproximadamente 4 MB, basándose en un estimado de 80 bytes por entrada. A esa escala, descargar la CRL una sola vez y reutilizarla localmente es significativamente más eficiente que realizar decenas de miles de consultas OCSP individuales.

El número mágico le da a CryptoAPI una forma de hacer esa determinación de eficiencia automáticamente. Una vez que se almacena en caché OCSP Cuando el número de respuestas supera el umbral, el cliente cambia a la CRL sin intervención del administrador. Para entornos con CRL pequeñas y un alto volumen de validación de certificados, esta es una optimización integrada muy útil.

El problema radica en que se aplica universalmente a todos los entornos Windows, independientemente de si esa compensación resulta conveniente para una implementación específica. Y cuando se activa, lo hace sin ninguna entrada en el registro, alerta ni indicación visible de que el mecanismo de revocación haya cambiado. Esa invisibilidad es lo que convierte una optimización razonable en un riesgo operativo y de seguridad real, dependiendo del motivo por el que su organización implementó OCSP en primer lugar.

Por qué esto es un problema

Aquí es donde el Número Mágico deja de ser una optimización y se convierte en un problema. Sus servidores OCSP siguen funcionando correctamente. Continúan recibiendo consultas de clientes que aún no han superado el umbral. Nada en el servidor indica que ciertos clientes hayan dejado de usarlo por completo. Existen dos escenarios en los que esta medida de seguridad provoca una falla de seguridad directa o una interrupción operativa.

Escenario 1: Grandes CRL

Implementaste OCSP precisamente porque tu CRL se había vuelto inmanejable. Los puntos finales sufrían tiempos de espera al intentar descargarla. Las comprobaciones de revocación fallaban. Configuraste un respondedor OCSP, actualizaste la configuración de tu CA, probaste todo y seguiste adelante. Entonces, ocurre lo inesperado: los clientes de Windows vuelven a descargar la misma CRL que intentabas evitar. Vuelves a tener tiempos de espera y fallos, sin ninguna indicación de qué sucedió ni por qué. Tu infraestructura OCSP funciona perfectamente. Simplemente no se está utilizando.

Escenario 2: Respuestas deterministas y los límites de la reversión a CRL

De forma predeterminada, el Respondedor en línea de Microsoft devuelve "BUENO" para los números de serie de certificados que no aparecen en la CRL. La revisión 2960124 de Microsoft soluciona este problema permitiendo que el Respondedor en línea devuelva respuestas deterministas que pueden distinguir entre certificados emitidos legítimamente y certificados falsificados. Cuando los clientes recurren a la comprobación de la CRL, esta protección desaparece por completo. Un certificado falsificado con un número de serie que no aparece en la CRL superará la validación sin problemas.

Lo que hace que esto sea particularmente peligroso es que Windows no genera un evento específico que indique que se superó el umbral de caché OCSP y que cambió la preferencia de revocación. No hay ningún evento en el registro de eventos de Windows ni ninguna alerta en el respondedor OCSP. La única forma de detectar el cambio es observar el tráfico de red sin procesar y notar que los clientes han dejado de enviar solicitudes OCSP y han comenzado a obtener la CRL.

La combinación de conmutación silenciosa y una infraestructura OCSP de aspecto saludable permite a las organizaciones operar durante períodos prolongados creyendo que su comprobación de revocación funciona exactamente como se diseñó, cuando en realidad una parte significativa de sus clientes abandonó OCSP hace semanas.

Cómo funciona la caché y qué es lo que Windows realmente contabiliza.

Cuando CryptoAPI obtiene y valida una respuesta OCSP, no la descarta. CryptoAPI almacena la respuesta localmente en un directorio llamado CryptnetUrlCache. Para las cuentas de usuario estándar, esta caché se encuentra en:

%USERPROFILE%\AppData\LocalLow\Microsoft\CryptnetUrlCache

Para servicios a nivel de sistema, como un controlador de dominio que procesa inicios de sesión con tarjeta inteligente, se almacena en:

%WINDIR%\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache

Cada vez que se almacena una respuesta OCSP válida para una combinación específica de URL de respondedor y CA, CryptoAPI incrementa el contador que sigue en relación con el umbral numérico. Este conteo no es global; se realiza por usuario, por URL de respondedor OCSP y por CA. Esto significa que si un único respondedor en línea presta servicios a dos CA emisoras, el contador se mantiene de forma independiente para cada una. Superar el umbral para una CA no afecta al contador de la otra.

Este seguimiento por usuario y por CA también explica un comportamiento que realmente confunde a los administradores: dos máquinas que realizan cargas de trabajo de validación de certificados idénticas pueden tener recuentos completamente diferentes dependiendo de cuánto tiempo hayan estado funcionando y cuántos certificados hayan validado. Una puede seguir consultando OCSP mientras que la otra ya ha cambiado a CRL, sin ninguna diferencia de configuración visible entre ellos.

El conteo no se mantiene indefinidamente. Por eso, algunos equipos observan problemas de verificación de revocación que parecen resolverse solos después de reiniciar el sistema; una vez reiniciada la máquina, las consultas OCSP se reanudan con normalidad hasta que se vuelve a superar el umbral. Comprender este ciclo es importante, pero saber cómo detectar el cambio antes de que cause daños es lo que realmente protege su entorno.

Cómo detectarlo

Dado que Windows no genera ningún registro ni activa ninguna alerta cuando se alcanza el número mágico, la detección requiere una monitorización proactiva o una inspección directa.

El método más fiable es el análisis del tráfico de red. Un cliente que haya cruzado el umbral dejará de enviar solicitudes a su respondedor OCSP y comenzará a realizar solicitudes HTTP GET a su CRL En cambio, se trata de un punto de distribución. Si se establece un volumen de consulta OCSP normal por cliente y se supervisan las caídas inesperadas, el conmutador se vuelve detectable. Observar un pico correspondiente en el tráfico de descarga de CRL del mismo cliente refuerza la señal.

En el lado del cliente, puede inspeccionar directamente la configuración actual del registro. El valor relevante es:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\ChainEngine\Config\CryptnetCachedOcspSwitchToCrlCount

Si esta clave no existe en una máquina determinada, se aplica el umbral predeterminado. Si existe, el valor indica el umbral configurado. La auditoría de esta clave en todo el entorno mediante informes de directivas de grupo o una herramienta de administración de configuración permite comprobar si el valor se ha configurado correctamente en los clientes.

Para una investigación más exhaustiva, se puede habilitar el registro de diagnóstico de CAPI2 en los clientes de Windows para capturar la actividad detallada de creación de cadenas de certificados y comprobación de revocación. Si bien CAPI2 no registra el cambio de número mágico en sí, sí registra el método de revocación utilizado para cada validación de certificado. Un patrón de validaciones basadas en CRL en un cliente que debería usar OCSP es un claro indicador de que se ha superado el límite. Una vez confirmado esto, o si se desea evitar que ocurra, el cambio de configuración es sencillo.

Cómo configurar el número mágico

Existen dos maneras de cambiar el umbral del número mágico: mediante la Directiva de grupo, que es el método recomendado para entornos unidos a un dominio, o directamente a través del registro para máquinas individuales o con fines de prueba.

1. Mediante la Política de grupo

Navegue a la siguiente ruta en el Editor de administración de directivas de grupo:

Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas de clave pública > Configuración de validación de ruta de certificado

En la pestaña Revocación, localice la opción denominada "Preferir las respuestas CRL a las respuestas OCSP si el número de respuestas OCSP almacenadas en caché correspondientes al mismo punto de distribución de CRL es mayor que". Establezca un valor que refleje el volumen de validación de certificados previsto.

Cuando se aplica esta política, Windows crea automáticamente el siguiente valor de registro:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\ChainEngine\Config\CryptnetCachedOcspSwitchToCrlCount

2. Mediante registro

Si la Directiva de grupo no está disponible, puede crear o modificar el valor DWORD CryptnetCachedOcspSwitchToCrlCount directamente en la misma ruta del registro. Esto es adecuado para equipos individuales o pruebas de laboratorio, pero la Directiva de grupo sigue siendo el método recomendado para implementaciones a gran escala.

Dos notas importantes:

No es posible desactivar la reserva basada en el recuento únicamente mediante esta configuración del registro. Establecer CryptnetCachedOcspSwitchToCrlCount en 0 no desactiva la reserva; simplemente restablece el umbral predeterminado de 50. Las organizaciones que necesiten deshabilitar por completo la obtención de OCSP deben usar el valor DWORD Options con el indicador CERT_CHAIN_OPTION_DISABLE_AIA_URL_RETRIEVAL (0x2) en la misma ruta del registro. Sin embargo, para la mayoría de los entornos, la solución práctica consiste en establecer un umbral lo suficientemente alto como para que nunca se alcance durante los picos de volumen de validación.

Tampoco existe un valor universalmente correcto. El umbral adecuado depende completamente del volumen de validación de certificados. Un servidor RADIUS que valida certificados VPN tendrá requisitos muy diferentes a los de un controlador de dominio que procesa inicios de sesión con tarjetas inteligentes. Primero, audite su entorno, comprenda el volumen máximo de validación por sistema y establezca el umbral en función de lo que observe en la práctica, en lugar de un valor arbitrario. Dicha auditoría requiere visibilidad de toda la arquitectura de revocación, y es ahí donde contar con la experiencia adecuada marca la diferencia.

Cómo puede ayudar la consultoría de cifrado

El número mágico de OCSP es un tipo de brecha de configuración que rara vez sale a la luz hasta que algo falla. La mayoría de las organizaciones lo descubren a través de un fallo de revocación, un hallazgo en una auditoría de seguridad o una captura de red que revela que sus clientes han abandonado OCSP silenciosamente. Para entonces, la vulnerabilidad ya lleva tiempo presente. Identificarlo y corregirlo de forma proactiva requiere saber que existe, saber dónde buscar y comprender cómo interactúa con el resto de la arquitectura de revocación.

Ese es precisamente el trabajo que realiza nuestro equipo. En Encryption Consulting, nuestro equipo de Servicios PKI colabora con organizaciones de los sectores financiero, sanitario, gubernamental y tecnológico para evaluar, diseñar y validar infraestructuras de revocación que resistan en condiciones reales. Ofrecemos servicios profesionales y nuestra plataforma de automatización (CertSecure Manager) para garantizar que su PKI sea segura, resiliente y esté preparada para el futuro.

Servicios de PKI

Consultoría de cifrado Servicios de PKI Cubrimos todo el ciclo de vida del proyecto, desde la definición inicial del alcance hasta la implementación y el soporte a largo plazo. Cada fase se estructura en función de su entorno, sus requisitos normativos y su realidad operativa.

• Planificación de proyectos

Evaluamos su entorno criptográfico, revisamos las configuraciones, dependencias y requisitos de PKI y consolidamos los hallazgos en un plan de proyecto estructurado y aprobado por el cliente.

• Desarrollo de CP/CPS

En la siguiente fase, desarrollamos la Política de Certificación (PC) y la Declaración de Prácticas de Certificación (DPC) en consonancia con la RFC#3647. Estos documentos se adaptan a los requisitos regulatorios, de seguridad y operativos de su organización.

• Diseño e implementación de PKI

Diseñamos e implementamos infraestructuras PKI resilientes con CA raíz offline, CA emisoras, servidores NDES, integración con HSM, etc., según las necesidades del cliente. Los entregables incluyen el documento de diseño de PKI, guías de compilación, scripts de ceremonias y configuraciones del sistema. Una vez implementada, realizamos pruebas exhaustivas, validación, optimización y sesiones de transferencia de conocimientos para capacitar a su equipo.

• Continuidad del negocio y recuperación ante desastres

Luego de la implementación, desarrollamos e implementamos estrategias de continuidad comercial y recuperación ante desastres, realizamos pruebas de conmutación por error y documentamos flujos de trabajo operativos para toda la infraestructura de PKI y HSM, respaldados por una guía integral de operaciones de PKI.

• Soporte y mantenimiento continuos (opcional)

Tras la implementación, ofrecemos un paquete de soporte anual por suscripción que ofrece cobertura integral para los componentes PKI, CLM y HSM. Esto incluye respuesta a incidentes, resolución de problemas, optimización del sistema, gestión del ciclo de vida de los certificados, actualizaciones de CP/CPS, archivado de claves, actualizaciones de firmware de HSM, registro de auditoría y gestión de parches.

Este enfoque garantiza que su infraestructura PKI no solo sea segura y compatible, sino también escalable, resiliente y totalmente alineada con sus objetivos operativos y regulatorios a largo plazo.

Nuestra solución de gestión del ciclo de vida de los certificados: CertSecure Manager

CertSecure Manager de Encryption Consulting es una solución de gestión del ciclo de vida de los certificados que simplifica y automatiza todo el ciclo de vida, lo que le permite centrarse en la seguridad en lugar de en otras cosas. renovaciones.

CertSecure Manager de Encryption Consulting es una solución de gestión del ciclo de vida de los certificados que centraliza el descubrimiento, la automatización, el registro, la aplicación de políticas y las integraciones en todo su entorno PKI. Previene interrupciones con renovaciones automatizadas, mejora el cumplimiento normativo y unifica la gestión de las CA públicas y privadas a través de una única plataforma escalable. Algunas de las características clave de CertSecure Manager incluyen:

• Automatización para certificados de corta duración: Con la adopción de los certificados ACME y TLS de 90/47 días como estándar, la renovación manual ya no es una opción práctica. CertSecure Manager automatiza la inscripción, la renovación y la implementación para garantizar que los certificados caduquen sin previo aviso.
• Integración perfecta de DevOps y la nube: Los certificados se pueden aprovisionar directamente en servidores web e instancias en la nube, y se integran con herramientas de registro modernas como Datadog, Splunk, herramientas ITSM como ServiceNow y herramientas DevOps como Terraform y Ansible.
• Compatibilidad con múltiples CA: Muchas organizaciones utilizan múltiples CA (CA interna de Microsoft, CA públicas como DigiCert y GlobalSign, etc.). CertSecure Manager se integra con estas fuentes, proporcionando un único panel para la gestión de la emisión y el ciclo de vida.
• Políticas unificadas de emisión y renovación: CertSecure Manager aplica los tamaños de clave, los algoritmos y las reglas de renovación de su organización de manera consistente en todos los certificados, no solo automatizando las renovaciones con múltiples CA, sino garantizando que cada certificado cumpla con sus estándares de seguridad en todo momento.
• Monitoreo proactivo y pruebas de renovación: El monitoreo continuo, combinado con pruebas simuladas de renovación/vencimiento, garantiza que usted identifique los riesgos antes de que los certificados afecten los sistemas de producción.
• Visibilidad y cumplimiento centralizados: Un panel consolidado muestra todos los certificados, la longitud de las claves, los algoritmos seguros y débiles, y sus fechas de caducidad. Los registros de auditoría y la aplicación de políticas simplifican el cumplimiento de PCI DSS, HIPAA y otros marcos.

Si aún te preguntas por dónde y cómo empezar a proteger tu PKI, Encryption Consulting está aquí para ayudarte con sus Servicios de Soporte PKI. Puedes contar con nosotros como tu socio de confianza y te guiaremos en cada paso con claridad, seguridad y experiencia práctica. Contáctanos en [email protected] para comenzar.

Conclusión

El número mágico de OCSP es uno de esos comportamientos de la infraestructura de clave pública (PKI) de Microsoft que solo se manifiestan durante la resolución de problemas, aunque su causa es sencilla. Lo que no es sencillo es diagnosticarlo. No hay registro de eventos. No hay alerta. No hay indicación en el respondedor OCSP. Simplemente es un interruptor silencioso que deja la infraestructura de revocación funcionando perfectamente mientras los clientes ya han cambiado de sistema. La única forma de anticiparse es conocer bien el entorno para configurarlo intencionadamente, antes de que el umbral se configure automáticamente.

Microsoft diseñó este comportamiento deliberadamente. CryptoAPI está diseñado para determinar dinámicamente si OCSP o las CRL proporcionan el mecanismo de revocación más eficiente según las condiciones actuales de la caché. El umbral de conteo mágico es simplemente el punto de inflexión que se utiliza para tomar esa decisión. Comprender este comportamiento es importante para cualquier persona que administre entornos PKI empresariales, especialmente aquellos que involucran sistemas de autenticación a gran escala.

Si su organización implementó OCSP específicamente para gestionar listas de revocación de certificados (CRL) extensas o para aplicar comprobaciones de revocación deterministas, el Número Mágico no es un detalle de implementación, sino una configuración que debe gestionarse activamente. Conozca el tamaño de su CRL, el volumen máximo de validación de certificados en sistemas críticos y establezca el umbral de forma deliberada según sus requisitos, en lugar de aceptar un valor predeterminado diseñado para un entorno diferente al que utiliza.