Como Configurar o SCEP para Registro Automatizado de Certificados de WiFi Corporativo

Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para o registro automatizado de certificados de WiFi corporativo, cobrindo toda a arquitetura, desde PKI e NDES até a implantação de perfis MDM e validação RADIUS. Destina-se a gerentes de TI, arquitetos de rede e CTOs de hotéis, redes de varejo, estádios, centros de convenções e organizações do setor público que precisam ir além das chaves pré-compartilhadas e implementar a autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição em nuvem da Purple, independente de hardware, integra-se diretamente a essa arquitetura, fornecendo a camada de WiFi para convidados e BYOD que opera em conjunto com a rede de funcionários autenticada por certificado.

📖 10 min de leitura📝 2,282 palavras🔧 2 exemplos práticos❓ 3 questões práticas📚 9 definições principais

Ouça este guia

Ver transcrição do podcast

Bem-vindo à série de Briefings Técnicos da Purple. Hoje vou falar sobre algo que chega a muitas caixas de entrada de TI, mas que raramente recebe uma resposta direta: como realmente implantar a autenticação WiFi baseada em certificados em escala, usando SCEP, em uma grande rede. Seja em um campus universitário, em um grupo hoteleiro com várias unidades ou em um grande patrimônio do setor público, os desafios são idênticos.

Vamos cobrir o cenário completo. O que o SCEP realmente faz, como ele se encaixa em uma arquitetura 802.1X, a sequência de implantação que a maioria das equipes erra, dois cenários de implementação do mundo real e as armadilhas que custarão um fim de semana da sua vida se você não se planejar para elas.

Este é um briefing de consultoria, não um tutorial. Estou assumindo que você sabe o que é um servidor RADIUS e que provavelmente já decidiu que precisa deixar de usar chaves pré-compartilhadas. O que você precisa agora é do mapa de implementação.

Vamos ao que interessa.

Primeiros princípios. SCEP significa Simple Certificate Enrollment Protocol. Foi formalizado pelo IETF como RFC 8894 em 2020, embora já estivesse em amplo uso empresarial por mais de uma década antes disso. O seu trabalho é simples: automatizar o processo de obtenção de um certificado digital em um dispositivo gerenciado sem a necessidade de intervenção humana em cada máquina.

No contexto da autenticação WiFi, o SCEP é o mecanismo de entrega. O protocolo de autenticação real que você está buscando é o EAP-TLS, Extensible Authentication Protocol com Transport Layer Security, que fica dentro do framework 802.1X. O EAP-TLS é amplamente considerado o método de autenticação mais seguro para redes sem fio corporativas porque exige que tanto o dispositivo cliente quanto o servidor RADIUS apresentem certificados válidos. Nenhum dos lados confia no outro sem prova criptográfica. Essa autenticação mútua é o que protege você contra ataques de "evil twin", onde um invasor cria um ponto de acesso não autorizado para coletar credenciais.

Aqui está como funciona a cadeia completa. Um dispositivo gerenciado, o notebook de um estudante, o telefone de um funcionário, um terminal de ponto de venda de um hotel, precisa se conectar à rede sem fio corporativa. Sua plataforma MDM, que pode ser o Microsoft Intune ou o Jamf, envia um payload SCEP para esse dispositivo. O payload contém duas coisas: a URL do SCEP, que aponta para o seu servidor NDES ou gateway SCEP na nuvem, e uma senha de desafio ou segredo compartilhado.

O dispositivo gera seu próprio par de chaves pública e privada localmente. Isso é fundamental. A chave privada nunca sai do dispositivo. Ela é gerada no dispositivo, armazenada no enclave seguro ou TPM, e nunca é transmitida pela rede. O dispositivo então cria uma Solicitação de Assinatura de Certificado, um CSR, e a envia para o gateway SCEP. O gateway valida o desafio, encaminha o CSR para a sua Autoridade Certificadora, e a CA o assina e retorna o certificado público para o dispositivo.

A partir desse momento, quando o dispositivo se conecta ao seu SSID de WiFi, ele 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 para confirmar que o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem de aceitação para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o usuário.

Agora, vamos falar sobre onde o SCEP se posiciona em relação à alternativa, que é o PKCS. O PKCS, Public Key Cryptography Standards, é o outro método de entrega de certificado suportado por plataformas como o Intune. Com o PKCS, a CA gera tanto a chave pública quanto a privada de forma centralizada, e o conector de certificado envia o par de chaves para o dispositivo. Isso significa que a chave privada trafega pela rede, o que introduz uma superfície de ataque teórica. O PKCS é adequado para casos de uso como criptografia de e-mail S/MIME, onde a custódia de chaves é realmente desejável. Para autenticação WiFi, o SCEP é a escolha certa. A chave privada permanece no dispositivo, ponto final.

