Saltar al contenido principal
Español (México)

Automatización de la revocación de certificados con OCSP y CRL en un entorno NAC

Esta guía de referencia técnica proporciona a los directores de TI y arquitectos de red un análisis detallado de la automatización de la revocación de certificados en un entorno de Network Access Control (NAC). Explora las ventajas y desventajas arquitectónicas entre OCSP y CRL, ofrece una guía de implementación independiente del proveedor y describe el impacto empresarial de la aplicación de políticas en tiempo real.

📖 6 min de lectura📝 1,437 palabras🔧 2 ejemplos resueltos❓ 3 preguntas de práctica📚 8 definiciones clave

Escucha esta guía

Ver transcripción del podcast
Automatización de la revocación de certificados con OCSP y CRL en un entorno NAC Una sesión informativa técnica de Purple - Aproximadamente 10 minutos --- INTRODUCCIÓN Y CONTEXTO - aproximadamente 1 minuto Bienvenido a la serie de sesiones informativas técnicas de Purple. Soy su anfitrión, y hoy nos adentraremos en la mecánica de la automatización de la revocación de certificados; específicamente, cómo funcionan OCSP y CRL dentro de un entorno de Network Access Control y por qué hacer esto bien es una de las decisiones de seguridad más ignoradas en las implementaciones de WiFi empresariales. Si usted opera una cadena hotelera, un complejo minorista, un estadio o una red del sector público con cientos o miles de dispositivos conectados, la gestión del ciclo de vida de los certificados no es un lujo. Es la diferencia entre una red que aplica las políticas en tiempo real y otra que alberga silenciosamente credenciales revocadas de dispositivos que deberían haber sido desconectados hace semanas. Cubriremos la arquitectura técnica, analizaremos dos escenarios reales de implementación y terminaremos con las preguntas que su equipo debería hacerse antes de acercarse a un despliegue en producción. Comencemos. --- ANÁLISIS TÉCNICO DETALLADO - aproximadamente 5 minutos Primero, establezcamos el problema que estamos resolviendo. En cualquier red autenticada mediante IEEE 802.1X (el estándar que sustenta el WiFi empresarial, el NAC cableado y la mayoría de las arquitecturas modernas de acceso para invitados), los dispositivos se autentican mediante credenciales o certificados. Los certificados son preferibles porque no dependen de secretos compartidos, están vinculados al dispositivo y se integran limpiamente con las plataformas MDM a través de protocolos como SCEP. Pero los certificados tienen un ciclo de vida. Expiran, se ven comprometidos y los dispositivos se dan de baja. Cuando ocurre cualquiera de estas cosas, necesita un mecanismo para indicarle a su infraestructura de red: este certificado ya no es válido, deje de confiar en él. Ese mecanismo se presenta en dos variantes: CRL, que significa Lista de Revocación de Certificados, y OCSP, que significa Protocolo de Estado de Certificados en Línea. Comencemos con CRL. Una Lista de Revocación de Certificados es exactamente lo que parece: una lista firmada, publicada por su Autoridad de Certificación, de cada número de serie de certificado que ha sido revocado. Su infraestructura NAC (normalmente un servidor RADIUS como FreeRADIUS, Cisco ISE o Aruba ClearPass) descarga esta lista periódicamente desde un punto de distribución de CRL, que es simplemente un endpoint HTTP o LDAP. El servidor RADIUS almacena la lista localmente en caché y verifica los números de serie de los certificados entrantes con ella durante el protocolo de enlace EAP-TLS. La ventaja operativa de CRL es la simplicidad y la resiliencia sin conexión. Una vez descargada la lista, la verificación de la revocación funciona incluso si su CA no está disponible. La desventaja es la latencia. Si revoca un certificado a las 9:00 a. m. y su intervalo de actualización de CRL es de 24 horas, ese dispositivo aún podría autenticarse hasta la próxima descarga programada. En un entorno de alta seguridad (un hospital, una oficina administrativa de servicios financieros, una red gubernamental), esa ventana de tiempo es inaceptable. OCSP resuelve el problema de la latencia. En lugar de mantener una lista local en caché, su servidor RADIUS envía una consulta en tiempo real a un OCSP Responder - un servicio que se encuentra frente a su CA - para cada certificado que necesita validar. El responder devuelve una de tres respuestas: Good, Revoked o Unknown. Todo el intercambio ocurre en línea, durante el saludo de EAP-TLS, normalmente en menos de 100 milisegundos en una infraestructura bien aprovisionada. La desventaja de OCSP es la dependencia de la disponibilidad. Si su OCSP Responder se cae, o si su servidor RADIUS no puede comunicarse con él debido a una partición de red, debe tomar una decisión de política: ¿falla en abierto (permitiendo que continúe la autenticación) o falla en cerrado (denegando el acceso hasta que el responder esté accesible)? Fallar en abierto mantiene el tiempo de actividad pero crea una brecha de seguridad. Fallar en cerrado mantiene la postura de seguridad pero puede bloquear a usuarios legítimos durante un incidente de infraestructura. Existe una tercera opción que vale la pena conocer: OCSP Stapling. En este modelo, el titular del certificado (el dispositivo cliente) obtiene periódicamente una respuesta OCSP firmada del responder y la adjunta al saludo TLS. El servidor RADIUS valida la respuesta adjunta en lugar de realizar su propia consulta OCSP. Esto reduce la carga en el OCSP Responder, elimina la preocupación de privacidad de exponer los números de serie de los certificados a un servicio externo y mejora la resiliencia. La desventaja es que no todos los suplicantes EAP admiten stapling, por lo que debe verificar la compatibilidad del cliente antes de depender de ello. Ahora, ¿cómo encaja esto en una arquitectura NAC? Su motor de políticas NAC - ya sea Cisco ISE, Aruba ClearPass, Juniper Mist o una pila de código abierto basada en FreeRADIUS y PacketFence - se sitúa entre el suplicante y la red. Cuando un dispositivo intenta conectarse, el servidor RADIUS recibe el Access-Request, realiza la negociación EAP-TLS, valida la cadena de certificados del cliente, verifica el estado de revocación mediante OCSP o CRL y luego emite un Access-Accept con una asignación de VLAN o un Access-Reject. La parte de automatización interviene en dos niveles. Primero, en la capa de emisión de certificados: su plataforma MDM (Jamf, Intune, Workspace ONE) utiliza SCEP para aprovisionar automáticamente certificados a los dispositivos administrados. Cuando un dispositivo se desincribe o se retira del servicio, el MDM activa una llamada de revocación a la CA, la cual actualiza la CRL y notifica al OCSP Responder. Segundo, en la capa de aplicación de NAC: su servidor RADIUS está configurado para consultar OCSP o actualizar su caché de CRL según un programa definido, lo que garantiza que las decisiones de revocación se propaguen a la política de acceso sin intervención manual. El punto crítico de integración aquí es el canal de comunicación entre la CA y el NAC. En una implementación bien diseñada, la revocación es una cadena totalmente automatizada: el MDM retira el dispositivo, activa la revocación de la CA, la CA actualiza el respondedor OCSP y publica una nueva CRL, el servidor RADIUS detecta el cambio (ya sea de inmediato a través de OCSP o dentro de la siguiente ventana de actualización de la CRL) y al dispositivo se le niega el acceso en su siguiente intento de autentificación. --- RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aproximadamente 2 minutos Permítame ofrecerle la guía práctica que evita que las implementaciones fracasen. Primero: defina su tolerancia a la latencia de revocación antes de elegir su mecanismo. Si opera una red WiFi para invitados en un hotel donde el riesgo principal es un dispositivo del personal fuera de servicio, un intervalo de actualización de la CRL de 4 horas probablemente sea suficiente. Si opera una red de atención médica donde un dispositivo comprometido podría acceder a los datos de los pacientes, querrá OCSP con una política de fallo de seguridad (fail-closed) y un clúster de respondedores de alta disponibilidad. Segundo: no ejecute un único respondedor OCSP en producción. Implemente al menos dos, detrás de un balanceador de carga, con monitoreo de estado. Una interrupción del respondedor OCSP que cause un comportamiento de fallo de seguridad generará tickets de soporte más rápido que casi cualquier otra falla de infraestructura. Tercero: vigile el tamaño de su CRL. En implementaciones grandes (hablamos de decenas de miles de certificados), los archivos CRL pueden crecer a varios megabytes. Un servidor RADIUS que descarga una CRL de 5 MB cada hora a través de un enlace WAN es un problema de rendimiento de datos a punto de ocurrir. Considere utilizar CRL delta, que solo contienen los cambios desde la última CRL completa, o migre a OCSP para entornos de alto volumen. Cuarto: pruebe su canal de revocación con regularidad. No basta con configurar OCSP y asumir que funciona. Automatice una prueba mensual: emita un certificado, revóquelo, intente la autentificación y verifique el rechazo. Si su monitoreo no detecta un respondedor OCSP inactivo, su mecanismo de revocación es pura simulación. Quinto: alinee los periodos de validez de sus certificados con su estrategia de revocación. Los certificados de corta duración (de 24 a 72 horas) reducen la ventana de exposición de las credenciales comprometidas y pueden disminuir por completo su dependencia de la infraestructura de revocación. Esta es la dirección en la que se mueve la industria y vale la pena evaluarla para nuevas implementaciones. --- PREGUNTAS Y RESPUESTAS RÁPIDAS - aproximadamente 1 minuto Pregunta: ¿Puedo usar OCSP y CRL de forma simultánea? Sí. La mayoría de las implementaciones RADIUS admiten una cadena de respaldo: intentar OCSP primero y recurrir a CRL si el respondedor no está disponible. Esto le brinda verificación en tiempo real en condiciones normales y resiliencia sin conexión durante las interrupciones. Pregunta: ¿La plataforma de WiFi para invitados de Purple se integra con NAC basado en certificados? La plataforma de Purple funciona en la capa de acceso de invitados, gestionando la autenticación del captive portal, la captura de datos y la analítica. Para las redes del personal de la empresa que ejecutan 802.1X con autenticación mediante certificados, Purple se integra con la infraestructura de red subyacente - los puntos de acceso, controladores y servidores RADIUS - en lugar de reemplazar la pila de gestión de certificados. Las redes de invitados y del personal suelen estar segmentadas, con diferentes mecanismos de autenticación adecuados para cada una. Pregunta: ¿Cuál es el enfoque de cumplimiento? PCI-DSS 4.0 exige que el acceso a los entornos de datos de titulares de tarjetas utilice una autenticación sólida. El GDPR exige medidas técnicas adecuadas para proteger los datos personales. Ambos marcos se cumplen mediante 802.1X basado en certificados con revocación automatizada - siempre que pueda demostrar que la revocación es oportuna y ha sido probada. Su pista de auditoría debe mostrar cuándo se revocaron los certificados y cuándo se propagó esa revocación al control de acceso a la red. --- RESUMEN Y PRÓXIMOS PASOS - aproximadamente 1 minuto Para resumir: automatizar la revocación de certificados en un entorno de control de acceso a la red es un problema de tres capas. Necesita una CA que admita activadores de revocación automatizados, un respondedor OCSP o un punto de distribución de CRL que sea de alta disponibilidad y tenga el tamaño adecuado, y un servidor RADIUS configurado para aplicar el estado de revocación como parte de su política de acceso. La elección entre OCSP y CRL no es binaria - es una decisión de tolerancia al riesgo que debe tomarse en el contexto de los requisitos de seguridad, la topología de red y la madurez operativa de su entorno. Si está creando o revisando un despliegue de control de acceso a la red y desea comprender cómo encaja la plataforma de analítica y WiFi para invitados de Purple en la arquitectura de red más amplia, los enlaces en las notas del programa le llevarán a las guías técnicas correspondientes. Gracias por escuchar. Nos vemos en el próximo informe. --- FIN DEL GUION

