El número mágico de OCSP

El Protocolo de Estado de Certificados en Línea (OCSP) es uno de los componentes más importantes 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 necesidad de descargar una Lista de Revocación de Certificados (CRL) completa. En la mayoría de los entornos empresariales, la eficiencia es fundamental. La autenticación con tarjetas inteligentes, el acceso VPN, las conexiones TLS, la autenticación Wi-Fi y los flujos de trabajo de registro de dispositivos dependen de que las comprobaciones de revocación de certificados se realicen de forma rápida y confiable en segundo plano.

Oculto en el motor de revocación de Windows se encuentra un comportamiento menos conocido que puede modificar silenciosamente el funcionamiento de la validación de certificados en un sistema cliente. Los profesionales de PKI suelen referirse a este umbral como el Número Mágico de OCSP. Una vez que un cliente de Windows almacena en caché más de un cierto número de respuestas OCSP del mismo respondedor, CryptoAPI puede dejar de priorizar OCSP y comenzar 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.

Respuesta rápida: ¿Cuál es el número mágico de OCSP?

El número mágico de OCSP es un umbral de CryptoAPI de Windows (valor predeterminado: 50) almacenado en el valor del registro CryptnetCachedOcspSwitchToCrlCount . Cuando las respuestas OCSP almacenadas en caché de una única URL de respuesta para una CA determinada superan este valor, CryptoAPI cambia automáticamente la comprobación de revocación de OCSP a CRL. No se genera ninguna entrada en el registro de eventos. El respondedor OCSP aparece como correcto. Se puede configurar mediante directivas de grupo en la configuración de validación de ruta de certificado.

Puntos Clave

• El número mágico de OCSP es un umbral integrado de la API criptográfica de Windows (valor predeterminado: 50) que determina cuándo la comprobación de revocación de certificados cambia de OCSP a CRL. Este cambio es totalmente silencioso: no genera ninguna entrada en el registro de eventos de Windows, ningún error del respondedor OCSP ni ninguna alerta del cliente. Los únicos indicadores son los cambios en el tráfico de red, que requieren una monitorización activa para su detección.
• CryptoAPI aplica tres reglas basadas en el número de respuestas almacenadas en caché: si el número es menor o igual al valor predeterminado, las URL OCSP se procesan según el orden de extensión de AIA; si el número es mayor que el valor predeterminado, las URL CRL se procesan según el orden de extensión de CDP; y si todas las URL OCSP fallan, se recurre a las CRL independientemente del número. La directiva de grupo configurada para dar preferencia a las CRL sobre OCSP es un segundo desencadenante independiente que omite por completo la lógica basada en el número de respuestas.
• El recuento se realiza por usuario, por URL de respuesta OCSP y por CA. Esto significa que dos máquinas con configuraciones idénticas pueden tener recuentos completamente diferentes según su historial de validación. Una puede seguir consultando OCSP mientras que la otra ya ha cambiado a CRL, sin que exista ninguna diferencia de configuración visible entre ellas.
• Establecer el valor del registro CryptnetCachedOcspSwitchToCrlCount en 0 no desactiva la reserva. Restablece el umbral predeterminado de 50. Las organizaciones que necesiten deshabilitar completamente 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.
• El contador no se mantiene indefinidamente. Reiniciar la máquina restablece el contador de la caché OCSP, por lo que algunos equipos observan problemas de comprobación de revocación que parecen resolverse solos tras un reinicio. Las consultas OCSP se reanudan con normalidad hasta que se vuelve a superar el umbral.

¿A quién debería importarle el número mágico de OCSP?

El número mágico de OCSP es principalmente una preocupación para las operaciones de AD CS y PKI de Windows, pero sus consecuencias en materia de seguridad y cumplimiento afectan a todos los equipos que dependen de que la revocación de certificados funcione según lo documentado.

Matriz de escenarios de números mágicos de OCSP: Requisito, método de validación, modo de fallo y señal de monitorización.