Agora, a camada de hardware. SCEP e EAP-TLS são padrões neutros de fornecedor, o que significa que funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração do RADIUS, seja ela Windows NPS, FreeRADIUS ou um serviço de RADIUS em nuvem, é onde você define a política de validação de certificado e, fundamentalmente, onde você configura a atribuição dinâmica de VLAN.

As VLANs dinâmicas são a forma como você segmenta a rede por identidade. O dispositivo de um aluno recebe a VLAN 20 apenas para acesso à internet. O dispositivo de um professor recebe a VLAN 10 para acesso aos sistemas de pesquisa internos. Um dispositivo de gestão de instalações recebe a VLAN 30 para acesso aos sistemas de gestão predial. Tudo isso é direcionado pelos atributos do certificado e pela política do RADIUS, sem nenhuma intervenção manual por dispositivo.

Para a integração com provedores de identidade, os atributos do certificado SCEP, especificamente o Subject Alternative Name, podem carregar o nome principal do usuário a partir do Microsoft Entra ID, Okta ou Google Workspace. Isso vincula o certificado a uma identidade específica, o que significa que quando você desativa uma conta no Entra ID e o MDM cancela o registro do dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa é a história de revogação que as chaves pré-compartilhadas simplesmente não conseguem contar.

Certo, vamos falar sobre a sequência de implantação, porque é aqui que a maioria das equipes comete erros.

A sequência não é negociável: primeiro o certificado Trusted Root, segundo o perfil de certificado SCEP, terceiro o perfil de WiFi. O Intune e o Jamf impõem dependências de perfil. Se o seu perfil de WiFi fizer referência a um certificado SCEP que ainda não foi implantado no dispositivo, o perfil de WiFi falhará com um erro enigmático que parece uma configuração incorreta, mas na verdade é apenas um problema de tempo.O segundo erro comum é o direcionamento de grupos. Todos os três perfis, Trusted Root, SCEP e WiFi, devem ser implantados exatamente no mesmo grupo do Azure AD ou Jamf. Se o perfil SCEP for direcionado a um grupo de usuários e o perfil WiFi for direcionado a um grupo de dispositivos, o Intune não conseguirá resolver a dependência e o perfil WiFi será exibido como Não Aplicável. Isso costuma pegar as equipes de surpresa constantemente.

Terceiro: acessibilidade do servidor NDES. Seu servidor NDES precisa estar acessível pela internet para que os dispositivos possam se registrar antes de chegarem ao local. A maneira correta de fazer isso é por meio do Azure AD Application Proxy, e não abrindo uma porta no seu firewall. O App Proxy oferece acesso remoto seguro sem portas de entrada e permite aplicar políticas de Acesso Condicional ao fluxo de registro.

Quarto: disponibilidade de CRL. Seu servidor RADIUS verifica a Lista de Revogação de Certificados (CRL) toda vez que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL estiver indisponível, seja porque um servidor está fora do ar ou porque a URL mudou, a autenticação falhará para todos os dispositivos na rede simultaneamente. Isso representa uma interrupção em todo o campus. Torne seus endpoints de CRL altamente disponíveis e teste a revogação antes de entrar em operação.

Para redes grandes, com mais de 500 dispositivos, considere um gateway SCEP em nuvem em vez de um NDES local. Os gateways em nuvem eliminam o ponto único de falha do NDES, escalam horizontalmente e geralmente se integram diretamente com serviços RADIUS em nuvem, removendo mais uma dependência de infraestrutura.

Vamos responder a algumas perguntas rápidas que costumamos ouvir de CTOs.

O SCEP pode lidar com dispositivos BYOD que não estão registrados no MDM? Não diretamente. O SCEP exige o registro no MDM para enviar a carga do certificado. Para BYOD não gerenciado, você precisa de uma abordagem diferente: um portal de integração de autoatendimento ou um SSID separado usando um Captive Portal com verificação de identidade. A Purple lida com essa camada de convidados e BYOD de forma limpa, operando ao lado da sua rede de funcionários autenticada por certificado.

E quanto ao iOS e Android? Ambas as plataformas oferecem suporte nativo ao SCEP. O iOS suporta o SCEP desde o iOS 4. O Android Enterprise suporta o SCEP por meio do Intune e de outros MDMs. A configuração é um pouco diferente para cada plataforma, mas o protocolo subjacente é idêntico.

O EAP-TLS funciona com WPA3? Sim. O WPA3-Enterprise exige o modo de segurança de 192 bits para ambientes confidenciais, e o EAP-TLS é totalmente compatível. Na verdade, o WPA3-Enterprise com EAP-TLS é a combinação recomendada pela Wi-Fi Alliance para redes governamentais e financeiras.

