Cómo configurar SCEP para el registro automatizado de certificados WiFi corporativos

Esta guía explica cómo configurar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados WiFi corporativos, abarcando toda la arquitectura desde PKI y NDES hasta el despliegue de perfiles MDM y la validación RADIUS. Está dirigida a directores de TI, arquitectos de red y CTO de hoteles, cadenas de retail, estadios, centros de conferencias 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 independiente del hardware, se integra directamente con esta arquitectura, proporcionando la capa de WiFi para invitados y BYOD que coexiste junto a la red de personal autenticada por certificado.

📖 10 min de lectura📝 2,720 palabras🔧 2 ejemplos prácticos❓ 3 preguntas de práctica📚 9 definiciones clave

Escuchar esta guía

Ver transcripción del podcast

Le damos la bienvenida a la serie de informes técnicos de Purple. Hoy voy a hablar de algo que llega a muchas bandejas de entrada de TI pero que rara vez recibe una respuesta clara: cómo implementar realmente la autenticación de WiFi basada en certificados a escala, utilizando SCEP, en una red de gran tamaño. Ya se trate de un campus universitario, un grupo hotelero con múltiples sedes o un gran complejo del sector público, los retos son idénticos.

Vamos a cubrir todo el panorama. Qué hace realmente SCEP, cómo encaja en una arquitectura 802.1X, la secuencia de despliegue en la que la mayoría de los equipos se equivocan, dos escenarios de implementación del mundo real y los errores que le costarán un fin de semana de su vida si no los planifica.

Este es un informe de consultoría, no un tutorial. Asumo que sabe lo que es un servidor RADIUS y que probablemente ya haya decidido que necesita dejar atrás las claves precompartidas. Lo que necesita ahora es el mapa de implementación.

Entremos en materia.

Principios básicos. SCEP son las siglas de Simple Certificate Enrollment Protocol (Protocolo de registro de certificados simple). Fue formalizado por el IETF como RFC 8894 en 2020, aunque ya se utilizaba de forma generalizada en las empresas desde hacía más de una década. Su función es sencilla: automatizar el proceso de obtención de un certificado digital en un dispositivo gestionado sin necesidad de que una persona intervenga en cada máquina.

En el contexto de la autenticación de WiFi, SCEP es el mecanismo de entrega. El protocolo de autenticación real que se busca es EAP-TLS (Extensible Authentication Protocol with Transport Layer Security), que se encuadra dentro del marco 802.1X. EAP-TLS está considerado de forma generalizada como el método de autenticación más seguro para redes inalámbricas empresariales porque requiere que tanto el dispositivo cliente como el servidor RADIUS presenten certificados válidos. Ninguna de las partes confía en la otra sin una prueba criptográfica. Esa autenticación mutua es lo que le protege contra los ataques de "evil twin" (gemelo malvado), en los que un atacante levanta un punto de acceso no autorizado para recopilar credenciales.

Así es como funciona toda la cadena. Un dispositivo gestionado (el portátil de un estudiante, el teléfono de un empleado, un terminal de punto de venta de un hotel) necesita unirse a la red inalámbrica corporativa. Su plataforma MDM, que podría ser Microsoft Intune o Jamf, envía una carga útil de SCEP a ese dispositivo. La carga útil contiene dos cosas: la URL de SCEP, que apunta a su servidor NDES o pasarela SCEP en la nube, y una contraseña de desafío o secreto compartido.

El dispositivo genera su propio par de claves pública y privada de forma local. Esto es fundamental. La clave privada nunca sale del dispositivo. Se genera en el propio dispositivo, se almacena en el enclave seguro o TPM y nunca se transmite por la red. A continuación, el dispositivo crea una solicitud de firma de certificado (CSR) y la envía a la pasarela SCEP. La pasarela valida el desafío, reenvía la CSR a su entidad de certificación (CA), y la CA la firma y devuelve el certificado público al dispositivo.

A partir de ese momento, cuando el dispositivo se conecta a su SSID de WiFi, presenta ese certificado al servidor RADIUS. El servidor RADIUS valida el certificado contra su cadena de confianza de CA, comprueba la Lista de Revocación de Certificados para confirmar que el certificado no ha sido revocado y, si todo es correcto, envía un mensaje de aceptación al punto de acceso. El dispositivo ya está en la red. Todo el proceso es invisible para el usuario.

Ahora, hablemos de dónde se sitúa SCEP en relación con la alternativa, que es PKCS. PKCS (Public Key Cryptography Standards) es el otro método de entrega de certificados compatible con plataformas como Intune. Con PKCS, la CA genera tanto la clave pública como la privada de forma centralizada, y el conector de certificados envía el par de claves al dispositivo. Esto significa que la clave privada viaja por la red, lo que introduce una superficie de ataque teórica. PKCS es adecuado para casos de uso como el cifrado de correo electrónico S/MIME, donde el depósito de claves es realmente deseable. Para la autenticación WiFi, SCEP es la opción correcta. La clave privada se queda en el dispositivo, y punto.

Ahora, la capa de hardware. SCEP y EAP-TLS son estándares neutrales respecto al proveedor, lo que significa que funcionan en puntos de acceso de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Su configuración de RADIUS, ya sea Windows NPS, FreeRADIUS o un servicio RADIUS en la nube, es donde se define la política de validación de certificados y, fundamentalmente, donde se configura la asignación dinámica de VLAN.