header_image.png

Resumen Ejecutivo

Para los directores de TI empresariales y arquitectos de red que gestionan entornos de alta densidad - como complejos de hospitalidad , sucursales de retail y despliegues del sector público - la gestión del ciclo de vida de los certificados es una frontera de seguridad crítica. Aunque IEEE 802.1X proporciona una autenticación sólida para dispositivos corporativos y BYOD, el mecanismo para revocar la confianza a menudo se pasa por alto hasta que ocurre una brecha de seguridad.

La automatización de la revocación de certificados dentro de un entorno de Network Access Control (NAC) a través de Online Certificate Status Protocol (OCSP) y Listas de Revocación de Certificados (CRL) cierra la brecha entre la baja de un endpoint y la aplicación de políticas de red. Esta guía explora los mecanismos arquitectónicos de la revocación automatizada, comparando las capacidades en tiempo real de OCSP con la resiliencia offline de las CRL.

Al integrar plataformas de Mobile Device Management (MDM), Autoridades de Certificación (CAs) y motores de políticas NAC, las organizaciones pueden lograr un Acceso de Red Zero-Trust donde los dispositivos comprometidos o dados de baja son bloqueados de inmediato. Esta referencia técnica proporciona orientación de despliegue accionable, estrategias de mitigación de riesgos y explora cómo esta postura de seguridad orientada al personal complementa la infraestructura de cara al público, como las plataformas de Guest WiFi y WiFi Analytics de Purple.

