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.

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

Escucha esta guía

Ver transcripción del podcast

Bienvenido 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, a través de una gran red. Ya sea que se trate de un campus universitario, un grupo hotelero con múltiples sedes o un gran patrimonio del sector público, los desafíos son idénticos.

Vamos a cubrir el panorama completo. Qué hace realmente SCEP, cómo encaja en una arquitectura 802.1X, la secuencia de implementación en la que la mayoría de los equipos se equivocan, dos escenarios de implementación del mundo real y los obstáculos 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 qué 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.

Comencemos.

Primeros principios. SCEP significa Simple Certificate Enrollment Protocol (Protocolo de Inscripción de Certificados Simple). Fue formalizado por el IETF como RFC 8894 en 2020, aunque ya se utilizaba ampliamente en 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 administrado 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 al que se dirige es EAP-TLS, Extensible Authentication Protocol con Transport Layer Security (Protocolo de Autenticación Extensible con Seguridad de la Capa de Transporte), que se encuentra dentro del marco 802.1X. EAP-TLS es ampliamente considerado 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 lo protege contra los ataques de gemelo malvado (evil twin), donde un atacante levanta un punto de acceso no autorizado para recopilar credenciales.

Así es como funciona la cadena completa. Un dispositivo administrado, la laptop de un estudiante, el teléfono del personal, una 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 un payload SCEP a ese dispositivo. El payload contiene dos cosas: la URL de SCEP, que apunta a su servidor NDES o gateway 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 dispositivo, se almacena en el enclave seguro o TPM, y nunca se transmite a través de la red. Luego, el dispositivo crea una Solicitud de Firma de Certificado, un CSR, y la envía al gateway SCEP. El gateway valida el desafío, reenvía el CSR a su Autoridad de Certificación (CA), y la CA lo 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, verifica la Lista de Revocación de Certificados para confirmar que el certificado no haya sido revocado y, si todo está en orden, envía un mensaje de aceptación al punto de acceso. El dispositivo está en la red. Todo el proceso es invisible para el usuario.

Ahora, hablemos de dónde se ubica 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. Eso significa que la clave privada viaja a través de 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 de 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 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 usted define la política de validación de certificados y, fundamentalmente, donde configura la asignación dinámica de VLAN.

Las VLAN dinámicas son la forma en que se segmenta 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 intervención manual por dispositivo.

Para la integración con proveedores de identidad, los atributos del certificado SCEP, específicamente el Subject Alternative Name, pueden contener el nombre principal del usuario de Microsoft Entra ID, Okta o Google Workspace. Eso vincula el certificado a una identidad específica, lo que significa que cuando se deshabilita una cuenta en Entra ID y el MDM desvincula el dispositivo, el certificado se revoca y el acceso a 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 implementación, porque aquí es donde la mayoría de los equipos se equivocan.

La secuencia no es negociable: primero el certificado raíz de confianza (Trusted Root), segundo el perfil de certificado SCEP y tercero el perfil de WiFi. Tanto Intune como Jamf aplican dependencias de perfil. Si su perfil de WiFi hace referencia a un certificado SCEP que aún no se ha implementado 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.

El segundo error común es la segmentación por grupos. Los tres perfiles, Trusted Root, SCEP y WiFi, deben implementarse 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 toma por sorpresa 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 firewall. App Proxy le brinda 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 verifica la Lista de Revocación de Certificados cada vez que un dispositivo se autentica. Si su punto de distribución de CRL no está disponible, ya sea porque un servidor está caído o porque la URL cambió, la autenticación fallará para todos los dispositivos de la red simultáneamente. Eso representa una caída del servicio en todo el campus. Asegúrese de que sus endpoints de CRL tengan alta disponibilidad y pruebe la revocación antes de salir a producción.

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

Abordemos algunas preguntas rápidas que escuchamos a menudo de los CTO.