Las VLAN dinámicas son la forma de segmentar la red por identidad. El dispositivo de un estudiante obtiene la VLAN 20 solo para acceso a internet. El dispositivo de un profesor obtiene la VLAN 10 para acceder a los sistemas de investigación internos. Un dispositivo de gestión de instalaciones obtiene la VLAN 30 para acceder a los sistemas de gestión del edificio. Todo esto se gestiona mediante los atributos del certificado y la política de RADIUS, sin ninguna intervención manual por dispositivo.

Para la integración con proveedores de identidad, los atributos de certificado SCEP, específicamente el Subject Alternative Name, pueden contener el nombre principal de usuario de Microsoft Entra ID, Okta o Google Workspace. Esto vincula el certificado a una identidad específica, lo que significa que cuando se deshabilita una cuenta en Entra ID y el MDM retira el dispositivo, el certificado se revoca y el acceso a la WiFi se corta automáticamente. Esa es la historia de revocación que las claves precompartidas simplemente no pueden ofrecer.

Bien, hablemos de la secuencia de despliegue, porque aquí es donde la mayoría de los equipos se equivocan.

La secuencia no es negociable: primero el certificado raíz de confianza, segundo el perfil de certificado SCEP y tercero el perfil de WiFi. Tanto Intune como Jamf imponen dependencias de perfil. Si su perfil de WiFi hace referencia a un certificado SCEP que aún no se ha desplegado en el dispositivo, el perfil de WiFi fallará con un error críptico que parece una configuración incorrecta, pero que en realidad es solo un problema de sincronización temporal.

El segundo error común es la segmentación por grupos. Los tres perfiles, Trusted Root, SCEP y WiFi, deben desplegarse exactamente en el mismo grupo de Azure AD o Jamf. Si el perfil SCEP se dirige a un grupo de usuarios y el perfil WiFi a un grupo de dispositivos, Intune no podrá resolver la dependencia y el perfil WiFi se mostrará como No aplicable. Esto suele pillar desprevenidos a los equipos constantemente.

Tercero: la accesibilidad del servidor NDES. Su servidor NDES debe ser accesible desde internet para que los dispositivos puedan registrarse antes de llegar a las instalaciones. La forma correcta de hacerlo es a través de Azure AD Application Proxy, no abriendo un puerto en su cortafuegos. App Proxy le ofrece un acceso remoto seguro sin puertos entrantes y le permite aplicar políticas de acceso condicional al flujo de registro.

Cuarto: la disponibilidad de la CRL. Su servidor RADIUS comprueba la lista de revocación de certificados (CRL) cada vez que un dispositivo se autentica. Si el punto de distribución de su CRL no está disponible, ya sea porque un servidor está caído o porque la URL ha cambiado, la autenticación fallará para todos los dispositivos de la red simultáneamente. Eso se traduce en una caída de toda la sede. Asegúrese de que sus endpoints de CRL tengan una alta disponibilidad y pruebe la revocación antes de la puesta en marcha.

Para redes grandes, de más de 500 dispositivos, considere una pasarela SCEP en la nube en lugar de un NDES local. Las pasarelas en la nube eliminan el punto único de fallo de NDES, escalan horizontalmente y, por lo general, se integran directamente con los servicios RADIUS en la nube, eliminando otra dependencia de infraestructura.

Abordemos ahora algunas preguntas rápidas que solemos escuchar de los CTO.

¿Puede SCEP gestionar dispositivos BYOD que no están registrados en el MDM? No directamente. SCEP requiere el registro en el MDM para enviar la carga útil del certificado. Para BYOD no gestionados, se necesita un enfoque diferente: un portal de autogestión para la incorporación de usuarios o un SSID independiente que utilice un Captive Portal con verificación de identidad. Purple gestiona esa capa de invitados y BYOD de forma limpia, conviviendo con su red de empleados autenticada por certificados.

¿Qué ocurre con iOS y Android? Ambas plataformas son compatibles con SCEP de forma nativa. iOS es compatible con SCEP desde iOS 4. Android Enterprise admite SCEP a través de Intune y otros MDM. La configuración varía ligeramente según la plataforma, pero el protocolo subyacente es idéntico.

¿Funciona EAP-TLS con WPA3? Sí. WPA3-Enterprise exige un modo de seguridad de 192 bits para entornos sensibles, y EAP-TLS es totalmente compatible. De hecho, WPA3-Enterprise con EAP-TLS es la combinación recomendada por la Wi-Fi Alliance para redes gubernamentales y financieras.

En resumen: la autenticación WiFi mediante certificados SCEP es la arquitectura adecuada para cualquier red con más de 50 dispositivos gestionados. Elimina las credenciales compartidas, proporciona una identidad por dispositivo, permite la segmentación dinámica de VLAN y se integra directamente con su proveedor de identidad para la revocación automatizada. La secuencia de despliegue (Trusted Root, luego perfil SCEP y, por último, perfil WiFi) es fija. La segmentación por grupos debe ser coherente. La disponibilidad de la CRL no es opcional.

Específicamente para la educación superior, la combinación de SCEP para los dispositivos del personal y del profesorado, junto con una capa de WiFi para invitados independiente para los estudiantes en sus dispositivos personales, le ofrece tanto seguridad como una excelente experiencia de usuario sin concesiones.

Si desea profundizar más, la guía de Purple sobre autenticación WiFi empresarial cubre el camino nativo de la nube. Y si está pensando en qué ocurre cuando un empleado se marcha, nuestra guía sobre cómo revocar el acceso a WiFi detalla todo el flujo de trabajo de revocación.

Gracias por escucharnos. Soy del equipo técnico de Purple y nos vemos en la próxima sesión informativa.