Inmersión Técnica Profunda

En cualquier red empresarial que utilice IEEE 802.1X con EAP-TLS, los dispositivos se autentican mediante certificados digitales en lugar de credenciales compartidas. Este enfoque es fundamental para las arquitecturas de seguridad modernas, ya que proporciona identidades vinculadas al dispositivo y se integra a la perfección con las plataformas MDM a través de protocolos como SCEP (para más información, consulte The Role of SCEP and NAC in Modern MDM Infrastructure ). Sin embargo, los certificados tienen un ciclo de vida definido. Cuando se pierde un dispositivo, un empleado se marcha o una clave privada se ve comprometida, la infraestructura de red debe recibir instrucciones explícitas para dejar de confiar en ese certificado.

Esta instrucción de revocación se entrega a través de dos mecanismos principales: las CRL y OCSP.

Arquitectura de la Lista de Revocación de Certificados (CRL)

Una CRL es un archivo firmado digitalmente publicado por la Autoridad de Certificación que contiene los números de serie de todos los certificados que han sido revocados pero que aún no han expirado. El motor de políticas NAC (que actúa como servidor RADIUS) descarga periódicamente esta lista de un Punto de Distribución de CRL (CDP) a través de HTTP o LDAP.

Durante el saludo EAP-TLS, el servidor RADIUS verifica el número de serie del certificado del cliente entrante con su CRL almacenada localmente en caché. Si el número de serie está presente, se rechaza la autenticación.