Utilice esta matriz para identificar qué escenario se aplica a su entorno, validar que la comprobación de revocación funciona según lo previsto, comprender el modo de fallo si el Número Mágico se activa inesperadamente e identificar la señal de monitorización que detecta el interruptor antes de que provoque un incidente.

¿Qué es OCSP?

El Protocolo de estado de certificados 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 vigente. Permite a las partes que confían en un certificado comprobar en tiempo real si un certificado X.509 específico ha sido revocado , sin necesidad de descargar la Lista de revocación de certificados (CRL) completa.

La diferencia fundamental entre ambos es sencilla. Una Lista de Revocación de Certificados (CRL, por sus siglas en inglés) es una lista que se publica periódicamente con todos los certificados que han sido revocados mientras aún estaban dentro de su período de validez. La Autoridad de Certificación (CA, por sus siglas en inglés) emite la CRL 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 en adelante), lo que aumenta el consumo de ancho de banda y retrasa la actualización de la información de 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 la extensión Authority Information Access (AIA) del certificado, mientras que la URL 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.

Según la documentación de Microsoft sobre "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 permite a CryptoAPI determinar automáticamente la eficiencia. Una vez que el número de respuestas OCSP almacenadas en caché 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 la conmutación silenciosa y una infraestructura OCSP aparentemente saludable permite a las organizaciones operar durante períodos prolongados creyendo que su verificación de revocación funciona exactamente como se diseñó, cuando en realidad una parte significativa de sus clientes abandonó OCSP hace semanas. La encuesta DigiCert Trust Pulse (julio de 2025) reveló que el 45 % de las empresas experimentaron tiempo de inactividad relacionado con certificados el año anterior; la conmutación silenciosa del mecanismo de revocación es una forma de ese mismo riesgo operativo, invisible hasta que falla algún componente posterior.

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 idénticas de validación de certificados pueden tener recuentos completamente diferentes dependiendo del tiempo que lleven funcionando y de la cantidad de certificados que hayan validado. Una puede seguir consultando OCSP mientras que la otra ya ha cambiado a CRL , sin ninguna diferencia de configuración visible entre ellas.

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 superado el umbral dejará de enviar solicitudes a su respondedor OCSP y comenzará a realizar solicitudes HTTP GET a su punto de distribución de CRL . Si se establece un volumen de consulta OCSP normal por cliente y se monitorizan las caídas inesperadas, el cambio 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

Los servicios de infraestructura de clave pública (PKI) de Encryption Consulting abarcan 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 proceso, lo que le permite centrarse en la seguridad en lugar de en las 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 no sabe por dónde empezar a proteger su infraestructura de clave pública (PKI), Encryption Consulting le ofrece sus servicios de soporte. Puede contar con nosotros como su socio de confianza; le guiaremos en cada paso con claridad, seguridad y experiencia práctica. Contáctenos 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.

Preguntas frecuentes

¿Cuál es la principal conclusión de "El número mágico de OCSP"?

El número mágico de OCSP es un umbral de CryptoAPI de Windows (valor predeterminado: 50) almacenado en el valor del registro CryptnetCachedOcspSwitchToCrlCount. Cuando las respuestas OCSP almacenadas en caché de una única URL de respuesta para una CA determinada superan este valor, CryptoAPI cambia silenciosamente la comprobación de revocación de OCSP a CRL. No se genera ninguna entrada en el registro de eventos de Windows y el respondedor OCSP aparece como correcto. Si se establece el valor en 0, se restablece el valor predeterminado de 50, pero no se desactiva la opción de reserva. El umbral se puede configurar mediante la Directiva de grupo en Configuración de validación de ruta de certificado > pestaña Revocación.

¿Por qué es importante el número mágico de OCSP para los equipos de PKI empresariales?