Conclusiones clave

✓SCEP (RFC 8894) automatiza el registro de certificados para dispositivos gestionados: la clave privada se genera en el dispositivo y nunca se transmite, lo que lo convierte en la opción correcta para la autenticación WiFi frente a PKCS.
✓La secuencia de despliegue no es negociable: primero el certificado de raíz de confianza (Trusted Root), segundo el perfil de certificado SCEP y tercero el perfil WiFi. Violar este orden provoca fallos de dependencia de perfil.
✓Los tres perfiles de MDM (Trusted Root, SCEP, WiFi) deben dirigirse exactamente al mismo grupo de directorio. El direccionamiento entre diferentes grupos es la causa más común de fallos de despliegue.
✓NDES debe publicarse a través de Azure AD Application Proxy, no exponerse directamente a internet. Para redes de más de 500 dispositivos, una pasarela SCEP en la nube elimina el punto único de fallo de NDES.
✓La disponibilidad del punto de distribución de la CRL es una dependencia crítica de la red. Si el servidor RADIUS no puede acceder a la CRL, falla por seguridad (fails closed) y deniega todas las autenticaciones simultáneamente.
✓EAP-TLS con certificados provistos por SCEP cumple con el requisito 8.6 de PCI DSS 4.0 para redes inalámbricas en entornos de datos de titulares de tarjetas, y es obligatorio para WPA3-Enterprise de 192 bits (Suite B).
✓SCEP cubre únicamente dispositivos gestionados. Los dispositivos BYOD no gestionados y de invitados requieren un SSID independiente con Captive Portal y verificación de identidad; la plataforma de Purple gestiona esta capa junto con la red de su personal autenticada por certificado.

📚 Parte de nuestra serie principal: Enterprise WiFi Security Guide →

Resumo executivo

Para espaços empresariais - quer se trate de um hotel de 200 quartos, de uma cadeia de retalho com 50 localizações ou de um grande centro de conferências - depender de chaves pré-partilhadas para o WiFi dos funcionários é um risco de segurança e um estrangulamento operacional. Uma única palavra-passe divulgada expõe toda a rede. A autenticação baseada em certificados via IEEE 802.1X e EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina totalmente esse risco. Cada dispositivo prova a sua identidade de forma criptográfica antes de o ponto de acesso lhe conceder acesso à rede.

O desafio reside na distribuição. Implementar manualmente certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android não é viável. O SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 pela IETF em 2020, resolve este problema. Automatiza o processo de solicitação, emissão e instalação de certificados digitais em dispositivos geridos através da sua plataforma MDM - sem qualquer interação do utilizador.

Este guia abrange toda a arquitetura: o que o SCEP faz, como se integra com o Microsoft Intune, Jamf e outras plataformas MDM, a sequência exata de implementação que a maioria das equipas erra e as armadilhas operacionais que causam interrupções de serviço. Também abordamos dois cenários reais de implementação em hotelaria e retalho, e explicamos onde a plataforma de Guest WiFi da Purple se enquadra ao lado da sua rede de funcionários autenticada por certificado.

Ouça o podcast informativo complementar:

Análise técnica detalhada: SCEP, PKI e 802.1X

O que o SCEP realmente faz

O SCEP não substitui a sua Public Key Infrastructure (PKI). É a camada de registo automatizada que se posiciona sobre ela. A sua PKI - normalmente uma hierarquia de dois níveis com uma CA raiz offline e uma CA emissora online - continua a ser a âncora de confiança. O SCEP automatiza a etapa em que um dispositivo solicita um certificado a essa CA, eliminando a necessidade de geração manual de CSR e instalação de certificados.

No contexto da autenticação WiFi, o protocolo de destino é o EAP-TLS. Este é o método de autenticação 802.1X que exige que tanto o dispositivo cliente como o servidor RADIUS apresentem certificados X.509 válidos. Nenhuma das partes confia na outra sem prova criptográfica. Esse modelo de autenticação mútua elimina o roubo de credenciais e protege contra ataques de "evil twin", em que um atacante cria um ponto de acesso falso para recolher nomes de utilizador e palavras-passe.

Para uma análise detalhada do handshake EAP-TLS, consulte o nosso guia sobre WiFi Certificate Authentication: Secure Network Access .

O fluxo de registo SCEP, passo a passo

A cadeia de registo completa funciona da seguinte forma. A sua plataforma MDM - Microsoft Intune, Jamf ou outro MDM - envia um payload SCEP para um dispositivo gerido. Esse payload contém duas coisas: o URL do SCEP que aponta para o seu servidor NDES (Network Device Enrollment Service) ou gateway SCEP na nuvem, e uma palavra-passe de desafio ou segredo partilhado.

O dispositivo gera o seu próprio par de chaves pública e privada localmente. Esta é a propriedade de segurança crítica do SCEP: a chave privada é gerada no dispositivo, armazenada no enclave seguro ou chip TPM, e nunca é transmitida pela rede. O dispositivo cria então um Certificate Signing Request (CSR) e envia-o para o gateway SCEP. O gateway valida a palavra-passe de desafio, encaminha o CSR para a sua Autoridade de Certificação (CA), e a CA assina-o e devolve o certificado público ao dispositivo.

A partir desse momento, quando o dispositivo se liga ao seu SSID de WiFi, apresenta esse certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação à sua cadeia de confiança da CA, verifica a Lista de Revogação de Certificados (CRL) para confirmar que o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem Access-Accept para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o utilizador.