Características Arquitectónicas:

  • Resiliencia sin Conexión: Dado que el servidor RADIUS almacena en caché la CRL, la verificación de revocación continúa incluso si la CA o el CDP no están disponibles.
  • Latencia: La principal desventaja es la latencia entre la revocación y la aplicación. Si un certificado se revoca a las 09:00 AM y el intervalo de actualización de la CRL es de 24 horas, el dispositivo comprometido mantiene el acceso a la red hasta la siguiente descarga.
  • Sobrecarga de Rendimiento: En entornos con miles de certificados, los archivos CRL pueden crecer hasta varios megabytes, lo que genera una gran demanda de ancho de banda durante los ciclos de actualización.

Arquitectura del Protocolo de Estado de Certificados en Línea (OCSP)

OCSP resuelve las limitaciones de latencia de CRL al permitir la verificación de revocación en tiempo real. En lugar de descargar la lista completa, el servidor RADIUS envía una consulta específica que contiene el número de serie del certificado a un respondedor OCSP. El respondedor devuelve un estado firmado: Good, Revoked, o Unknown.

Características de la Arquitectura:

  • Aplicación en Tiempo Real: Las decisiones de revocación surten efecto de manera instantánea. Una vez que la CA actualiza el respondedor OCSP, el siguiente intento de autenticación del dispositivo comprometido fallará.
  • Dependencia de Disponibilidad: El motor de políticas NAC depende de la alta disponibilidad del respondedor OCSP. Si el respondedor no está disponible, el administrador de la red debe definir una política de fallo: "fallo abierto" (autorizar el acceso, comprometiendo la seguridad) o "fallo cerrado" (denegar el acceso, comprometiendo la disponibilidad).
  • Engrapado OCSP (OCSP Stapling): Para mitigar los problemas de carga y privacidad, el engrapado OCSP permite que el dispositivo cliente obtenga la respuesta OCSP firmada y la adjunte al saludo TLS, aunque el soporte del suplicante puede variar.

ocsp_crl_architecture_overview.png

Integración con Plataformas de Invitados y Analytics

Mientras que OCSP y CRL gestionan los estrictos requisitos de seguridad del personal y los dispositivos corporativos, las redes abiertas al público requieren una arquitectura diferente. Para lugares públicos, integrar un NAC robusto para el personal con una plataforma pública dedicada como Purple garantiza una cobertura integral. La plataforma de Purple maneja la autenticación del Captive Portal, la aceptación de los términos de servicio y la captura de datos para el segmento público, mientras que la infraestructura de red subyacente (a menudo los mismos puntos de acceso físicos y switches) aplica 802.1X y OCSP para los SSID corporativos. Comprender el entorno de radio es crucial para ambos segmentos; consulte Wi Fi Frequencies: A Guide to Wi-Fi Frequencies in 2026 para la planificación del espectro.