Los equipos de PKI empresariales implementan OCSP por dos razones específicas por las que el Número Mágico puede socavar silenciosamente. Primero, para evitar grandes CRL: la opción de respaldo del Número Mágico reintroduce el problema de descarga de CRL precisamente en los sistemas de alto volumen donde el tráfico OCSP es mayor. Segundo, para aplicar una verificación de revocación determinista: cuando los clientes recurren a la CRL después de superar el umbral, la protección proporcionada por la revisión 2960124 de Microsoft desaparece y los certificados falsificados con números de serie que no están en la CRL pasan la validación silenciosamente. La encuesta DigiCert Trust Pulse (julio de 2025) encontró que el 45 por ciento de las empresas experimentaron tiempo de inactividad relacionado con certificados en el año anterior; el cambio silencioso del mecanismo de revocación es una forma de ese riesgo operativo.

¿Qué riesgos aumentan si el número mágico de OCSP no se gestiona activamente?

Aumentan tres categorías de riesgo: la reversión no detectada de CRL (los sistemas de autenticación de alto volumen superan rápidamente el umbral de 50 respuestas y comienzan a descargar CRL sin ninguna alerta; si las CRL son grandes o los puntos de distribución de CRL son inaccesibles, las comprobaciones de revocación fallan silenciosamente); la pérdida de la comprobación de revocación determinista (los clientes que recurrieron a CRL pierden la protección de la revisión 2960124, lo que permite que los certificados falsificados pasen la validación si sus números de serie no están en la CRL); y el comportamiento inconsistente de la revocación en toda la flota (dos máquinas con configuraciones idénticas pueden tener recuentos de caché OCSP completamente diferentes, lo que hace que la resolución de problemas parezca no determinista).

¿Qué equipos deberían tener la configuración del Número Mágico de OCSP?

Los administradores de PKI son responsables de la configuración del umbral: auditan el valor del registro CryptnetCachedOcspSwitchToCrlCount en toda la flota, miden los volúmenes máximos de validación de certificados por tipo de sistema e implementan el umbral correcto mediante directivas de grupo. Los arquitectos de seguridad son responsables del diseño de la política de revocación: determinan si se requieren respuestas deterministas de la revisión 2960124 y si el umbral del número mágico debe establecerse lo suficientemente alto como para que nunca se supere. Los equipos de plataforma son responsables de supervisar el volumen de consultas OCSP y el volumen de descargas de CRL por cliente para detectar superaciones del umbral. Los equipos de cumplimiento son responsables de la evidencia de que la comprobación de revocación funciona según lo documentado en la Declaración de Prácticas de Certificados.

¿Cómo se relaciona el número mágico de OCSP con la gestión del ciclo de vida de los certificados?

El número mágico de OCSP es una brecha en la configuración de la infraestructura de revocación que una plataforma CLM detecta como parte de una evaluación más amplia del estado de la PKI. CertSecure Manager proporciona el inventario de certificados y la capa de monitorización de la infraestructura que correlaciona el volumen de consultas del respondedor OCSP con el comportamiento del cliente, detecta cuándo es probable que los sistemas de autenticación de alto volumen superen el umbral del número mágico e incluye la configuración CryptnetCachedOcspSwitchToCrlCount en la línea base de la postura de la PKI. Sin la cobertura de CLM, el umbral solo se descubre cuando algo falla.

¿Cómo deberían las organizaciones medir el éxito en la gestión del Número Mágico de OCSP?

Métricas clave: consistencia del volumen de consultas OCSP por cliente de alto volumen (los controladores de dominio, los servidores RADIUS y las puertas de enlace VPN deben mostrar una tasa de consultas OCSP estable que no disminuya repentinamente sin un cambio de configuración correspondiente); cumplimiento de la configuración CryptnetCachedOcspSwitchToCrlCount (el valor del registro debe estar establecido por encima del recuento máximo esperado de respuestas OCSP para cada tipo de sistema, verificado trimestralmente a través de informes de directivas de grupo); volumen de descarga de CRL por cliente (un pico repentino de un cliente que anteriormente usaba OCSP es la confirmación secundaria de que se superó el umbral); y cero cambios inexplicables en el método de revocación (cualquier transición de OCSP a la validación basada en CRL en un sistema de producción debe ser rastreable a un cambio de configuración deliberado).