Para resumir tudo. A autenticação WiFi por certificado SCEP é a arquitetura correta para qualquer rede com mais de 50 dispositivos gerenciados. Ela elimina credenciais compartilhadas, oferece identidade por dispositivo, permite segmentação dinâmica de VLAN e se integra diretamente com seu provedor de identidade para revogação automatizada. A sequência de implantação — Trusted Root, depois perfil SCEP e, em seguida, perfil WiFi — é fixa. O direcionamento de grupos deve ser consistente. A disponibilidade de CRL não é opcional.

Para o ensino superior especificamente, a combinação de SCEP para dispositivos de funcionários e professores, juntamente com uma camada separada de WiFi para convidados para estudantes em dispositivos pessoais, oferece segurança e uma excelente experiência de usuário sem concessões.

Se você quiser se aprofundar, o guia da Purple sobre autenticação de WiFi corporativo aborda o caminho nativo em nuvem. E se você está pensando no que acontece quando um funcionário sai, nosso guia sobre revogação de acesso ao WiFi orienta você por todo o fluxo de trabalho de revogação.

Obrigado por ouvir. Eu sou da equipe técnica da Purple, e nos vemos no próximo briefing.

Principais conclusões

✓O SCEP (RFC 8894) automatiza o registro de certificados para dispositivos gerenciados - a chave privada é gerada no próprio dispositivo e nunca é transmitida, tornando-o a escolha correta para autenticação WiFi em relação ao PKCS.
✓A sequência de implantação não é negociável: primeiro o certificado Trusted Root, segundo o perfil de certificado SCEP, terceiro o perfil de WiFi. Violar essa ordem causa falhas de dependência de perfil.
✓Todos os três perfis de MDM (Trusted Root, SCEP, WiFi) devem ter como alvo exatamente o mesmo grupo de diretório. O direcionamento cruzado entre grupos é a causa mais comum de falhas de implantação.
✓O NDES deve ser publicado via Azure AD Application Proxy, não exposto diretamente à internet. Para redes com mais de 500 dispositivos, um gateway SCEP em nuvem elimina o ponto único de falha do NDES.
✓A disponibilidade do Ponto de Distribuição CRL é uma dependência crítica da rede. Se o servidor RADIUS não conseguir alcançar a CRL, ele falha no modo fechado e nega todas as autenticações simultaneamente.
✓O EAP-TLS com certificados provisionados por SCEP atende ao Requisito 8.6 do PCI DSS 4.0 para redes sem fio em ambientes de dados de portadores de cartão e é obrigatório para WPA3-Enterprise de 192 bits (Suite B).
✓O SCEP cobre apenas dispositivos gerenciados. Dispositivos BYOD não gerenciados e de convidados exigem um SSID separado com Captive Portal e verificação de identidade - a plataforma da Purple gerencia essa camada juntamente com a rede de funcionários autenticada por certificado.

Resumo executivo

Para ambientes corporativos - seja um hotel de 200 quartos, uma rede de varejo com 50 lojas ou um grande centro de convenções - depender de chaves pré-compartilhadas para o WiFi da equipe é um risco de segurança e um gargalo operacional. Uma única senha vazada 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 esse risco por completo. Cada dispositivo comprova sua identidade criptograficamente antes que o ponto de acesso conceda acesso à rede.

O desafio é a distribuição. Implantar certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android manualmente não é viável. O SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 pela IETF em 2020, resolve isso. Ele automatiza o processo de solicitação, emissão e instalação de certificados digitais em dispositivos gerenciados por meio de sua plataforma MDM - sem qualquer interação do usuário.

Este guia aborda a arquitetura completa: o que o SCEP faz, como ele se integra ao Microsoft Intune, Jamf e outras plataformas MDM, a sequência exata de implantação que a maioria das equipes erra e as armadilhas operacionais que causam interrupções. Também cobrimos dois cenários reais de implementação em hotelaria e varejo, e explicamos onde a plataforma de Guest WiFi da Purple se encaixa ao lado de sua rede corporativa autenticada por certificado.

Ouça o podcast complementar informativo:

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

O que o SCEP realmente faz

O SCEP não substitui a sua Infraestrutura de Chaves Públicas (PKI). Ele é a camada de registro automatizada que opera sobre ela. Sua PKI - normalmente uma hierarquia de duas camadas com uma CA raiz offline e uma CA emissora online - continua sendo 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 quanto o servidor RADIUS apresentem certificados X.509 válidos. Nenhum dos lados confia no outro 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 invasor cria um ponto de acesso falso para coletar nomes de usuário e senhas.

Para uma análise detalhada do handshake EAP-TLS, consulte nosso guia sobre Autenticação de Certificado WiFi: Acesso Seguro à Rede .

O fluxo de registro SCEP, passo a passo

A cadeia de registro completa funciona da seguinte forma. Sua plataforma MDM - Microsoft Intune, Jamf ou outro MDM - envia um payload SCEP para um dispositivo gerenciado. Esse payload contém duas coisas: a URL do SCEP apontando para o seu servidor NDES (Network Device Enrollment Service) ou gateway SCEP em nuvem, e uma senha de desafio ou segredo compartilhado.