Guía de Implementación

La implementación de la revocación automatizada de certificados requiere la coordinación entre los dominios PKI, MDM y NAC. Siga estos pasos de implementación independientes del proveedor para establecer un flujo de revocación resiliente.

Paso 1: Definir los Desencadenadores de Revocación

La automatización comienza en la capa de gestión de endpoints. Configure su plataforma MDM (por ejemplo, Microsoft Intune, Jamf Pro) para activar una llamada de API de revocación a su autoridad de certificación cuando se cumplan condiciones específicas:

  • Cuando un dispositivo se da de baja del MDM
  • Cuando un dispositivo se marca como no conforme
  • Cuando se deshabilita una cuenta de usuario en el servicio de directorio

Paso 2: Configurar la infraestructura de revocación

Para la implementación de CRL:

  1. Configure la CA para publicar la CRL en un CDP de alta disponibilidad (por ejemplo, un servidor web interno con balanceo de carga).
  2. Establezca el intervalo de publicación de la CRL según su tolerancia al riesgo (por ejemplo, cada 4 horas).
  3. Configure el servidor RADIUS para obtener la CRL a intervalos ligeramente más cortos que el intervalo de publicación para garantizar que la caché siempre esté actualizada.

Para la implementación de OCSP:

  1. Implemente al menos dos servidores de respuesta OCSP detrás de un balanceador de carga para garantizar la alta disponibilidad.
  2. Configure la CA para enviar las actualizaciones de revocación a los servidores de respuesta OCSP de inmediato.
  3. Configure el servidor RADIUS para consultar la IP virtual OCSP con balanceo de carga durante la autenticación EAP-TLS.

Paso 3: Establecer políticas de respaldo

No dependa de un solo mecanismo. Configure su servidor RADIUS para utilizar OCSP como la comprobación de revocación principal y recurrir a una CRL almacenada en caché localmente si el servidor de respuesta OCSP no está accesible. Esto proporciona una aplicación en tiempo real en condiciones normales y resiliencia sin conexión durante las interrupciones de la infraestructura.

Paso 4: Definir el comportamiento ante fallas

Si tanto el OCSP como la CRL en caché no están disponibles, el servidor RADIUS debe decidir cómo manejar la solicitud de autenticación.

  • Entornos de alta seguridad (por ejemplo, salud ): Configure "fallar cerrado". Deniegue el acceso para evitar que se conecten dispositivos potencialmente comprometidos.
  • Entornos estándar (por ejemplo, centros de transporte ): Configure "fallar abierto" con alertas. Permita el acceso para mantener la continuidad operativa, pero genere una alerta de alta prioridad para el SOC.

ocsp_vs_crl_comparison_chart.png

Buenas prácticas

  1. Implementar CRL delta: Si depende de las CRL en un entorno grande, implemente CRL delta. Estos archivos contienen únicamente los cambios de revocación desde que se publicó la última CRL base completa, lo que reduce significativamente el tamaño de la descarga y el consumo de ancho de banda.
  2. Monitorear la latencia de OCSP: Las consultas OCSP ocurren en línea durante el saludo EAP-TLS. Si el servidor de respuesta OCSP tarda 500 ms en responder, la autenticación se retrasa 500 ms. Monitoree la latencia del servidor de respuesta y escale horizontalmente si los tiempos de respuesta se degradan.
  3. Certificados de corta duración: Considere reducir los períodos de validez de los certificados (por ejemplo, de 1 año a 7 días) mediante la renovación automatizada de SCEP/EST. Los certificados de corta duración caducan rápidamente de forma natural, lo que reduce la dependencia de una infraestructura de revocación sólida.4. Alineación con una estrategia de red más amplia: Asegúrese de que su implementación de NAC esté alineada con su arquitectura de red de área amplia. Para obtener información sobre el diseño de WAN moderno, consulte SD WAN vs MPLS: The 2026 Enterprise Network Guide .

Resolución de problemas y mitigación de riesgos

El modo de fallo más común de la revocación automatizada es una interrupción en el canal de comunicación entre la CA y el NAC, lo que resulta en un evento de "cierre por fallo" que bloquea a los usuarios legítimos.

Riesgo: Interrupción del respondedor OCSP Mitigación: Implemente respondedores en un clúster activo-activo a través de múltiples dominios de fallo. Configure comprobaciones de estado exhaustivas en el equilibrador de carga para verificar no solo la disponibilidad del puerto TCP 80, sino también la capacidad del respondedor para consultar la base de datos de la CA.