¿Qué aspectos deben auditarse o supervisarse periódicamente para la gestión del número mágico de OCSP?

Monitoreo continuo: volumen de consultas OCSP por cliente de alto volumen utilizando líneas base de tráfico de red, observando caídas sostenidas; volumen de descargas CRL por cliente como señal secundaria, con alertas para picos repentinos de clientes que previamente usaban OCSP; y estado del respondedor OCSP junto con tasas de consulta del lado del cliente, ya que un respondedor saludable con tasas de consulta decrecientes de clientes de alto volumen es un fuerte indicador de que se ha superado el umbral. Auditoría trimestral: verificar el valor del registro CryptnetCachedOcspSwitchToCrlCount en todos los controladores de dominio, servidores RADIUS y puertas de enlace VPN; volver a medir los volúmenes máximos de validación de certificados a medida que crece la flota; y confirmar que el registro de diagnóstico CAPI2 esté configurado en clientes representativos de alto volumen.

¿Cómo afecta el número mágico de OCSP a los entornos PKI en la nube, híbridos o con múltiples autoridades de certificación?

En entornos híbridos, el Número Mágico se aplica de forma independiente en cada cliente Windows, independientemente de dónde se aloje el respondedor OCSP o el punto de distribución de CRL. Los respondedores OCSP alojados en la nube no modifican el comportamiento de conteo. Lo que cambia es la consecuencia de la reserva: si el punto de distribución de CRL se aloja en las instalaciones y los clientes en la nube tienen una ruta de alta latencia o bloqueada, la reserva de OCSP a CRL produce tiempos de espera de descarga. En entornos con múltiples CA, donde un único Respondedor en línea presta servicio a varias CA emisoras, el conteo del Número Mágico se realiza de forma independiente para cada CA: superar el umbral para una CA no afecta al conteo para las demás.

¿Qué errores comunes deben evitar los equipos con el Número Mágico de OCSP?

Los errores más frecuentes son: desconocer la existencia del umbral hasta que se produce un fallo de revocación en producción; asumir que la infraestructura OCSP está rota porque los clientes dejaron de enviar consultas cuando el respondedor OCSP está en buen estado y simplemente se activó el número mágico; establecer el umbral a través del registro sin implementarlo mediante la directiva de grupo, lo que provoca que el valor sea inconsistente en todo el conjunto; establecer el umbral en 0 esperando deshabilitar la reserva cuando en realidad restaura el valor predeterminado de 50; y no medir los volúmenes máximos de validación de certificados antes de establecer el umbral.

¿Qué se debe actualizar trimestralmente para la gobernanza del número mágico de OCSP?

Trimestralmente: vuelva a medir los volúmenes máximos de validación de certificados en los controladores de dominio, servidores RADIUS y puertas de enlace VPN a medida que crece la flota; verifique que el valor de la directiva de grupo CryptnetCachedOcspSwitchToCrlCount se implemente de manera consistente en todos los sistemas afectados; revise los registros de consulta del respondedor OCSP para detectar caídas de volumen sostenidas de clientes de alto volumen no causadas por cambios de configuración deliberados; confirme que el registro de diagnóstico CAPI2 esté activo en los clientes representativos; y revise el tamaño de la CRL para todas las CA emisoras activas para confirmar que si se activa el Número Mágico y los clientes recurren a la CRL, la CRL se mantiene dentro del tamaño de descarga aceptable y la disponibilidad del punto de distribución. Para la alineación de la infraestructura de revocación con la planificación de la migración de certificados post-cuánticos, consulte la guía actual a través del Centro de Excelencia PQC.