O dispositivo gera 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 então cria uma Solicitação de Assinatura de Certificado (CSR) e a envia para o gateway SCEP. O gateway valida a senha de desafio, encaminha a CSR para a sua Autoridade Certificadora, e a CA a assina e retorna o certificado público para o dispositivo.

A partir desse momento, quando o dispositivo se conecta ao seu SSID de WiFi, ele 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 de Access-Accept para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o usuário.

SCEP vs. PKCS: qual usar para WiFi

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 Certificadora gera tanto a chave pública quanto a privada de forma centralizada, e o conector de certificado 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 é apropriado para casos de uso onde a custódia de chaves é necessária, como a criptografia de e-mail S/MIME. Para 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	Pela rede
Servidor NDES necessário	Sim (ou gateway em nuvem)	Não
Recomendado para WiFi	Sim	Não
Recomendado para S/MIME	Não	Sim

Compatibilidade de hardware

SCEP e EAP-TLS são padrões neutros em relação a fornecedores. Eles funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Sua configuração RADIUS - seja Windows NPS, FreeRADIUS ou um serviço RADIUS em nuvem - é onde você define a política de validação de certificado e a atribuição dinâmica de VLAN.

A atribuição dinâmica de VLAN é como você segmenta a rede por identidade de dispositivo. Um dispositivo de 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 isso é impulsionado por atributos de certificado e política RADIUS, sem 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 nossa visão geral da plataforma de analytics.

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

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

A sequência é: Root confiável primeiro, perfil SCEP em segundo, perfil de WiFi em terceiro. Essa ordem não é negociável.

Passo 1: implantar o perfil de Certificado Root Confiável

Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar no seu servidor RADIUS, ele deve confiar na Autoridade Certificadora emissora. Exporte o certificado da sua CA Root - e quaisquer certificados de CA Intermediária - como arquivos .cer. No seu centro de administração MDM, crie um perfil de Certificado Confiável, faça o upload do arquivo .cer e implante-o no seu grupo de dispositivos de destino.

Se você tiver uma hierarquia PKI de duas camadas (recomendado), precisará implantar os certificados da CA root e da CA emissora como perfis de Certificado Confiável separados, ou como uma cadeia em um único perfil, dependendo da sua plataforma MDM.

Passo 2: configurar o perfil de Certificado SCEP

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

Crie um novo perfil de configuração e selecione o tipo de perfil de certificado SCEP. Configure o formato do Subject name. Para autenticação baseada em usuário, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivo (dispositivos compartilhados, IoT, terminais POS), use CN={{AAD_Device_ID}}. Defina o Key usage como Digital signature e Key encipherment. Defina o Extended Key Usage como Client Authentication (OID: 1.3.6.1.5.5.7.3.2). Vincule este perfil ao perfil de certificado Root Confiável criado no Passo 1. Forneça a URL externa do seu servidor NDES.Para o Microsoft Intune especificamente, o servidor NDES deve ser publicado via Azure AD Application Proxy para permitir que dispositivos remotos se registrem antes de chegarem ao local. Não exponha o NDES diretamente à internet.

Passo 3: implantar o perfil de WiFi 802.1X

O passo final é enviar a configuração de WiFi que vincula os certificados ao SSID da rede. Crie um perfil de configuração de Wi-Fi. Insira o nome da rede (SSID) exatamente como ele é transmitido pelos seus pontos de acesso. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança. Defina o tipo de EAP como EAP-TLS. Nas configuraçõ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 Root Confiável para validação do servidor - isso garante que o dispositivo se conecte apenas ao seu servidor RADIUS legítimo e não a um ponto de acesso não autorizado.

Integração com provedor de identidade

Os atributos do certificado SCEP - especificamente o Subject Alternative Name (SAN) - podem carregar o nome principal do usuário do Microsoft Entra ID, Okta ou Google Workspace. Isso vincula o certificado a uma identidade específica. Quando você desativa uma conta no Entra ID e o MDM cancela o registro do dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa revogação automatizada é o diferencial de segurança que as chaves pré-compartilhadas 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 nosso guia dedicado.

Boas práticas e padrões do setor

Posicionamento do servidor NDES

O servidor NDES deve estar acessível pela internet para que os dispositivos possam se registrar antes de chegarem ao local. Publique a URL do NDES via Azure AD Application Proxy. Isso fornece acesso remoto seguro sem abrir portas de firewall de entrada e permite aplicar políticas de Acesso Condicional ao fluxo de registro. Nunca exponha o NDES diretamente à internet.

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

Disponibilidade de CRL