Riesgo: Caché de CRL desactualizada Mitigación: Los servidores RADIUS pueden fallar al descargar la CRL más reciente debido a particiones de red o interrupciones de CDP. Implemente un monitoreo que emita alertas cuando la CRL almacenada localmente en caché sea más antigua que el intervalo de publicación definido.

Riesgo: Revocación incompleta de MDM Mitigación: Si el MDM no logra activar una llamada de revocación a la CA, el certificado seguirá siendo válido. Implemente un script de reconciliación que compare periódicamente la lista de dispositivos activos del MDM con la lista de certificados válidos de la CA y revoque automáticamente cualquier discrepancia.

ROI e impacto empresarial

La automatización de la revocación de certificados transforma la seguridad de un proceso reactivo y manual en un mecanismo de defensa proactivo y automatizado.

  • Mitigación de riesgos: Al eliminar la ventana de exposición entre el compromiso del dispositivo y el aislamiento de la red, las organizaciones reducen significativamente el riesgo de movimiento lateral y filtración de datos. Esto es fundamental para mantener el cumplimiento de marcos como PCI-DSS y GDPR.
  • Eficiencia operativa: La automatización del canal de revocación elimina la necesidad de que el personal de soporte técnico actualice manualmente las configuraciones de RADIUS o las bases de datos de la CA cuando los empleados se van, lo que ahorra cientos de horas anuales en las grandes empresas.
  • Estrategia de acceso unificado: Un entorno NAC sólido para dispositivos corporativos permite a los equipos de TI implementar con confianza servicios paralelos, como el WiFi para invitados basado en análisis de Purple o los servicios basados en la ubicación (consulte BLE Low Energy Explained for Enterprise ), con la certeza de que la infraestructura principal permanece segura.

Escuche nuestra sesión informativa técnica sobre este tema a continuación:

Definiciones clave

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

El estándar más seguro para la autenticación de red 802.1X, que requiere que tanto el cliente como el servidor presenten certificados digitales para demostrar su identidad.

Los equipos de TI implementan EAP-TLS para eliminar los riesgos asociados con la autenticación basada en contraseñas, garantizando que solo los dispositivos gestionados que cuenten con un certificado puedan conectarse a la red corporativa.

OCSP (Online Certificate Status Protocol)

Un protocolo de internet utilizado para obtener el estado de revocación de un certificado digital X.509 en tiempo real.

Crucial para entornos que requieren la aplicación inmediata de políticas de acceso, como cuando se rescinde el contrato de un empleado y su dispositivo debe desconectarse instantáneamente.

CRL (Lista de Revocación de Certificados)

Una lista publicada periódicamente y firmada digitalmente de números de serie de certificados que han sido revocados por la Autoridad de Certificación emisora.

Se utiliza como un mecanismo de revocación principal en redes locales o desconectadas, o como una alternativa de alta resiliencia para OCSP.

Grampado OCSP (OCSP Stapling)

Un mecanismo mediante el cual el dispositivo cliente obtiene su propia respuesta OCSP y la "grampa" al saludo TLS, presentándola al servidor RADIUS.

Reduce la carga en el servidor RADIUS y en el Respondedor OCSP, y mejora la privacidad al evitar que la CA vea exactamente cuándo y dónde se está autenticando un dispositivo.

CRL Delta

Una lista de revocación más pequeña que contiene solo los certificados revocados desde que se publicó la última CRL Base completa.

Esencial para despliegues grandes para evitar la congestión de la red, ya que las CRL completas pueden volverse masivas y consumir un ancho de banda considerable durante los ciclos de actualización.

CDP (Punto de Distribución de CRL)

La ubicación, normalmente una URL HTTP o LDAP, donde la Autoridad de Certificación publica la CRL para que los clientes y los servidores RADIUS la descarguen.

Los equipos de TI deben asegurarse de que el CDP esté altamente disponible y sea accesible desde todos los motores de políticas de control de acceso a la red (NAC); si el CDP se cae, los servidores RADIUS no podrán actualizar sus cachés.

Fallo Abierto / Fallo Cerrado (Fail Open / Fail Closed)

La decisión de política que determina qué sucede cuando la infraestructura de revocación (OCSP o CDP) no está disponible. Fallo Abierto permite el acceso; Fallo Cerrado deniega el acceso.

