Conceptos fundamentales de PKI para administradores de WiFi: Certificados, AC y cadenas de confianza
Esta guía de referencia técnica explica los conceptos fundamentales de la Infraestructura de Clave Pública (PKI) para los administradores de WiFi empresarial, abarcando autoridades de certificación, cadenas de confianza y certificados X.509. Detalla cómo la PKI sustenta la autenticación mutua EAP-TLS y proporciona orientación de implementación práctica para equipos de TI en entornos de hotelería, comercio minorista y sector público. Comprender PKI es un requisito previo obligatorio para implementar la autenticación de WiFi para el personal basada en certificados con Purple.
Escucha esta guía
Ver transcripción del podcast
Resumen Ejecutivo
Para los administradores de TI, arquitectos de red y directores de operaciones de recintos, proteger las redes WiFi corporativas y del personal es un requisito operativo y de cumplimiento crítico. Los métodos de autenticación heredados, como las claves precompartidas (PSK) o el filtrado de direcciones MAC, son insuficientes para los entornos empresariales modernos, lo que deja a las redes vulnerables al robo de credenciales y a la suplantación de identidad de dispositivos. Para lograr una seguridad sólida y auditable, las organizaciones deben realizar la transición a la autenticación basada en certificados, específicamente EAP-TLS (Extensible Authentication Protocol-Transport Layer Security).
La implementación de EAP-TLS requiere una comprensión sólida de la Infraestructura de Clave Pública (PKI). Esta guía desmitifica la PKI para los administradores de WiFi, explicando las funciones de las Autoridades de Certificación (CA), la mecánica de la cadena de confianza y las diferencias prácticas entre los certificados de servidor y de cliente. Al dominar estos aspectos fundamentales, los equipos de TI pueden diseñar e implementar con confianza soluciones de acceso a la red seguras y escalables en sectores como Hotelería , Retail y recintos del sector público, garantizando el cumplimiento de estándares como PCI DSS y GDPR, al tiempo que proporcionan una conectividad fluida y sin contraseñas para los dispositivos gestionados. Comprender la PKI es también el prerrequisito fundamental para implementar la autenticación WiFi del personal basada en certificados con Purple.
Análisis Técnico Detallado
La Arquitectura de la Confianza: ¿Qué es la Infraestructura de Clave Pública?
La Infraestructura de Clave Pública (PKI) es un marco criptográfico que permite la comunicación segura y la autenticación mutua a través de una red no confiable. En el contexto del WiFi empresarial, la PKI actúa como un sistema de pasaporte digital, verificando la identidad tanto del dispositivo cliente (el suplicante) como del servidor de autenticación de red (el servidor RADIUS) antes de que se intercambie cualquier dato.
Este sistema se basa en certificados X.509, que vinculan una clave pública a una identidad verificada (como el nombre de host de un servidor o la dirección de correo electrónico de un usuario) y están firmados digitalmente por un tercero de confianza conocido como Autoridad de Certificación (CA). La firma de la CA es la garantía criptográfica de que la afirmación de identidad es legítima.
La Jerarquía de Certificados y la Cadena de Confianza
La fortaleza de la PKI radica en su estructura jerárquica, conocida como la cadena de confianza. Esta jerarquía garantiza que cualquier certificado presentado por un dispositivo o servidor pueda rastrearse criptográficamente hasta una fuente de confianza universal. Los tres niveles son los siguientes.
Autoridad de Certificación Raíz (Root CA): La Root CA es la clave criptográfica de todo el ecosistema de PKI. Emite un certificado autofirmado y es inherentemente confiable para los dispositivos de los clientes y los servidores. En un despliegue empresarial seguro, la Root CA se mantiene fuera de línea (offline) y aislada físicamente para proteger su clave privada contra vulneraciones basadas en la red. Su único propósito operativo es firmar los certificados de las autoridades de certificación intermedias.
Autoridad de Certificación Intermedia (Intermediate CA): La Intermediate CA actúa como un amortiguador entre la altamente segura Root CA y el entorno operativo. Está en línea (online) y se encarga de la emisión y revocación diaria de los certificados de hoja (leaf certificates). Esta separación es una estrategia crítica de mitigación de riesgos: si una Intermediate CA se ve comprometida, la Root CA puede revocarla sin invalidar toda la infraestructura de PKI o requerir que se vuelvan a configurar todos los dispositivos de los clientes.
Certificados de Hoja (End-Entity Certificates): Estos son los certificados instalados en los servidores individuales y dispositivos de los clientes. Se encuentran en la parte inferior de la cadena de confianza y no pueden firmar otros certificados. Existen dos tipos principales relevantes para la implementación de WiFi. El Certificado de Servidor se instala en el servidor RADIUS, lo que permite a los dispositivos de los clientes verificar que se están conectando a la red corporativa legítima. El Certificado de Cliente se instala en las laptops del personal, dispositivos móviles o terminales de punto de venta, permitiendo que el servidor RADIUS verifique la identidad de cada dispositivo o usuario específico.
Cómo la PKI sustenta la autenticación EAP-TLS
EAP-TLS es el estándar de oro para la autenticación WiFi segura porque exige una autenticación mutua basada en certificados. Esto significa que tanto el dispositivo del cliente como el servidor RADIUS deben demostrar su identidad mutuamente utilizando certificados validados contra la cadena de confianza de la PKI, eliminando los riesgos inherentes a los enfoques basados en contraseñas.
Durante el saludo (handshake) EAP-TLS, que opera dentro del marco de trabajo IEEE 802.1X, el servidor RADIUS presenta primero su Certificado de Servidor al dispositivo del cliente. El dispositivo valida la firma del certificado contra su almacén confiable de la Root CA. Si es válido, el dispositivo tiene una prueba criptográfica de que se está conectando a la red corporativa legítima, y no a un punto de acceso no autorizado o un "evil twin" (punto de acceso gemelo malicioso). Luego, el dispositivo del cliente presenta su propio Certificado de Cliente al servidor RADIUS, el cual lo valida contra la CA. Una vez que ambas partes se han autenticado, se establece un túnel TLS seguro y se otorga el acceso a la red. No se transmiten contraseñas y no existen secretos compartidos que puedan ser robados.
This architecture is also the foundation of WPA3-Enterprise, which mandates 192-bit security mode and relies on the same PKI and 802.1X underpinnings. For organisations deploying Wireless Access Points in high-security environments, WPA3-Enterprise with EAP-TLS represents the current best practice.
Public CA vs. Private CA: The Deployment Decision
One of the most consequential architectural decisions in a PKI deployment is the choice between a Public CA and a Private CA. The table below summarises the trade-offs.
| Criterion | Public CA | Private CA |
|---|---|---|
| Cost | Per-certificate fee (viable for a small number of servers) | Infrastructure cost, but no per-certificate fee at scale |
| Device Trust | Trusted by default on most OSes and devices | Requires Root CA to be pushed to all devices via MDM |
| Control | Limited; CA controls issuance policies | Full control over issuance, revocation, and lifecycle |
| Best Use Case | RADIUS Server Certificate | Client Certificates for managed corporate devices |
| Compliance | Auditable via public CT logs | Requires internal audit processes |
The recommended approach for most enterprise WiFi deployments is a hybrid model: use a Public CA for the RADIUS Server Certificate to ensure broad compatibility, and deploy a Private CA (such as Microsoft Active Directory Certificate Services or a cloud-based PKI provider) for issuing Client Certificates to managed devices at scale.
Implementation Guide
Step 1: Design the CA Architecture
Begin by mapping your certificate requirements. Identify the number of managed devices, the operating systems in use, and the MDM platform available. Determine whether a two-tier (Root CA + Intermediate CA) or three-tier hierarchy is appropriate for your organisation's scale and risk profile.
Step 2: Deploy and Secure the Root and Intermediate CAs
Establish the offline Root CA on a dedicated, air-gapped machine. Use the Root CA to sign the Intermediate CA certificate. Ensure the Intermediate CA is securely deployed in your data centre or cloud environment and integrated with your identity provider (IdP) or MDM solution. Store the Root CA private key in a Hardware Security Module (HSM) where budget permits.
Step 3: Configure the RADIUS Server
Install the Server Certificate on your RADIUS server. Configure the server to require EAP-TLS for the secure corporate SSID. Ensure the RADIUS server trusts the Intermediate CA that issued the Client Certificates, and configure it to perform revocation checking via OCSP.
Step 4: Distribute Certificates via MDM
Never attempt manual certificate installation at scale. Use an MDM platform such as Microsoft Intune or Jamf to push the Root CA certificate, the Intermediate CA certificate, and unique Client Certificates to all managed devices via automated policy. This ensures consistent deployment and enables automated renewal.
Paso 5: Implementar y probar mecanismos de revocación
Configure las Listas de Revocación de Certificados (CRL) o el Protocolo de Estado de Certificados en Línea (OCSP). Pruebe el flujo de trabajo de revocación de extremo a extremo revocando un certificado de prueba y confirmando que el servidor RADIUS deniegue el acceso dentro del plazo esperado. Para entornos que requieren una revocación casi instantánea — como las redes POS de Retail — el uso de OCSP es obligatorio.
Paso 6: Monitorear y automatizar la gestión del ciclo de vida
Implemente un monitoreo automatizado para la expiración de certificados en todos los niveles de la jerarquía. Configure alertas a los 90, 60 y 30 días antes de la expiración. Automatice la renovación a los 60 días. Este es el paso operativo más impactante para prevenir interrupciones en la red.
Mejores prácticas
Hacer obligatoria la autenticación mutua sin excepción: Asegúrese de que los dispositivos cliente estén configurados para validar estrictamente el certificado del servidor RADIUS. Deshabilitar la validación del certificado del servidor — un atajo común durante la implementación inicial — deja a los dispositivos vulnerables a ataques de intermediario (man-in-the-middle) y al robo de credenciales, además de violar los requisitos de PCI DSS.
Segregar las redes por método de autenticación: Utilice EAP-TLS para dispositivos corporativos y del personal en un SSID dedicado. Para el acceso de visitantes públicos, implemente una solución robusta de Captive Portal como Guest WiFi en una red completamente segregada. No intente implementar PKI en dispositivos de invitados no administrados.
Auditar la infraestructura de PKI regularmente: Realice auditorías trimestrales de los controles de acceso a la CA, las listas de revocación y los registros de emisión de certificados. En entornos de Healthcare y Retail , este es un requisito de cumplimiento bajo HIPAA y PCI DSS respectivamente.
Integrar con analíticas de red: Una vez que la autenticación segura esté en su lugar, agregue WiFi Analytics para obtener visibilidad sobre el comportamiento de los dispositivos, los patrones de conexión y las posibles anomalías. Una red segura es la base para obtener datos confiables.
Considerar la integración con SD-WAN: Para implementaciones en múltiples sitios a través de cadenas hoteleras o complejos de retail, la PKI se integra de forma natural con las arquitecturas SD-WAN. Para obtener contexto sobre cómo se complementan estas tecnologías, consulte The Core SD-WAN Benefits for Modern Businesses .
Resolución de problemas y mitigación de riesgos
La siguiente tabla asocia los modos de falla comunes con sus causas raíz y las mitigaciones recomendadas.
| Síntoma | Causa raíz | Mitigación |
|---|---|---|
| Los dispositivos no pueden conectarse; los registros de RADIUS muestran 'CA desconocida' | El dispositivo cliente no confía en la CA que emitió el certificado del servidor RADIUS | Distribuya la CA raíz a todos los dispositivos a través de MDM |
| Interrupción repentina en toda la red para todos los dispositivos corporativos | El certificado del servidor RADIUS o el certificado de la CA intermedia ha expirado | Implemente monitoreo y renovación automatizados; alertas a los 90/60/30 días |
| Una laptop robada aún puede acceder a la red | La CRL está desactualizada o OCSP no está configurado | Cambie a OCSP para la verificación de revocación en tiempo real |
| New devices cannot connect after MDM enrolment | Client Certificate not yet pushed by MDM policy | Verify MDM policy assignment and force a device sync |
| Intermittent authentication failures | Clock skew between client and RADIUS server | Ensure all devices use NTP time synchronisation |
Para una comprensión más profunda de la configuración y resolución de problemas de 802.1X, la guía 802.1X Authentication: Securing Network Access on Modern Devices proporciona una guía de configuración detallada e independiente del proveedor.
ROI e Impacto Comercial
La transición a una arquitectura EAP-TLS respaldada por PKI ofrece un valor comercial medible para los operadores de recintos en múltiples dimensiones.
Mitigación de Riesgos y Cumplimiento: Eliminar la autenticación basada en contraseñas remueve el vector de ataque más común para el compromiso de la red. Esto reduce directamente la probabilidad de costosas filtraciones de datos y simplifica el cumplimiento de PCI DSS (requerido para el procesamiento de pagos), GDPR (para la protección de datos) y las regulaciones específicas del sector. Para los recintos que implementan Sensors de IoT o sistemas de Wayfinding basados en la ubicación, una red protegida criptográficamente es un requisito previo para la integridad de los datos confiables.
Eficiencia Operativa: Automatizar la implementación de certificados a través de MDM elimina la carga operativa de la gestión de contraseñas, reduciendo los tickets de soporte de TI relacionados con la conectividad WiFi. En entornos de alta rotación, como hoteles y comercios minoristas, donde el alta y baja de personal es frecuente, la emisión y revocación automatizada de certificados proporciona un ahorro de tiempo significativo en comparación con la gestión de credenciales compartidas.
Base para Servicios Avanzados: Una red corporativa segura y autenticada es la base confiable sobre la cual se construyen los servicios operativos avanzados. Ya sea que se implemente WiFi Analytics para inteligencia de tráfico de personas, Sensors para datos de ocupación en tiempo real o Wayfinding para grandes recintos, cada una de estas capacidades se beneficia de las garantías de integridad que proporciona PKI.
Para los operadores de Hospitality en específico, la combinación de una red de personal segura y un portal de invitados bien diseñado — como se explora en Modern Hospitality WiFi Solutions Your Guests Deserve — representa la arquitectura de WiFi empresarial completa. Para los centros de Transport y grandes recintos públicos, se aplican los mismos principios a escala.
Definiciones clave
Infraestructura de clave pública (PKI)
Un marco de funciones, políticas, hardware, software y procedimientos necesarios para crear, administrar, distribuir, usar, almacenar y revocar certificados digitales y administrar el cifrado de clave pública.
La arquitectura fundamental que debe estar instalada antes de que un equipo de TI pueda implementar la autenticación WiFi segura basada en certificados utilizando EAP-TLS.
Autoridad de Certificación (CA)
Una entidad de confianza que emite certificados digitales, verificando la identidad del sujeto del certificado y vinculando esa identidad a una clave pública con una firma criptográfica.
La autoridad central en su red que actúa como la fuente de verdad para todas las identidades de dispositivos y servidores. Sin una CA de confianza, no es posible la autenticación basada en certificados.
Certificado X.509
El formato estándar para certificados de clave pública, definido en RFC 5280. Contiene la identidad del sujeto, la clave pública, la identidad del emisor, el período de validez y la firma digital de la CA.
El pasaporte digital real instalado en una computadora portátil o servidor que prueba su identidad durante el saludo de EAP-TLS.
EAP-TLS (Protocolo de Autenticación Extensible-Seguridad de la Capa de Transporte)
Un método de autenticación 802.1X que requiere autenticación mutua basada en certificados entre el dispositivo cliente (suplicante) y el servidor de autenticación (RADIUS). Definido en RFC 5216.
El método más seguro para autenticar dispositivos corporativos en una red WiFi. Elimina la necesidad de contraseñas y proporciona una prueba criptográfica de identidad para ambas partes.
Cadena de confianza
Una secuencia jerárquica de certificados utilizada para autenticar una entidad, comenzando desde el certificado de hoja y rastreando hacia arriba a través de la CA intermedia hasta la CA raíz.
El mecanismo mediante el cual una computadora portátil verifica que el certificado de un servidor RADIUS es legítimo. Cada enlace de la cadena se valida hasta que se alcanza una CA raíz de confianza.
Lista de revocación de certificados (CRL)
Una lista publicada periódicamente de certificados digitales que han sido revocados por la CA emisora antes de su fecha de vencimiento programada y en los que ya no se debe confiar.
Un mecanismo para bloquear el acceso de dispositivos perdidos o robados. Las CRL se almacenan en caché y se actualizan de forma programada, lo que significa que la revocación puede no ser inmediata, una limitación que aborda OCSP.
Protocolo de estado de certificado en línea (OCSP)
Un protocolo de internet (RFC 6960) utilizado para obtener el estado de revocación en tiempo real de un certificado digital X.509 mediante la consulta al respondedor OCSP de la CA.
El mecanismo de revocación preferido para entornos de alta seguridad. Permite al servidor RADIUS verificar la validez del certificado en tiempo real durante cada intento de autenticación, lo que proporciona una aplicación de revocación casi instantánea.
RADIUS (Servicio de usuario de marcación de autenticación remota)
Un protocolo de red que proporciona una gestión centralizada de autenticación, autorización y contabilidad (AAA) para usuarios y dispositivos que se conectan a una red.
El servidor central en una implementación WiFi empresarial que valida certificados y toma la decisión final de control de acceso. El servidor RADIUS es el núcleo operativo de una implementación EAP-TLS.
IEEE 802.1X
Un estándar IEEE para el control de acceso a redes basado en puertos (PNAC) que proporciona un mecanismo de autenticación para los dispositivos que desean conectarse a una LAN o WLAN.
El marco general dentro del cual opera EAP-TLS. Comprender 802.1X es esencial para configurar puntos de acceso y switches para aplicar la autenticación basada en certificados.
Gestión de dispositivos móviles (MDM)
Una plataforma de software utilizada por los administradores de TI para gestionar, configurar y proteger de forma remota dispositivos móviles y computadoras portátiles en toda una organización.
La herramienta operativa esencial para implementar certificados a escala. Las plataformas MDM como Microsoft Intune y Jamf automatizan la distribución de certificados de CA raíz, certificados de CA intermedia y certificados de cliente a todos los dispositivos gestionados.
Ejemplos resueltos
Un hotel de lujo de 500 habitaciones en Londres necesita asegurar su red WiFi para el personal, específicamente para las tabletas de limpieza y las terminales de punto de venta (POS). Actualmente, utilizan una única Clave Precompartida (PSK) que no se ha rotado en tres años y que es conocida por todo el personal de planta y de agencia. El Director de TI tiene la tarea de realizar la transición a una arquitectura basada en certificados antes de la próxima auditoría de PCI DSS. ¿Cómo se debe abordar esto?
Fase 1 — Diseño de Arquitectura: Implementar una PKI privada basada en la nube (por ejemplo, Microsoft NDES a través de Intune, o un proveedor de PKI en la nube dedicado) integrada con la plataforma MDM del hotel. Obtener un Certificado de Servidor RADIUS de una CA pública como DigiCert.
Fase 2 — Implementación de Infraestructura: Configurar el servidor RADIUS con el nuevo Certificado de Servidor y habilitar EAP-TLS en un nuevo SSID oculto designado para los dispositivos del personal. Configurar OCSP para la verificación de revocación en tiempo real.
Fase 3 — Registro de Dispositivos: Utilizar la plataforma MDM para enviar la CA Raíz Privada, la CA Intermedia y Certificados de Cliente únicos a todas las tabletas de limpieza y terminales POS. Verificar la instalación exitosa del certificado en un grupo piloto de 20 dispositivos antes del despliegue completo.
Fase 4 — Migración y Desmantelamiento: Migrar todos los dispositivos al nuevo SSID EAP-TLS a través de la política de MDM. Confirmar la conectividad en todos los tipos de dispositivos. Después de un período de funcionamiento en paralelo de dos semanas, desmantelar la red PSK heredada.
Fase 5 — Entrega Operativa: Documentar el ciclo de vida del certificado, los procedimientos de revocación y las políticas de MDM. Configurar alertas automáticas de vencimiento y programar auditorías trimestrales de PKI.
Una cadena minorista nacional está implementando EAP-TLS en 200 tiendas. Durante las pruebas piloto en cinco tiendas, el equipo de TI descubre que cuando se reporta el robo de la laptop de un gerente de tienda y se revoca el certificado en el sistema PKI, el dispositivo aún puede autenticarse con éxito en la red WiFi corporativa hasta 18 horas después de la revocación. El equipo de seguridad considera que este es un riesgo inaceptable dado que el dispositivo puede tener acceso a los sistemas de gestión de inventario. ¿Cómo se debe resolver esto?
El retraso de 18 horas es causado por el hecho de que el servidor RADIUS depende de una Lista de Revocación de Certificados (CRL) almacenada en caché que se descarga con poca frecuencia. Las CRL se publican normalmente de forma programada (por ejemplo, cada 24 horas) y el servidor RADIUS las almacena en caché, lo que significa que la revocación no se refleja en tiempo real.
La resolución consiste en reconfigurar el servidor RADIUS para que utilice el Protocolo de Estado de Certificados en Línea (OCSP) como el mecanismo principal de verificación de revocación. OCSP permite que el servidor RADIUS consulte al respondedor OCSP de la CA en tiempo real durante cada protocolo de enlace (handshake) EAP-TLS, recibiendo una respuesta inmediata de 'bueno', 'revocado' o 'desconocido' para el certificado específico que se presenta.
Pasos de configuración: (1) Asegurarse de que la CA Privada esté configurada con un punto de conexión de respondedor OCSP. (2) Actualizar la configuración del servidor RADIUS para consultar el punto de conexión OCSP en cada intento de autenticación. (3) Configurar el grapado (stapling) OCSP donde sea compatible para reducir la latencia. (4) Probar revocando un certificado y confirmando que el servidor RADIUS deniegue el acceso en un plazo de 60 segundos.
Preguntas de práctica
Q1. Su organización está migrando de PEAP-MSCHAPv2 (usuario y contraseña) a EAP-TLS para la WiFi corporativa. El equipo de red propone utilizar la infraestructura existente de Active Directory Certificate Services (AD CS) para emitir certificados tanto a los servidores RADIUS como a todas las laptops corporativas. Un miembro del equipo señala que la organización también cuenta con 50 laptops de contratistas que no están unidas al dominio. ¿Cuál es el principal riesgo de compatibilidad y cómo debería abordarse?
Sugerencia: Considere cómo los dispositivos que no están unidos al dominio validarán la identidad del servidor RADIUS cuando este presente un certificado firmado por su Private AD CS Root CA.
Ver respuesta modelo
El principal riesgo es que las 50 laptops de contratistas que no están unidas al dominio no tendrán la AD CS Root CA privada en su almacén de certificados de confianza. Cuando el servidor RADIUS presente su Certificado de Servidor durante el saludo EAP-TLS, estos dispositivos recibirán un error de "Certificado no confiable" y no podrán conectarse. La resolución recomendada es obtener el Certificado de Servidor RADIUS de una CA pública (como DigiCert o Sectigo) en lugar de la AD CS privada. Las raíces de CA públicas están preinstaladas en los almacenes de confianza de todos los sistemas operativos principales, lo que garantiza la compatibilidad tanto con dispositivos unidos al dominio como con los que no lo están. La AD CS privada debe reservarse únicamente para emitir Certificados de Cliente a dispositivos administrados y unidos al dominio.
Q2. Durante una auditoría de cumplimiento para un gran fideicomiso de hospitales del NHS, el auditor observa que la Root CA se está ejecutando como una máquina virtual en el centro de datos principal y está conectada permanentemente a la red interna del hospital. El auditor señala esto como un hallazgo crítico. ¿Qué cambio de arquitectura se debe implementar y por qué la configuración actual representa un riesgo significativo?
Sugerencia: Considere qué pasaría con cada certificado de la organización si la clave privada de la Root CA se viera comprometida por un ataque de ransomware o una amenaza interna.
Ver respuesta modelo
La Root CA debe desconectarse de inmediato y mantenerse aislada de la red (air-gapped). La configuración actual es un riesgo crítico porque la clave privada de la Root CA está expuesta a ataques basados en la red, incluidos ransomware, movimientos laterales desde una cuenta de dominio comprometida o amenazas internas. Si la clave privada de la Root CA es robada o utilizada para firmar certificados maliciosos, toda la infraestructura de PKI (y, por lo tanto, cada sistema autenticado por certificado en el fideicomiso) se verá comprometida. La recuperación requeriría revocar la Root CA y volver a emitir cada certificado en la organización, un evento operativo catastrófico. La arquitectura correcta requiere que la Root CA se encienda únicamente al firmar o revocar un certificado de CA intermedia, manejando toda la emisión diaria mediante una CA intermedia en línea. La clave privada de la Root CA debe almacenarse en un Módulo de Seguridad de Hardware (HSM).
Q3. Un gran operador de centros de convenciones desea implementar la autenticación basada en certificados tanto para su personal de TI permanente como para los miles de expositores y visitantes que asisten a los eventos. Le piden que diseñe una única infraestructura de PKI para atender a ambos grupos. ¿Cuál es su recomendación y por qué?
Sugerencia: Considere la viabilidad operativa de distribuir certificados a miles de visitantes temporales no administrados que podrían asistir a un evento por un solo día.
Ver respuesta modelo
Se debe desaconsejar firmemente el uso de PKI y EAP-TLS para visitantes públicos y expositores. La autenticación basada en certificados requiere instalar un Certificado de Cliente y, a menudo, un perfil de Root CA en el dispositivo del usuario final, lo cual es operativamente imposible para dispositivos temporales no administrados y genera una experiencia de usuario sumamente deficiente. EAP-TLS debe reservarse estrictamente para el personal de TI permanente que utiliza dispositivos corporativos administrados e inscritos en la plataforma MDM de la organización. Para expositores y visitantes, se debe implementar una solución de Captive Portal en un SSID completamente separado y segregado. Esta arquitectura de dos redes (EAP-TLS seguro para el personal y Captive Portal para los invitados) es el estándar de la industria para operadores de recintos y es el modelo compatible con la plataforma de Purple.
Q4. Un gerente de TI en una cadena de tiendas minoristas ha implementado con éxito EAP-TLS en las 150 sucursales. Seis meses después, el servidor RADIUS en 12 tiendas deja de aceptar conexiones de clientes de manera simultánea. La investigación revela que no se ha producido ninguna revocación de certificados. ¿Cuál es la causa más probable y qué falla en el proceso permitió que esto sucediera?
Sugerencia: Considere qué podrían tener en común las 12 tiendas afectadas desde la perspectiva de los certificados, y qué evento podría causar fallas simultáneas.
Ver respuesta modelo
La causa más probable es que el certificado de la CA intermedia, o el Certificado de Servidor RADIUS, ha expirado. Si las 12 tiendas se configuraron utilizando la misma CA intermedia o el mismo lote de Certificados de Servidor RADIUS emitidos al mismo tiempo, todos expirarían simultáneamente. Esta es una falla en la gestión del ciclo de vida: la organización no implementó un monitoreo y alertas automatizadas para la expiración de certificados. La resolución requiere renovar los certificados expirados e implementar de inmediato un monitoreo automatizado con alertas a los 90, 60 y 30 días antes del vencimiento para todos los certificados de la jerarquía, incluidos la CA intermedia, el Certificado de Servidor RADIUS y la Root CA.
Continúe leyendo esta serie
How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment
Esta guía explica cómo configurar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados de WiFi empresariales, abarcando toda la arquitectura desde PKI y NDES hasta la implementación de perfiles MDM y la validación RADIUS. Está dirigida a gerentes de TI, arquitectos de red y CTOs en hoteles, cadenas de retail, estadios, centros de convenciones y organizaciones del sector público que necesitan ir más allá de las claves precompartidas e implementar una autenticación 802.1X EAP-TLS escalable y basada en la identidad. La plataforma de superposición en la nube de Purple, que es agnóstica al hardware, se integra directamente con esta arquitectura, proporcionando la capa de WiFi para invitados y BYOD que coexiste junto con la red de personal autenticada por certificado.
La guía empresarial de SCEP: Implementación de Simple Certificate Enrollment Protocol para la seguridad automatizada de WiFi en campus
Esta guía de referencia técnica proporciona un diseño arquitectónico definitivo y una estrategia de implementación paso a paso para la distribución de certificados de WiFi empresarial mediante SCEP. Cubre las diferencias críticas entre SCEP y PKCS, la secuencia exacta de implementación requerida para el éxito y las estrategias de mitigación de riesgos del mundo real para los líderes de TI.
Cómo implementar SCEP para la inscripción automatizada de certificados WiFi
Esta guía explica cómo implementar SCEP (Simple Certificate Enrollment Protocol) para la inscripción automatizada de certificados WiFi en entornos empresariales. Cubre el diseño completo de la arquitectura, desde el diseño de PKI y la integración con MDM hasta la secuencia obligatoria de implementación de tres pasos, y muestra a los gerentes de TI y arquitectos de red cómo eliminar las credenciales compartidas, automatizar la gestión del ciclo de vida de los certificados y cumplir con los requisitos de PCI DSS y GDPR a escala.