Seu servidor RADIUS verifica a Lista de Revogação de Certificados (CRL) toda vez que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL (CDP) estiver indisponível - porque um servidor está fora do ar ou a URL mudou - a autenticação falha para todos os dispositivos na rede simultaneamente. Configure seu servidor NPS ou RADIUS para impor uma verificação rigorosa de CRL e torne 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 portadores de cartão. O EAP-TLS com certificados provisionados por SCEP atende a esse requisito para redes sem fio em ambientes de Varejo e Hotelaria .

Compatibilidade com WPA3

EAP-TLS é totalmente compatível com WPA3-Enterprise. O WPA3-Enterprise com a suíte 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 você está implantando em ambientes de Saúde ou Transporte com requisitos de conformidade rigorosos, o WPA3-Enterprise com EAP-TLS é a arquitetura de destino correta.

BYOD e WiFi de convidados

O SCEP exige o registro no MDM para enviar o payload do certificado. Ele não abrange dispositivos BYOD não gerenciados ou convidados. Para esses casos de uso, você precisa de um SSID separado com um Captive Portal e verificação de identidade. A plataforma da Purple lida com essa camada de forma limpa, operando em paralelo com a rede de funcionários autenticada por certificado. Nossa plataforma de Guest WiFi suporta opt-ins de escolha consciente, captura de dados primários (first-party) e integração com Microsoft Entra ID, Okta e Google Workspace para verificação de identidade.

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

Falha ao aplicar o perfil de WiFi

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

Causa raiz: Incompatibilidade de direcionamento de grupo. Se o perfil SCEP for direcionado a um grupo de Usuários e o perfil de WiFi for direcionado a um grupo de Dispositivos, o MDM não conseguirá resolver a dependência.

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

Erros NDES 403 Forbidden

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

Causa raiz: A conta de serviço do MDM Certificate Connector não possui permissões de Leitura e Registro (Read and Enroll) no modelo de certificado, ou o filtro de URL do firewall está bloqueando os parâmetros de query string do SCEP.

Correção: Verifique se a conta do conector possui permissões de Leitura e Registro no modelo da CA. Verifique os logs do firewall para garantir que as URLs contendo ?operation=GetCACaps não estejam bloqueadas.

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

Sintoma: Todos os dispositivos na rede falham ao autenticar simultaneamente.

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

Correção: Configure o monitoramento e alertas de CRL. Publique CRLs com um período de validade significativamente maior do que o intervalo de publicação. Teste a acessibilidade do CDP a partir do servidor RADIUS antes do go-live.

Expiração de certificado causando falhas silenciosas

Sintoma: Dispositivos individuais falham intermitentemente ao se conectar, sem um padrão claro.

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

Correção: Configure a renovação do certificado para ser acionada em 80% do tempo de vida do certificado. Monitore os relatórios de status de registro do MDM para dispositivos com erros de certificado. Defina períodos de validade de certificado adequados ao ciclo de atualização do seu dispositivo - normalmente de um a dois anos para endpoints gerenciados.

ROI e impacto nos negócios

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

Redução de chamados no Helpdesk: O WiFi baseado em senha gera um volume significativo de chamados de suporte - expiração de senhas, bloqueios e erros de digitação. A autenticação baseada em certificado é invisível para o usuário. As organizações geralmente observam uma redução de 70-80% no volume de helpdesk relacionado ao WiFi após a migração.

Postura de segurança: O EAP-TLS elimina a coleta de credenciais e ataques Man-in-the-Middle. Isso apoia diretamente a conformidade com o PCI DSS 4.0 para redes de varejo e hospitalidade, e os requisitos do Artigo 32 do GDPR para medidas técnicas de segurança apropriadas.

Revogação automatizada: Quando um funcionário se desliga, a desativação de sua conta no Microsoft Entra ID aciona a revogação automática do certificado e o descredenciamento do MDM. O acesso ao WiFi é cortado sem qualquer intervenção manual da equipe de rede.

Segmentação de rede: A atribuição dinâmica de VLAN via atributos de certificado RADIUS oferece uma segmentação de rede aplicada criptograficamente. Os dispositivos entram no segmento de rede correto com base nas propriedades do certificado, e não na seleção de SSID ou filtragem de endereço MAC - ambos facilmente burlados.

A Purple opera em mais de 80.000 locais ativos com 99,999% de uptime, e nossa plataforma é certificada ISO 27001, GDPR, CCPA e Cyber Essentials. Nosso overlay de nuvem agnóstico de hardware se integra com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - para que a sua rede de funcionários autenticada por certificado e a nossa camada de WiFi para convidados funcionem a partir da mesma infraestrutura.

Para saber mais sobre como a Análise Comportamental: Insights para Redes WiFi pode complementar sua implantação de rede segura, consulte 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

Definições principais

SCEP (Simple Certificate Enrollment Protocol)

Um protocolo formalizado na RFC 8894 que permite que dispositivos gerenciados solicitem e recebam automaticamente certificados digitais X.509 de uma Autoridade Certificadora via HTTP, usando uma senha de desafio compartilhada para a autenticação inicial. A chave privada é gerada no dispositivo e nunca é transmitida.