Una decisión comercial crítica que equilibra la postura de seguridad con el tiempo de actividad operativa. Requiere la aprobación tanto de operaciones de TI como del CISO.

SCEP (Protocolo de Inscripción de Certificados Simple)

Un protocolo utilizado por las plataformas MDM para automatizar la emisión de certificados digitales a dispositivos gestionados sin la intervención del usuario.

El punto de partida del ciclo de vida automatizado. SCEP emite el certificado y el MDM activa posteriormente a la CA para revocarlo cuando el dispositivo se retira.

Ejemplos resueltos

¿Cómo debe diseñarse la arquitectura de revocación para una red de un hospital de 500 camas que está migrando de un esquema de 802.1X basado en credenciales a uno basado en certificados EAP-TLS para todos los dispositivos médicos de IoT y laptops del personal? El CISO exige que si se reporta el robo de un dispositivo, su acceso a la red debe cancelarse en un plazo de 5 minutos. Al equipo de red le preocupa la carga del servidor RADIUS si tiene que consultar constantemente servicios externos.

El hospital debe implementar OCSP para cumplir con el SLA de revocación de 5 minutos, ya que los intervalos de actualización de CRL no pueden cumplir con este objetivo de manera confiable sin causar una sobrecarga grave en la red. Para abordar las preocupaciones de carga del equipo de red, la arquitectura debe implementar OCSP Responders de forma local dentro del centro de datos del hospital, ubicados cerca de los servidores RADIUS para minimizar la latencia. Los servidores RADIUS deben configurarse para consultar la IP virtual (VIP) local de OCSP. Para garantizar la resiliencia, los servidores RADIUS deben configurarse con una alternativa de respaldo (fallback) a una CRL almacenada localmente en caché, la cual se actualizará cada hora. La política de fallas debe establecerse en "fail closed" debido a los estrictos requisitos de cumplimiento del entorno de atención médica.

Comentario del examinador: Este enfoque equilibra correctamente el estricto requisito de seguridad (SLA de 5 minutos) con la estabilidad operativa. Al localizar los OCSP Responders, el diseño mitiga la latencia y la dependencia de la WAN. La inclusión de un respaldo a CRL demuestra una comprensión madura del diseño de alta disponibilidad, garantizando que una interrupción temporal de OCSP no active de inmediato la política "fail closed" ni afecte las operaciones clínicas.

Una cadena minorista global con 1,200 tiendas utiliza SCEP para aprovisionar certificados en tablets de punto de venta (POS). Las tiendas tienen un ancho de banda de WAN limitado. El director de TI desea implementar la revocación de certificados, pero teme que la descarga de archivos CRL de gran tamaño en 1,200 servidores RADIUS de las sucursales sature los enlaces WAN. ¿Cuál es la estrategia de implementación óptima?

La cadena minorista debe implementar un enfoque híbrido que utilice Delta CRLs y OCSP Stapling. En primer lugar, la CA debe configurarse para publicar una CRL base semanalmente y una Delta CRL (que contenga únicamente las revocaciones recientes) cada 4 horas. Los servidores RADIUS de las sucursales solo descargarán las pequeñas Delta CRLs durante el día, minimizando el impacto en la WAN. Alternativamente, si los suplicantes EAP de las tablets POS lo admiten, se debe habilitar OCSP Stapling. Esto traslada la carga de obtener la respuesta OCSP desde el servidor RADIUS de la sucursal a la propia tablet, la cual puede obtener la respuesta directamente de la CA central a través de HTTPS estándar, evitando por completo la sobrecarga de procesamiento del servidor RADIUS.

Comentario del examinador: Esta solución aborda eficazmente la limitación específica: el ancho de banda de la WAN en el extremo de la red. Recomendar Delta CRLs es la práctica estándar de la industria para este escenario. La recomendación secundaria de OCSP Stapling muestra un conocimiento avanzado de la mecánica de EAP-TLS, aunque la advertencia sobre la compatibilidad del suplicante es crucial, ya que muchos dispositivos IoT o POS heredados no admiten el grapado.

Preguntas de práctica

Q1. ¿Su organización está implementando 802.1X en 50 sucursales remotas. Los enlaces WAN al centro de datos central están altamente congestionados y con frecuencia pierden paquetes. Necesita implementar la revocación de certificados para las laptops corporativas de las sucursales. ¿Qué arquitectura debería elegir?