SCEP vs. PKCS: qual utilizar para WiFi

As plataformas MDM como o Intune suportam dois mecanismos de entrega de certificados: SCEP e PKCS (Public Key Cryptography Standards). A diferença arquitetónica é significativa.

Com o SCEP, a chave privada é gerada no dispositivo e nunca sai dele. Com o PKCS, a Autoridade de Certificação gera a chave pública e a privada centralmente, e o conector de certificados envia o par de chaves para o dispositivo através da rede. Isso significa que a chave privada é transmitida, o que introduz uma superfície de ataque teórica.

O PKCS é adequado para casos de utilização em que a custódia de chaves é necessária, como a encriptação de e-mail S/MIME. Para a autenticação WiFi, o SCEP é a escolha correta. A chave privada permanece no dispositivo.

Propriedade	SCEP	PKCS
Geração de chave privada	No dispositivo (TPM/Secure Enclave)	Centralizada (CA)
Transmissão de chave privada	Nunca	Através da rede
Servidor NDES necessário	Sim (ou gateway na nuvem)	Não
Recomendado para WiFi	Sim	Não
Recomendado para S/MIME	Não	Sim

Compatibilidade de hardware

O SCEP e o EAP-TLS são normas independentes de fornecedor. Funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração RADIUS - quer seja Windows NPS, FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e a atribuição dinâmica de VLAN.

A atribuição dinâmica de VLAN é a forma como segmenta a rede através da identidade do dispositivo. Um dispositivo de um funcionário recebe a VLAN 10 com acesso a sistemas internos. O dispositivo de um prestador de serviços recebe a VLAN 20 apenas com acesso à internet. Um terminal de ponto de venda recebe a VLAN 30 apenas com acesso a sistemas de processamento de pagamentos. Tudo isto é gerido por atributos de certificado e pela política RADIUS, sem qualquer intervenção manual por dispositivo.

Para saber mais sobre como o WiFi Analytics se integra com a segmentação de rede baseada em identidade, consulte a nossa visão geral da plataforma de analytics.

Guia de implementação: a sequência de implementação

A configuração bem-sucedida do SCEP para WiFi empresarial exige a adesão estrita a uma sequência de implementação específica. As plataformas MDM impõem dependências de perfil: um perfil de WiFi que faça referência a um certificado SCEP não pode ser aplicado até que esse certificado exista no dispositivo. A violação desta sequência é a causa mais comum de falhas na implementação.

A sequência é: primeiro a Raiz de Confiança (Trusted Root), segundo o perfil SCEP, terceiro o perfil WiFi. Esta ordem não é negociável.

Passo 1: implementar o perfil de Certificado de Raiz de Confiança (Trusted Root)

Antes de qualquer dispositivo poder solicitar um certificado de cliente ou confiar no seu servidor RADIUS, deve confiar na Autoridade de Certificação (CA) emissora. Exporte o seu certificado de CA Raiz - e quaisquer certificados de CA Intermédia - como ficheiros .cer. No seu centro de administração MDM, crie um perfil de Certificado de Confiança, carregue o ficheiro .cer e implemente-o no seu grupo de dispositivos de destino.

Se tiver uma hierarquia PKI de dois níveis (recomendado), precisa de implementar tanto o certificado da CA raiz como o da CA emissora como perfis de Certificado de Confiança separados, ou como uma cadeia num único perfil, dependendo da sua plataforma MDM.

Passo 2: configurar o perfil de Certificado SCEP

Assim que a confiança estiver estabelecida, configure o perfil SCEP para instruir os dispositivos sobre como obter o seu certificado de cliente.

Crie um novo perfil de configuração e selecione o tipo de perfil de certificado SCEP. Configure o formato do Nome do Requerente (Subject name). Para autenticação baseada no utilizador, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivos (dispositivos partilhados, IoT, terminais POS), utilize CN={{AAD_Device_ID}}. Defina a Utilização da chave (Key usage) para Assinatura digital e Cifragem de chave. Defina a Utilização de Chave Alargada (Extended Key Usage) para Autenticação de Cliente (OID: 1.3.6.1.5.5.7.3.2). Associe este perfil ao perfil de certificado de Raiz de Confiança criado no Passo 1. Forneça o URL externo do seu servidor NDES.Para o Microsoft Intune especificamente, o servidor NDES deve ser publicado através do Azure AD Application Proxy para permitir que os dispositivos remotos se registem antes de chegarem ao local. Não exponha o NDES diretamente à internet.

Passo 3: implementar o perfil de WiFi 802.1X

O passo final é enviar a configuração de WiFi que associa os certificados ao SSID da rede. Crie um perfil de configuração de Wi-Fi. Introduza o Nome da rede (SSID) exatamente como é transmitido pelos seus pontos de acesso. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança. Defina o tipo de EAP para EAP-TLS. Nas definições de autenticação, selecione o perfil de certificado SCEP criado no Passo 2 como o certificado de autenticação do cliente. Especifique o certificado Trusted Root para validação do servidor - isto garante que o dispositivo apenas se liga ao seu servidor RADIUS legítimo e não a um ponto de acesso não autorizado.

Integração do fornecedor de identidade

Os atributos do certificado SCEP - especificamente o Subject Alternative Name (SAN) - podem conter o nome principal do utilizador do Microsoft Entra ID, Okta ou Google Workspace. Isto associa o certificado a uma identidade específica. Quando desativa uma conta no Entra ID e o MDM remove o registo do dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa revogação automatizada é a história de segurança que as chaves pré-partilhadas não conseguem igualar.