O mecanismo padrão usado por plataformas de MDM como Microsoft Intune e Jamf para implantar certificados de autenticação WiFi em endpoints gerenciados em escala.

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

O método de autenticação 802.1X mais seguro, exigindo que tanto o dispositivo cliente quanto o servidor RADIUS apresentem certificados X.509 válidos. A autenticação mútua significa que nenhuma das partes confia na outra sem prova criptográfica.

O protocolo de autenticação de destino para WiFi corporativo. Exigido ou fortemente recomendado pelo PCI DSS 4.0, WPA3-Enterprise de 192 bits (Suite B) e HIPAA para redes sem fio que lidam com dados confidenciais.

NDES (Network Device Enrollment Service)

Uma função do Microsoft Windows Server que atua como uma Autoridade de Registro (RA) entre dispositivos habilitados para SCEP e uma Autoridade Certificadora. Ele valida senhas de desafio e encaminha CSRs para a CA em nome de dispositivos que não possuem credenciais de domínio.

Infraestrutura necessária para a implantação do SCEP com o Microsoft Intune. Deve ser publicado via Azure AD Application Proxy em vez de ser exposto diretamente à internet.

PKI (Public Key Infrastructure)

A hierarquia de Autoridades Certificadoras, políticas e procedimentos usados para emitir, gerenciar e revogar certificados digitais. Uma PKI de duas camadas consiste em uma CA raiz offline (a âncora de confiança mestre) e uma CA emissora online (que lida com a emissão diária de certificados).

O pré-requisito inegociável para a implantação de EAP-TLS e SCEP. A CA raiz deve ser mantida isolada (air-gapped); sua chave privada é a base de toda a sua cadeia de confiança de certificados.

CSR (Certificate Signing Request)

Uma mensagem gerada por um dispositivo contendo sua chave pública e informações de identidade, enviada a uma Autoridade Certificadora para solicitar um certificado digital assinado. No SCEP, o CSR é gerado no dispositivo e encapsulado em um envelope PKCS antes da transmissão.

Gerado automaticamente pelo dispositivo durante o fluxo de registro do SCEP. A chave privada usada para assinar o CSR nunca sai do dispositivo.

CRL (Certificate Revocation List)

Uma lista publicada pela Autoridade Certificadora contendo os números de série dos certificados que foram revogados antes da data de expiração. Os servidores RADIUS verificam a CRL a cada tentativa de autenticação para garantir que certificados revogados não acessem a rede.

A disponibilidade do Ponto de Distribuição CRL (CDP) é crítica. Se o servidor RADIUS não conseguir acessar a CRL, ele falha no modo fechado e nega todas as autenticações - causando uma interrupção em toda a rede.

RADIUS (Remote Authentication Dial-In User Service)

Um protocolo de rede que fornece Autenticação, Autorização e Contabilização (AAA) centralizada para acesso à rede. No WiFi 802.1X, o servidor RADIUS valida os certificados dos clientes, verifica a CRL e retorna uma mensagem de Access-Accept ou Access-Reject para o ponto de acesso.

O servidor de autenticação no modelo suplicante-autenticador-servidor 802.1X. Implementações comuns incluem Windows NPS, FreeRADIUS e serviços de RADIUS na nuvem.

Dynamic VLAN assignment

Um recurso do RADIUS que coloca um dispositivo autenticado em uma VLAN específica com base nos atributos do certificado ou na associação a grupos de diretório, em vez de depender da seleção de SSID ou filtragem de endereço MAC. Aplica a segmentação de rede por identidade de dispositivo.

Permite que um único SSID atenda a múltiplos tipos de dispositivos com diferentes níveis de acesso à rede. Um dispositivo de funcionário recebe a VLAN 10 (acesso interno); o dispositivo de um prestador de serviços recebe a VLAN 20 (apenas internet); um terminal de PDV recebe a VLAN 30 (apenas sistemas de pagamento).

MDM (Mobile Device Management)

Software usado por equipes de TI para registrar, configurar, proteger e gerenciar smartphones, tablets e laptops. Plataformas de MDM como Microsoft Intune e Jamf usam perfis SCEP para enviar instruções de registro de certificados para dispositivos gerenciados sem a necessidade de interação do usuário.

O pré-requisito para a implantação de certificados baseada em SCEP. Os dispositivos devem estar registrados no MDM antes de poderem receber perfis de SCEP e WiFi. Dispositivos BYOD não gerenciados exigem uma abordagem de integração separada.

Exemplos práticos

Uma propriedade Premier Inn de 200 quartos precisa proteger o WiFi de sua equipe para tablets de ponto de venda e smartphones do serviço de quarto. Atualmente, eles usam uma chave pré-compartilhada que foi vazada para prestadores de serviços. Eles gerenciam os dispositivos via Microsoft Intune e possuem uma mistura de dispositivos iOS e Android. A propriedade utiliza pontos de acesso HPE Aruba.