Sugerencia: Considere el impacto de la pérdida de paquetes en los protocolos en tiempo real frente a la resiliencia de los datos almacenados en caché.

Ver respuesta modelo

Debería implementar una arquitectura basada en CRL, específicamente utilizando CRLs Base y Delta. Debido a que los enlaces WAN están congestionados y no son confiables, las consultas OCSP en tiempo real fallarán con frecuencia por tiempo de espera, lo que provocará retrasos o fallas en la autenticación. Al configurar los servidores RADIUS de las sucursales para que descarguen y almacenen en caché las CRL Delta durante las horas de menor actividad, el servidor RADIUS local puede realizar verificaciones de revocación de forma instantánea contra su caché, incluso si el enlace WAN se cae por completo durante el intento de autenticación.

Q2. Una auditoría de seguridad revela que cuando su Respondedor OCSP principal queda fuera de línea por mantenimiento, todos los usuarios corporativos se quedan completamente sin acceso a la red WiFi. La empresa exige que el mantenimiento no afecte la conectividad de los usuarios, pero el CISO se niega a cambiar la política a "Fallo Abierto". ¿Cómo resuelve esto?

Sugerencia: Si no puede cambiar la política de fallas, debe cambiar la disponibilidad del servicio.

Ver respuesta modelo

Debe implementar alta disponibilidad para el servicio OCSP. Despliegue al menos un Respondedor OCSP adicional y coloque ambos detrás de un balanceador de carga. Configure el servidor RADIUS para realizar consultas a la IP Virtual (VIP) del balanceador de carga. Durante el mantenimiento, puede drenar las conexiones del respondedor principal, ponerlo fuera de línea, y el balanceador de carga dirigirá sin problemas todas las consultas OCSP al respondedor secundario, cumpliendo tanto con el requisito de tiempo de actividad de la empresa como con el mandato de "Fallo Cerrado" del CISO.

Q3. Ha configurado su MDM para revocar automáticamente los certificados cuando un dispositivo se marca como "perdido". Prueba el sistema marcando un iPad de prueba como perdido. El MDM confirma la revocación, pero 10 minutos después, el iPad se conecta con éxito a la red WiFi corporativa. El servidor RADIUS está configurado para utilizar una CRL que se publica cada 24 horas. ¿Cuál es la causa raíz y cómo lo soluciona?

Sugerencia: Siga la línea de tiempo de los datos de revocación desde la CA hasta el motor de aplicación del servidor RADIUS.

Ver respuesta modelo

La causa raíz es la latencia en el ciclo de publicación y actualización de la CRL. Aunque el MDM le indicó con éxito a la CA que revocara el certificado, la CA no publicará ese estado actualizado en el punto de distribución de la CRL hasta el próximo ciclo de 24 horas, y el servidor RADIUS no lo descargará hasta que su propia caché expire. Para solucionarlo, debe migrar a OCSP para una verificación en tiempo real, o reducir drásticamente los intervalos de publicación y descarga de la CRL (por ejemplo, a 1 hora) para cumplir con el tiempo de respuesta requerido.

Continúe leyendo esta serie

WiFi para personal vs. WiFi para invitados: mejores prácticas para la segmentación de redes corporativas

Una guía técnica completa para líderes de TI sobre la segmentación de redes WiFi para personal e invitados. Cubre la arquitectura VLAN, la autenticación 802.1X, las políticas de firewall y el impacto empresarial del diseño de redes seguras.

Leer la guía →

Soluciones de WiFi para departamentos: una guía completa para empresas

Esta guía cubre la arquitectura, la implementación y el caso de negocio de las soluciones de WiFi para departamentos en propiedades Build to Rent (BTR) y unidades multi-residenciales (MDU). Explica cómo la tecnología Identity Pre-Shared Key (iPSK) crea burbujas de red seguras y aisladas para cada residente, al tiempo que admite dispositivos inteligentes e IoT. Los desarrolladores inmobiliarios, arrendadores y operadores de BTR encontrarán orientación práctica para la implementación, datos de ROI y escenarios de implementación resueltos.

Leer la guía →

Cox business managed WiFi: una guía completa para empresas

Esta guía detalla cómo los desarrolladores inmobiliarios y operadores de BTR pueden implementar redes escalables y seguras utilizando Cox Business managed WiFi. Cubre la arquitectura de red, la implementación de hardware independiente del proveedor y el impacto comercial de transformar la conectividad de un dolor de cabeza operativo a una infraestructura confiable.

Leer la guía →