Para saber mais sobre EAP Method WiFi: A Guide to Secure Network Access , incluindo caminhos de migração PEAP-MSCHAPv2, consulte o nosso guia dedicado.

Boas práticas e padrões da indústria

Posicionamento do servidor NDES

O servidor NDES deve estar acessível a partir da internet para que os dispositivos se possam registar antes de chegarem ao local. Publique o URL do NDES através do Azure AD Application Proxy. Isto fornece um acesso remoto seguro sem abrir portas de firewall de entrada e permite-lhe aplicar políticas de Acesso Condicional ao fluxo de registo. Nunca exponha o NDES diretamente à internet.

Para redes com mais de 500 dispositivos geridos, considere um gateway SCEP na nuvem em vez de um NDES local. Os gateways na nuvem eliminam o ponto único de falha do NDES, escalam horizontalmente e, normalmente, integram-se diretamente com serviços RADIUS na nuvem.

Disponibilidade da CRL

O seu servidor RADIUS verifica a Lista de Revogação de Certificados (CRL) sempre que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL (CDP) estiver indisponível - porque um servidor está em baixo ou o URL mudou - a autenticação falha para todos os dispositivos na rede em simultâneo. Configure o seu servidor NPS ou RADIUS para impor uma verificação rigorosa da CRL e torne os seus endpoints de CRL altamente disponíveis. Teste a revogação antes de entrar em produção.

O Requisito 8.6 do PCI DSS 4.0 exige autenticação multifator na camada de rede para ambientes de dados de titulares de cartões. O EAP-TLS com certificados provisionados por SCEP satisfaz este requisito para redes sem fios em ambientes de Retail e Hospitality .

Compatibilidade com WPA3

O EAP-TLS é totalmente compatível com o WPA3-Enterprise. O WPA3-Enterprise com a suite de segurança de 192 bits (Suite B) exige o EAP-TLS e é a combinação recomendada pela Wi-Fi Alliance para redes governamentais, financeiras e de saúde. Se está a implementar em ambientes de Saúde ou Transportes com requisitos de conformidade rigorosos, o WPA3-Enterprise com EAP-TLS é a arquitetura-alvo correta.

BYOD e WiFi de convidados

O SCEP requer a inscrição no MDM para enviar o payload do certificado. Não abrange dispositivos BYOD não geridos ou convidados. Para esses casos de utilização, necessita de um SSID separado com um Captive Portal e verificação de identidade. A plataforma da Purple lida com essa camada de forma limpa, coexistindo com a sua rede de funcionários autenticada por certificado. A nossa plataforma de Guest WiFi suporta opt-ins de escolha consciente, captura de dados primários (first-party) e integração com o Microsoft Entra ID, Okta e Google Workspace para verificação de identidade.

Resolução de problemas e mitigação de riscos

Falha na aplicação do perfil de WiFi

Sintoma: O dispositivo recebe os certificados Trusted Root e SCEP, mas o perfil de WiFi é apresentado como Erro ou Não Aplicável no MDM.

Causa raiz: Incompatibilidade de segmentação de grupo. Se o perfil SCEP se destinar a um grupo de Utilizadores e o perfil de WiFi se destinar a um grupo de Dispositivos, o MDM não consegue resolver a dependência.

Solução: Audite as suas atribuições. Certifique-se de que os perfis Trusted Root, SCEP e WiFi se destinam todos exatamente ao mesmo grupo de diretório.

Erros NDES 403 Forbidden

Sintoma: Os dispositivos não conseguem obter o certificado SCEP. Os registos do IIS do NDES mostram erros HTTP 403.

Causa raiz: A conta de serviço do MDM Certificate Connector não tem permissões de Leitura e Inscrição (Read and Enroll) no modelo de certificado, ou a filtragem de URLs da firewall está a bloquear os parâmetros de query string do SCEP.

Solução: Verifique se a conta do conector tem permissões de Leitura e Inscrição no modelo da CA. Verifique os registos da firewall para garantir que os URLs que contêm ?operation=GetCACaps não estão bloqueados.

Falha de autenticação em massa após expiração da CRL

Sintoma: Todos os dispositivos na rede falham a autenticação em simultâneo.

Causa raiz: A CRL expirou ou o URL do CDP está inacessível. O servidor RADIUS não consegue confirmar se os certificados são válidos e falha por omissão (fails closed).

Solução: Configure a monitorização e alertas de CRL. Publique as CRLs com um período de validade significativamente superior ao intervalo de publicação. Teste a acessibilidade do CDP a partir do servidor RADIUS antes do lançamento.

Expiração de certificado a causar falhas silenciosas

Sintoma: Dispositivos individuais falham a ligação de forma intermitente, sem um padrão claro.

Causa raiz: Os certificados de cliente expiraram e o MDM não os renovou com sucesso.

Solução: Configure a renovação do certificado para ser acionada a 80% do tempo de vida do certificado. Monitorize os relatórios de estado de inscrição do MDM para dispositivos com erros de certificado. Defina períodos de validade de certificado adequados ao ciclo de atualização dos seus dispositivos - normalmente um a dois anos para endpoints geridos.

ROI e impacto empresarial

A transição para a autenticação por certificado 802.1X baseada em SCEP proporciona retornos mensuráveis em termos de segurança, operações e conformidade.

Redução de pedidos de suporte: O WiFi baseado em palavra-passe gera um volume significativo de pedidos de suporte - expiração de palavras-passe, bloqueios e erros de digitação. A autenticação baseada em certificado é invisível para o utilizador. As organizações registam tipicamente uma redução de 70-80% no volume de suporte relacionado com WiFi após a migração.

