Guia de Configuração do SCEP Corporativo: Autenticação Wi-Fi Baseada em Certificado para Ensino Superior e Grandes Redes

Enterprise SCEP Setup Guide: Certificate-Based WiFi Authentication for Higher Education and Large Networks A Purple Technical Briefing - Podcast Script (approximately 10 minutes) --- INTRODUCTION AND CONTEXT - approximately 1 minute Welcome to the Purple Technical Briefing series. I am talking today about something that lands in a lot of IT inboxes but rarely gets a straight answer: how do you actually deploy certificate-based WiFi authentication at scale, using SCEP, across a large network - whether that is a university campus, a multi-site hotel group, or a large public sector estate? We are going to cover the full picture. What SCEP actually does, how it fits into an 802.1X architecture, the deployment sequence that most teams get wrong, two real-world implementation scenarios, and the pitfalls that will cost you a weekend of your life if you do not plan for them. This is a consultant briefing, not a tutorial. I am assuming you know what a RADIUS server is and you have probably already decided you need to move away from pre-shared keys. What you need now is the implementation map. Let us get into it. --- TECHNICAL DEEP-DIVE - approximately 5 minutes So, first principles. SCEP stands for Simple Certificate Enrollment Protocol. It was formalised by the IETF as RFC 8894 in 2020, though it had been in widespread enterprise use for well over a decade before that. Its job is straightforward: automate the process of getting a digital certificate onto a managed device without requiring a human to touch each machine. In the context of WiFi authentication, SCEP is the delivery mechanism. The actual authentication protocol you are targeting is EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - which sits inside the 802.1X framework. EAP-TLS is widely regarded as the most secure authentication method for enterprise wireless networks because it requires both the client device and the RADIUS server to present valid certificates. Neither side trusts the other without cryptographic proof. That mutual authentication is what protects you against evil twin attacks - where an attacker spins up a rogue access point to harvest credentials. Aqui está como funciona toda a cadeia. Um dispositivo gerenciado - um laptop de estudante, um telefone de funcionário, um terminal de ponto de venda de hotel - precisa se conectar à rede sem fio corporativa. Sua plataforma de 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 em 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 - uma CSR - e a envia para o gateway SCEP. O gateway valida o desafio, encaminha a CSR para a sua Autoridade Certificadora, e a AC 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 à cadeia de confiança da sua AC, verifica a Lista de Revogação de Certificados para confirmar se 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 certificados suportado por plataformas como o Intune. Com o PKCS, a AC gera tanto a chave pública quanto a privada centralmente, e o conector de certificado envia o par de chaves para o dispositivo. Isso significa que a chave privada viaja 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, sem exceção. 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. Sua configuração do RADIUS - seja Windows NPS, FreeRADIUS ou um serviço de RADIUS em nuvem - é onde você define a política de validação de certificados 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. Um dispositivo de estudante recebe a VLAN 20 - apenas acesso à internet. Um dispositivo de docente recebe a VLAN 10 - acesso a sistemas internos de pesquisa. Um dispositivo de gerenciamento predial recebe a VLAN 30 - acesso a sistemas de automação predial. Tudo isso é impulsionado pelos atributos do certificado e pela política do RADIUS, sem qualquer intervenção manual por dispositivo. For identity provider integration, SCEP certificate attributes - specifically the Subject Alternative Name - can carry the user's principal name from Microsoft Entra ID, Okta, or Google Workspace. That ties the certificate to a specific identity, which means when you disable an account in Entra ID and the MDM unenrols the device, the certificate is revoked and WiFi access is cut automatically. That is the revocation story that pre-shared keys simply cannot tell. --- RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS - aproximadamente 2 minutos Certo, vamos falar sobre a sequência de implantação, porque é aqui que a maioria das equipes se complica. A sequência é inegociável: primeiro o certificado Trusted Root, depois o perfil de certificado SCEP e, em terceiro lugar, o perfil de WiFi. Tanto o Intune quanto o Jamf impõem dependências de perfil. Se o seu perfil de WiFi referenciar 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. A segunda armadilha é o direcionamento de grupo. 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 de WiFi a um grupo de dispositivos, o Intune não conseguirá resolver a dependência e o perfil de WiFi aparecerá como Não Aplicável. Isso costuma pegar as equipes de surpresa o tempo todo. 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 brecha em 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 CRL estiver indisponível - porque um servidor caiu ou o 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 - qualquer coisa acima 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. --- PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto O SCEP pode lidar com dispositivos BYOD que não são registrados no MDM? Não diretamente. O SCEP exige o registro no MDM para enviar o payload do certificado. Para BYOD não gerenciado, você precisa de uma abordagem diferente - seja um portal de autoatendimento para integração de usuários ou um SSID separado que utilize um Captive Portal com verificação de identidade. A plataforma da Purple lida com essa camada de visitantes e BYOD de forma limpa, operando paralelamente à rede da equipe autenticada por certificado. What about iOS and Android? Both platforms support SCEP natively. iOS has supported SCEP since iOS 4. Android Enterprise supports SCEP through Intune and other MDMs. The configuration is slightly different per platform but the underlying protocol is identical. Does EAP-TLS work with WPA3? Yes. WPA3-Enterprise mandates 192-bit security mode for sensitive environments, and EAP-TLS is fully compatible. In fact, WPA3-Enterprise with EAP-TLS is the combination recommended by the Wi-Fi Alliance for government and financial networks. --- RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto Para resumir. A autenticação WiFi por certificado SCEP é a arquitetura ideal para qualquer rede com mais de 50 dispositivos gerenciados. Ela elimina credenciais compartilhadas, oferece identidade por dispositivo, permite a segmentação dinâmica de VLAN e se integra diretamente ao seu provedor de identidade para revogação automatizada. A sequência de implantação - Raiz Confiável, depois perfil SCEP, depois perfil WiFi - é fixa. O direcionamento de grupo deve ser consistente. A disponibilidade de CRL não é opcional. Especificamente para o ensino superior, a combinação de SCEP para dispositivos de funcionários e professores, juntamente com uma camada de WiFi para convidados separada para estudantes em dispositivos pessoais, oferece segurança e uma excelente experiência de usuário sem concessões. Se quiser se aprofundar, o guia da Purple sobre autenticação WiFi empresarial sem Active Directory ou um servidor local aborda o caminho nativo da nuvem. E se você estiver pensando no que acontece quando um funcionário se desliga, nosso guia sobre revogação de acesso ao WiFi detalha todo o fluxo de trabalho de revogação. Obrigado por nos acompanhar. Eu sou da equipe técnica da Purple, e nos vemos no próximo briefing. --- FIM DO SCRIPT