Implante uma PKI interna de duas camadas do Microsoft AD CS. Configure o NDES em um Windows Server dedicado e publique-o via Azure AD Application Proxy.
No Intune, crie um perfil de Certificado Raiz Confiável contendo os certificados da CA Raiz e da CA Emissora. Implante para um grupo do Azure AD 'Property Staff Devices'.
Crie um perfil de Certificado SCEP no Intune apontando para a URL externa do NDES. Defina o formato do Nome do Assunto como CN={{AAD_Device_ID}}, pois estes são dispositivos compartilhados. Defina o Uso da Chave como Assinatura Digital e Criptografia de Chave, e o Uso Estendido da Chave como Autenticação de Cliente. Implante para 'Property Staff Devices'.
Crie um perfil de Wi-Fi para o SSID da equipe, configurando WPA2-Enterprise e EAP-TLS. Selecione o perfil SCEP para autenticação de cliente e a CA Raiz para validação de servidor. Implante para 'Property Staff Devices'.
Configure as definições de RADIUS do HPE Aruba para apontar para o Windows NPS. No NPS, configure uma Política de Rede que exija EAP-TLS e atribua a VLAN 10 para os dispositivos da equipe.
Assim que os dispositivos receberem os perfis e se conectarem com sucesso, rotacione a PSK no SSID antigo e agende sua desativação.

Comentário do examinador: Esta abordagem identifica corretamente que dispositivos compartilhados (PDV, serviço de quarto) exigem autenticação baseada em dispositivo (CN={{AAD_Device_ID}}) em vez de autenticação baseada em usuário, já que vários membros da equipe usam o mesmo dispositivo. Ela segue a sequência obrigatória de implantação de perfil e garante que todos os três perfis tenham como alvo o mesmo grupo do Azure AD. Publicar o NDES via App Proxy em vez de exposição direta à internet é a postura de segurança correta para um ambiente de hotelaria.

Uma rede de varejo com 50 lojas deseja implantar o 802.1X para laptops corporativos em todas as unidades. Eles usam pontos de acesso Cisco Meraki e o Microsoft Intune. Eles não querem implantar e manter servidores NDES locais ou infraestrutura AD CS em cada localidade ou em seu data center.

Implemente um serviço de gateway SCEP e PKI baseado em nuvem que se integre ao Intune via protocolo SCEP. A CA em nuvem emite os certificados; o gateway SCEP em nuvem lida com a validação de CSR.
Configure o serviço RADIUS em nuvem (fornecido pelo fornecedor de PKI) no painel do Cisco Meraki em Wireless > Access Control para o SSID corporativo. Defina a segurança como WPA2-Enterprise e aponte o RADIUS para o serviço em nuvem.
No Intune, crie um perfil de Certificado Raiz Confiável contendo o certificado raiz da CA em nuvem. Implante para o grupo de dispositivos 'Corporate Laptops'.
Crie um perfil de Certificado SCEP apontando para a URL do gateway SCEP em nuvem. Defina o Nome do Assunto como CN={{UserPrincipalName}} para autenticação baseada em usuário. Implante para 'Corporate Laptops'.
Crie um perfil de Wi-Fi para o SSID corporativo com EAP-TLS, referenciando o perfil SCEP e a raiz da CA em nuvem. Implante para 'Corporate Laptops'.
Quando os laptops se registrarem no Intune, eles solicitarão automaticamente certificados da CA em nuvem por meio do gateway SCEP em nuvem. Nenhuma infraestrutura local é necessária em nenhuma das 50 localidades.

Comentário do examinador: Esta é a arquitetura moderna ideal para ambientes de varejo distribuídos. Ao aproveitar a PKI em nuvem e o RADIUS em nuvem, a organização elimina a necessidade de manter uma infraestrutura local complexa (NDES, AD CS, NPS) em cada site. O gateway SCEP em nuvem escala horizontalmente e é inerentemente altamente disponível, removendo o ponto único de falha que o NDES local introduz. A arquitetura gerenciada em nuvem da Cisco Meraki se alinha perfeitamente com essa abordagem.

Questões práticas

Q1. Sua organização está migrando de PEAP-MSCHAPv2 para EAP-TLS. Você implantou com sucesso os perfis Trusted Root e SCEP para o seu grupo do Azure AD 'Corporate Users' no Intune. Você implanta o perfil de WiFi para 'All Corporate Devices'. Os usuários relatam que não conseguem se conectar e o perfil de WiFi é exibido como Não Aplicável.

Dica: Verifique as dependências do perfil e as regras de direcionamento de grupo. O Intune resolve as dependências do perfil com base no grupo atribuído.

Ver resposta modelo