Postura de segurança: O EAP-TLS elimina a recolha de credenciais e os ataques Man-in-the-Middle. Isto apoia diretamente a conformidade com a norma PCI DSS 4.0 para redes de retalho e hotelaria, bem como os requisitos do Artigo 32.º do GDPR para medidas técnicas de segurança adequadas.

Revogação automatizada: Quando um colaborador sai da empresa, a desativação da sua conta no Microsoft Entra ID aciona a revogação automática do certificado e a desassociação do MDM. O acesso ao WiFi é cortado sem qualquer intervenção manual por parte da equipa de rede.

Segmentação de rede: A atribuição dinâmica de VLAN através de atributos de certificado RADIUS oferece-lhe uma segmentação de rede aplicada de forma criptográfica. Os dispositivos entram no segmento de rede correto com base nas propriedades do certificado, e não na seleção de SSID ou na filtragem de endereços MAC - ambas facilmente contornáveis.

A Purple opera em mais de 80.000 locais ativos com 99,999% de tempo de atividade, e a nossa plataforma possui as certificações ISO 27001, GDPR, CCPA e Cyber Essentials. A nossa sobreposição de nuvem agnóstica em termos de hardware integra-se com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - para que a sua rede de colaboradores autenticada por certificado e a nossa camada de WiFi de convidados funcionem a partir da mesma infraestrutura.

Para saber mais sobre como a análise comportamental ( Behavioral Analytics: Insights for WiFi Networks ) pode complementar a sua implementação de rede segura, consulte o nosso guia de análise.

Referências

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

Definiciones clave

SCEP (Simple Certificate Enrollment Protocol)

Un protocolo formalizado en RFC 8894 que permite a los dispositivos gestionados solicitar y recibir automáticamente certificados digitales X.509 de una Autoridad de Certificación a través de HTTP, utilizando una contraseña de desafío compartida para la autenticación inicial. La clave privada se genera en el dispositivo y nunca se transmite.

El mecanismo estándar utilizado por plataformas MDM como Microsoft Intune y Jamf para desplegar certificados de autenticación WiFi en endpoints gestionados a escala.

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

El método de autenticación 802.1X más seguro, que requiere que tanto el dispositivo cliente como el servidor RADIUS presenten certificados X.509 válidos. La autenticación mutua significa que ninguna de las partes confía en la otra sin una prueba criptográfica.

El protocolo de autenticación de destino para WiFi empresarial. Obligatorio o fuertemente recomendado por PCI DSS 4.0, WPA3-Enterprise de 192 bits (Suite B) y HIPAA para redes inalámbricas que manejan datos sensibles.

NDES (Network Device Enrollment Service)

Un rol de Microsoft Windows Server que actúa como una Autoridad de Registro (RA) entre los dispositivos habilitados para SCEP y una Autoridad de Certificación. Valida las contraseñas de desafío y reenvía las CSR a la CA en nombre de los dispositivos que carecen de credenciales de dominio.

Infraestructura requerida para el despliegue de SCEP con Microsoft Intune. Debe publicarse a través de Azure AD Application Proxy en lugar de exponerse directamente a internet.

PKI (Public Key Infrastructure)

La jerarquía de Autoridades de Certificación, políticas y procedimientos utilizados para emitir, gestionar y revocar certificados digitales. Una PKI de dos niveles consta de una CA raíz fuera de línea (el ancla de confianza maestra) y una CA emisora en línea (que gestiona la emisión diaria de certificados).

El requisito previo no negociable para el despliegue de EAP-TLS y SCEP. La CA raíz debe mantenerse aislada (air-gapped); su clave privada es la base de toda su cadena de confianza de certificados.

CSR (Certificate Signing Request)

Un mensaje generado por un dispositivo que contiene su clave pública e información de identidad, enviado a una Autoridad de Certificación para solicitar un certificado digital firmado. En SCEP, la CSR se genera en el dispositivo y se empaqueta en un sobre PKCS antes de la transmisión.

Generada automáticamente por el dispositivo durante el flujo de inscripción de SCEP. La clave privada utilizada para firmar la CSR nunca sale del dispositivo.

CRL (Certificate Revocation List)

Una lista publicada por la Autoridad de Certificación que contiene los números de serie de los certificados que han sido revocados antes de su fecha de caducidad. Los servidores RADIUS comprueban la CRL en cada intento de autenticación para garantizar que los certificados revocados no puedan acceder a la red.

La disponibilidad del Punto de Distribución de CRL (CDP) es crítica. Si el servidor RADIUS no puede acceder a la CRL, falla de forma segura bloqueando el acceso y deniega toda autenticación, lo que provoca una interrupción en toda la red.

RADIUS (Remote Authentication Dial-In User Service)

Un protocolo de red que proporciona Autenticación, Autorización y Contabilidad (AAA) centralizada para el acceso a la red. En WiFi 802.1X, el servidor RADIUS valida los certificados de los clientes, comprueba la CRL y devuelve un mensaje de Access-Accept o Access-Reject al punto de acceso.

El servidor de autenticación en el modelo suplicante-autenticador-servidor de 802.1X. Las implementaciones comunes incluyen Windows NPS, FreeRADIUS y servicios RADIUS en la nube.

Dynamic VLAN assignment