¿Puede SCEP manejar dispositivos BYOD que no están registrados en un MDM? No directamente. SCEP requiere el registro en el MDM para enviar la carga útil del certificado. Para BYOD no administrados, necesita un enfoque diferente, ya sea un portal de autoservicio para la incorporación de usuarios o un SSID independiente que utilice un Captive Portal con verificación de identidad. Purple maneja esa capa de invitados y BYOD de manera limpia, coexistiendo con su red de personal autenticada por certificados.

¿Qué pasa con iOS y Android? Ambas plataformas son compatibles con SCEP de forma nativa. iOS es compatible con SCEP desde iOS 4. Android Enterprise es compatible con SCEP a través de Intune y otros MDM. La configuración es ligeramente diferente 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 administrados. Elimina las credenciales compartidas, le brinda 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 implementación (Trusted Root, luego el perfil SCEP y después el perfil WiFi) es fija. La segmentación por grupos debe ser consistente. 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 cuerpo docente, junto con una capa de WiFi para invitados separada para los estudiantes en sus dispositivos personales, le brinda tanto seguridad como una excelente experiencia de usuario sin compromisos.

Si desea profundizar más, la guía de Purple sobre autenticación de WiFi empresarial cubre el camino nativo de la nube. Y si está pensando en lo que sucede cuando un empleado se va, 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.

Puntos clave

✓SCEP (RFC 8894) automatiza el registro de certificados para dispositivos administrados: 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 de WiFi sobre PKCS.
✓La secuencia de implementación no es negociable: primero el certificado Trusted Root, segundo el perfil de certificado SCEP y tercero el perfil de WiFi. Violar este orden provoca fallas de dependencia del perfil.
✓Los tres perfiles de MDM (Trusted Root, SCEP, WiFi) deben dirigirse exactamente al mismo grupo de directorio. La segmentación entre diferentes grupos es la causa más común de fallas de implementación.
✓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 puerta de enlace SCEP en la nube elimina el punto único de falla de NDES.
✓La disponibilidad del punto de distribución CRL es una dependencia crítica de la red. Si el servidor RADIUS no puede comunicarse con la CRL, falla de manera cerrada y deniega toda autenticación 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 necesario para WPA3-Enterprise de 192 bits (Suite B).
✓SCEP cubre únicamente dispositivos administrados. Los dispositivos BYOD no administrados y de invitados requieren un SSID independiente con Captive Portal y verificación de identidad; la plataforma de Purple maneja esta capa junto con su red de 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 implementar 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 la implementación 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 se encarga de la emisión diaria de certificados).

El prerrequisito no negociable para la implementación de EAP-TLS y SCEP. La CA raíz debe mantenerse aislada de la red (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 vencimiento. Los servidores RADIUS verifican 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 manera cerrada y niega 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, verifica 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.

Asignación dinámica de VLAN

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

Permite que un solo 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); una terminal POS obtiene la VLAN 30 (solo sistemas de pago).

MDM (Mobile Device Management)

Software utilizado por los equipos de TI para inscribir, configurar, asegurar y gestionar teléfonos inteligentes, tabletas y computadoras 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 prerrequisito para la implementación de certificados basados en SCEP. Los dispositivos deben estar inscritos en el MDM antes de poder recibir los perfiles SCEP y WiFi. Los dispositivos BYOD no gestionados requieren un enfoque de incorporación independiente.

Ejemplos resueltos

Un hotel Premier Inn de 200 habitaciones necesita proteger su WiFi para el personal en tabletas de punto de venta y teléfonos inteligentes de limpieza. Actualmente utilizan una clave precompartida que se ha filtrado a contratistas. Administran los dispositivos a través de Microsoft Intune y tienen una combinación de dispositivos iOS y Android. La propiedad utiliza puntos de acceso HPE Aruba.