O problema é uma incompatibilidade de direcionamento de grupo. O perfil de WiFi depende do perfil SCEP, que foi direcionado a um grupo de Usuários ('Corporate Users'). O perfil de WiFi foi direcionado a um grupo de Dispositivos ('All Corporate Devices'). O Intune não pode resolver a dependência entre tipos de grupos diferentes. A solução é alterar as atribuições de todos os três perfis - Trusted Root, SCEP e WiFi - para direcionar ao mesmo grupo. Decida se usará um grupo de Usuários ou um grupo de Dispositivos com base no seu modelo de autenticação (baseado em usuário vs. baseado em dispositivo) e aplique isso de forma consistente em todos os três perfis.

Q2. Uma auditoria de segurança revela que, quando um funcionário é desligado e sua conta do Microsoft Entra ID é desativada, seu smartphone corporativo ainda consegue se conectar à rede WiFi da equipe por até uma semana após o desligamento.

Dica: Considere como o servidor RADIUS determina se um certificado ainda é válido após a conta ser desativada. Qual é o mecanismo para comunicar o status de revogação?

Ver resposta modelo

O servidor RADIUS não está realizando uma verificação estrita da Lista de Revogação de Certificados (CRL) ou a CRL é publicada com pouca frequência. Quando um funcionário é desligado, o MDM deve desinscrever o dispositivo e a CA deve revogar o certificado. No entanto, se o servidor RADIUS não estiver verificando a CRL a cada tentativa de autenticação - ou se a CRL for publicada apenas semanalmente - o certificado revogado continuará sendo aceito. A solução envolve três etapas: configurar o servidor RADIUS para impor a verificação estrita da CRL em cada autenticação; configurar a CA para publicar a CRL em um intervalo menor (diariamente ou com maior frequência); e garantir que o MDM esteja configurado para acionar a revogação do certificado quando um dispositivo for desinscrito.

Q3. Você precisa fornecer acesso WiFi seguro para dispositivos IoT headless (termostatos inteligentes, players de sinalização digital) que não podem executar um agente MDM e não podem exibir um Captive Portal. Você pode usar SCEP para esses dispositivos e, se não, qual é a alternativa recomendada?

Dica: Considere os pré-requisitos para a inscrição SCEP e quais alternativas existem para dispositivos que não podem ser inscritos no MDM ou interagir com um navegador.

Ver resposta modelo

O SCEP não pode ser usado para esses dispositivos. O SCEP requer um agente MDM para receber a URL de inscrição e a senha de desafio, gerar o par de chaves e instalar o certificado resultante. Dispositivos IoT headless que não podem executar um agente MDM não podem participar do fluxo de inscrição SCEP. As alternativas recomendadas são: (1) MAC Authentication Bypass (MAB) combinado com segmentação estrita de VLAN - o servidor RADIUS permite o dispositivo com base em seu endereço MAC e o coloca em uma VLAN de IoT isolada, sem acesso aos sistemas corporativos; (2) se o dispositivo for compatível, o EST (Enrollment over Secure Transport, RFC 7030) pode provisionar certificados para dispositivos que suportam HTTPS, mas não MDM; (3) para dispositivos com uma interface de gerenciamento, alguns fornecedores oferecem suporte à inscrição SCEP diretamente por meio do firmware do dispositivo, sem a necessidade de um agente MDM. Em todos os casos, os dispositivos IoT devem ser isolados em uma VLAN dedicada, independentemente do método de autenticação utilizado.

Continue a ler esta série

O Guia Corporativo para SCEP: Implantando o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Campus

Este guia de referência técnica fornece um modelo arquitetônico definitivo e uma estratégia de implementação passo a passo para a implantação de certificados WiFi corporativos usando SCEP. Ele aborda as diferenças críticas entre SCEP e PKCS, a sequência exata de implantação necessária para o sucesso e estratégias reais de mitigação de riscos para líderes de TI.

Como implementar SCEP para registro automatizado de certificados WiFi

Este guia explica como implementar o SCEP (Simple Certificate Enrollment Protocol) para registro automatizado de certificados WiFi em locais corporativos. Ele abrange o projeto arquitetônico completo - desde o design de PKI e integração com MDM até a sequência obrigatória de implantação em três etapas - e mostra aos gerentes de TI e arquitetos de rede como eliminar credenciais compartilhadas, automatizar o gerenciamento do ciclo de vida dos certificados e atender aos requisitos do PCI DSS e GDPR em escala.

Entendendo o Cisco SUDI: Identidade de Dispositivo Baseada em Hardware no Controle de Acesso à Rede

Este guia detalha a arquitetura técnica do Cisco SUDI, explicando como a identidade ancorada em hardware protege o controle de acesso à rede. Ele fornece etapas práticas de implementação para líderes de TI implantarem a autenticação 802.1X EAP-TLS e automatizarem o Zero Touch Provisioning em locais corporativos.