Una función de RADIUS que coloca un dispositivo autenticado en una VLAN específica en función de los atributos del certificado o de la pertenencia a un grupo de directorio, en lugar de depender de la selección de SSID o del filtrado de direcciones MAC. Aplica la segmentación de red por identidad de dispositivo.

Permite que un único SSID sirva a múltiples tipos de dispositivos con diferentes niveles de acceso a la red. Un dispositivo del personal obtiene la VLAN 10 (acceso interno); el dispositivo de un contratista obtiene la VLAN 20 (solo internet); un terminal de punto de venta obtiene la VLAN 30 (solo sistemas de pago).

MDM (Mobile Device Management)

Software utilizado por los equipos de TI para inscribir, configurar, proteger y gestionar smartphones, tablets y portátiles. Las plataformas MDM como Microsoft Intune y Jamf utilizan perfiles SCEP para enviar instrucciones de inscripción de certificados a los dispositivos gestionados sin interacción del usuario.

El requisito previo para el despliegue de certificados basado en SCEP. Los dispositivos deben estar inscritos en el MDM antes de poder recibir los perfiles de SCEP y WiFi. Los dispositivos BYOD no gestionados requieren un enfoque de incorporación independiente.

Ejemplos prácticos

Un hotel Premier Inn de 200 habitaciones necesita proteger su WiFi para el personal, destinado a tabletas de punto de venta y smartphones del servicio de limpieza. Actualmente utilizan una clave precompartida que se ha filtrado a contratistas externos. Gestionan los dispositivos a través de Microsoft Intune y tienen una combinación de dispositivos iOS y Android. El establecimiento utiliza puntos de acceso HPE Aruba.

Implementar una PKI interna de dos niveles de Microsoft AD CS. Configurar NDES en un servidor Windows dedicado y publicarlo a través de Azure AD Application Proxy.
En Intune, crear un perfil de Certificado de Raíz de Confianza que contenga los certificados de la CA Raíz y de la CA Emisora. Desplegarlo en un grupo de Azure AD llamado 'Property Staff Devices'.
Crear un perfil de Certificado SCEP en Intune que apunte a la URL externa de NDES. Establecer el formato del Nombre de Sujeto como CN={{AAD_Device_ID}}, ya que se trata de dispositivos compartidos. Configurar el Uso de Clave para Firma Digital y Cifrado de Clave, y el Uso Extendido de Clave para Autenticación de Cliente. Desplegar en 'Property Staff Devices'.
Crear un perfil de Wi-Fi para el SSID del personal, configurando WPA2-Enterprise y EAP-TLS. Seleccionar el perfil SCEP para la autenticación del cliente y la CA Raíz para la validación del servidor. Desplegar en 'Property Staff Devices'.
Configurar los ajustes de RADIUS de HPE Aruba para que apunten a Windows NPS. En NPS, configurar una Directiva de Red que requiera EAP-TLS y asigne la VLAN 10 para los dispositivos del personal.
Una vez que los dispositivos reciban los perfiles y se conecten correctamente, rotar la PSK en el SSID antiguo y programar su desmantelamiento.

Comentario del examinador: Este enfoque identifica correctamente que los dispositivos compartidos (TPV, limpieza) requieren una autenticación basada en el dispositivo (CN={{AAD_Device_ID}}) en lugar de una autenticación basada en el usuario, ya que varios miembros del personal utilizan el mismo dispositivo. Sigue la secuencia obligatoria de despliegue de perfiles y garantiza que los tres perfiles se dirijan al mismo grupo de Azure AD. Publicar NDES a través de App Proxy en lugar de una exposición directa a Internet es la postura de seguridad correcta para un entorno de hostelería.

Una cadena de tiendas con 50 ubicaciones quiere desplegar 802.1X para portátiles corporativos en todos sus centros. Utilizan puntos de acceso Cisco Meraki y Microsoft Intune. No desean desplegar ni mantener servidores NDES locales ni infraestructura AD CS en cada ubicación ni en su centro de datos.

Implementar un servicio de pasarela SCEP y PKI basado en la nube que se integre con Intune a través del protocolo SCEP. La CA en la nube emite los certificados; la pasarela SCEP en la nube gestiona la validación de las CSR.
Configurar el servicio RADIUS en la nube (proporcionado por el proveedor de PKI) dentro del panel de Cisco Meraki en Wireless > Access Control para el SSID corporativo. Establecer la seguridad en WPA2-Enterprise y apuntar RADIUS al servicio en la nube.
En Intune, crear un perfil de Certificado de Raíz de Confianza que contenga el certificado raíz de la CA en la nube. Desplegar en el grupo de dispositivos 'Corporate Laptops'.
Crear un perfil de Certificado SCEP que apunte a la URL de la pasarela SCEP en la nube. Establecer el Nombre de Sujeto como CN={{UserPrincipalName}} para la autenticación basada en el usuario. Desplegar en 'Corporate Laptops'.
Crear un perfil de Wi-Fi para el SSID corporativo con EAP-TLS, haciendo referencia al perfil SCEP y a la raíz de la CA en la nube. Desplegar en 'Corporate Laptops'.
Cuando los portátiles se registran en Intune, solicitan automáticamente certificados a la CA en la nube a través de la pasarela SCEP en la nube. No se requiere infraestructura local en ninguna de las 50 ubicaciones.

Comentario del examinador: Esta es la arquitectura moderna óptima para entornos de retail distribuidos. Al aprovechar la PKI en la nube y el servicio RADIUS en la nube, la organización elimina la necesidad de mantener una infraestructura local compleja (NDES, AD CS, NPS) en cada centro. La pasarela SCEP en la nube escala horizontalmente y es intrínsecamente de alta disponibilidad, eliminando el punto único de fallo que introduce NDES local. La arquitectura gestionada en la nube de Cisco Meraki se alinea perfectamente con este enfoque.