Implementar una PKI interna de dos niveles de Microsoft AD CS. Configurar NDES en un Windows Server 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 la CA Emisora. Implementar 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 en CN={{AAD_Device_ID}} ya que se trata de dispositivos compartidos. Establecer el Uso de Clave en Firma Digital y Cifrado de Clave, y el Uso de Clave Extendido en Autenticación de Cliente. Implementar 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. Implementar en 'Property Staff Devices'.
Configurar los ajustes de RADIUS de HPE Aruba para que apunten a Windows NPS. En NPS, configurar una Política 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 (punto de venta, 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 implementación 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 hospitalidad.

Una cadena de tiendas de retail con 50 sucursales desea implementar 802.1X para laptops corporativas en todos sus sitios. Utilizan puntos de acceso Cisco Meraki y Microsoft Intune. No desean implementar ni mantener servidores NDES locales o infraestructura de AD CS en cada sucursal ni en su centro de datos.

Implementar un servicio de PKI en la nube y una puerta de enlace SCEP que se integre con Intune a través del protocolo SCEP. La CA en la nube emite los certificados; la puerta de enlace SCEP en la nube gestiona la validación de 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. Implementar en el grupo de dispositivos 'Corporate Laptops'.
Crear un perfil de Certificado SCEP que apunte a la URL de la puerta de enlace SCEP en la nube. Establecer el Nombre de Sujeto en CN={{UserPrincipalName}} para la autenticación basada en el usuario. Implementar 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. Implementar en 'Corporate Laptops'.
Cuando las laptops se registren en Intune, solicitarán automáticamente certificados a la CA en la nube a través de la puerta de enlace SCEP en la nube. No se requiere infraestructura local en ninguna de las 50 sucursales.

Comentario del examinador: Esta es la arquitectura moderna óptima para entornos de retail distribuidos. Al aprovechar la PKI en la nube y el RADIUS en la nube, la organización elimina la necesidad de mantener una infraestructura local compleja (NDES, AD CS, NPS) en cada sitio. La puerta de enlace SCEP en la nube se escala horizontalmente y es inherentemente de alta disponibilidad, eliminando el punto único de falla que introduce el NDES local. La arquitectura administrada 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 con éxito los perfiles de Trusted Root y SCEP en su grupo de Azure AD "Corporate Users" en Intune. Implementa el perfil de WiFi en "All Corporate Devices". Los usuarios informan que no pueden conectarse y el perfil de WiFi se muestra como No aplicable.

Sugerencia: Verifique 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 SCEP, el cual estaba dirigido a un grupo de usuarios ("Corporate Users"). El perfil de WiFi estaba dirigido a un grupo de dispositivos ("All Corporate Devices"). Intune no puede resolver la dependencia entre diferentes tipos de grupos. La solución es cambiar las asignaciones de los tres perfiles (Trusted Root, SCEP y WiFi) para que se dirijan al mismo grupo. Decida si utilizará un grupo de usuarios o un grupo de dispositivos según su modelo de autenticación (basado en usuario frente a basado en dispositivo) y aplíquelo de manera coherente en los tres perfiles.

Q2. Una auditoría de seguridad revela que cuando se rescinde el contrato de un empleado y se deshabilita su cuenta de Microsoft Entra ID, su teléfono inteligente corporativo aún puede conectarse a la red WiFi del personal hasta una semana después de la rescisión.

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

Ver respuesta modelo

El servidor RADIUS no está realizando una verificación estricta de la Lista de Revocación de Certificados (CRL), o bien la CRL se publica con poca frecuencia. Cuando se rescinde el contrato de un empleado, el MDM debe dar de baja el dispositivo y la CA debe revocar el certificado. Sin embargo, si el servidor RADIUS no verifica 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 implica tres pasos: configurar el servidor RADIUS para exigir una verificació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 dé de baja un dispositivo.

Q3. Necesita 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? De no ser así, ¿cuál es la alternativa recomendada?

Sugerencia: Considere los requisitos previos para el registro 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 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 a dispositivos que admiten HTTPS pero no MDM; (3) para dispositivos con una interfaz de administración, algunos proveedores admiten el registro SCEP directamente a través del firmware del dispositivo sin requerir un agente MDM. En todos los casos, 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 anclada por hardware en el control de acceso seguro a la red

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

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.

Entendiendo Cisco SUDI: Identidad de Dispositivo Basada en Hardware en el Control de Acceso a la Red

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