Preguntas de práctica

Q1. Su organización está migrando de PEAP-MSCHAPv2 a EAP-TLS. Ha implementado correctamente los perfiles de SCEP y de raíz de confianza en su grupo de Azure AD "Corporate Users" en Intune. Implementa el perfil de WiFi en "All Corporate Devices". Los usuarios informan de que no pueden conectarse y el perfil de WiFi aparece como No aplicable.

Sugerencia: Comprueba las dependencias del perfil y las reglas de segmentación de grupos. Intune resuelve las dependencias del perfil en función del grupo asignado.

Ver respuesta modelo

El problema es una discrepancia en la segmentación de grupos. El perfil de WiFi depende del perfil de SCEP, que se asignó a un grupo de usuarios ("Corporate Users"). El perfil de WiFi se asignó a un grupo de dispositivos ("All Corporate Devices"). Intune no puede resolver la dependencia entre diferentes tipos de grupos. La solución consiste en cambiar las tres asignaciones de perfil (raíz de confianza, SCEP y WiFi) para que se dirijan al mismo grupo. Decida si desea utilizar un grupo de usuarios o un grupo de dispositivos en función de su modelo de autenticación (basado en usuarios frente a basado en dispositivos) y aplíquelo de forma coherente en los tres perfiles.

Q2. Una auditoría de seguridad revela que cuando se despide a un empleado y se deshabilita su cuenta de Microsoft Entra ID, su smartphone corporativo aún puede conectarse a la red WiFi del personal hasta una semana después del despido.

Sugerencia: Considere cómo determina el servidor RADIUS si un certificado sigue siendo válido después de deshabilitar la cuenta. ¿Cuál es el mecanismo para comunicar el estado de revocación?

Ver respuesta modelo

El servidor RADIUS no está realizando una comprobación estricta de la lista de revocación de certificados (CRL), o bien la CRL se publica con poca frecuencia. Cuando se despide a un empleado, el MDM debe anular el registro del dispositivo y la CA debe revocar el certificado. Sin embargo, si el servidor RADIUS no comprueba la CRL en cada intento de autenticación, o si la CRL solo se publica semanalmente, el certificado revocado se sigue aceptando. La solución consta de tres pasos: configurar el servidor RADIUS para exigir una comprobación estricta de la CRL en cada autenticación; configurar la CA para publicar la CRL en un intervalo más corto (diario o más frecuente); y asegurarse de que el MDM esté configurado para activar la revocación del certificado cuando se anule el registro de un dispositivo.

Q3. Debe proporcionar acceso WiFi seguro para dispositivos IoT sin pantalla (termostatos inteligentes, reproductores de señalización digital) que no pueden ejecutar un agente MDM y no pueden mostrar un Captive Portal. ¿Puede utilizar SCEP para estos dispositivos y, si no es así, cuál es la alternativa recomendada?

Sugerencia: Considere los requisitos previos para el registro de SCEP y qué alternativas existen para los dispositivos que no se pueden registrar en el MDM o que no pueden interactuar con un navegador.

Ver respuesta modelo

No se puede utilizar SCEP para estos dispositivos. SCEP requiere un agente MDM para recibir la URL de registro y la contraseña de desafío, generar el par de claves e instalar el certificado resultante. Los dispositivos IoT sin pantalla que no pueden ejecutar un agente MDM no pueden participar en el flujo de registro de SCEP. Las alternativas recomendadas son: (1) MAC Authentication Bypass (MAB) combinado con una segmentación estricta de VLAN: el servidor RADIUS permite el dispositivo en función de su dirección MAC y lo coloca en una VLAN de IoT aislada sin acceso a los sistemas corporativos; (2) si el dispositivo lo admite, EST (Enrollment over Secure Transport, RFC 7030) puede aprovisionar certificados en dispositivos que admiten HTTPS pero no MDM; (3) para dispositivos con una interfaz de gestión, algunos proveedores admiten el registro de SCEP directamente a través del firmware del dispositivo sin necesidad de un agente MDM. En cualquier caso, los dispositivos IoT deben aislarse en una VLAN dedicada, independientemente del método de autenticación utilizado.

Continúe leyendo esta serie

Comprensión de Cisco SUDI: Identidad con Anclaje por Hardware en el Control de Acceso Seguro a la Red

Esta guía explica cómo Cisco SUDI proporciona una identidad con anclaje por hardware y criptográficamente segura para la infraestructura de red empresarial. Aprenda a sustituir las direcciones MAC suplantables por certificados 802.1AR inmutables para proteger el control de acceso a la red de su recinto.

Cómo implementar SCEP para el registro automatizado de certificados WiFi

Esta guía explica cómo implementar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados WiFi en entornos empresariales. Cubre el diseño arquitectónico completo, desde el diseño de PKI y la integración con MDM hasta la secuencia de despliegue obligatoria de tres pasos, y muestra a los responsables 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.

Introducción a Cisco SUDI: Identidad de dispositivos basada en hardware en el control de acceso a la red

Esta guía detalla la arquitectura técnica de Cisco SUDI y explica cómo la identidad anclada en hardware protege el control de acceso a la red. Proporciona pasos de implementación prácticos para que los responsables de TI desplieguen la autenticación 802.1X EAP-TLS y automaticen el Zero Touch Provisioning en entornos empresariales.