Confiança do servidor de perfil WiFi do Intune: nomes de servidor de certificado e checklist de CA raiz para Entra ID

Para estabelecer a confiança do servidor do perfil de WiFi do Intune com a integração do Microsoft Entra ID, faça a correspondência dos nomes dos servidores de certificados com o certificado do seu servidor RADIUS. A implantação deste padrão IEEE 802.1X em mais de 80.000 locais exige a vinculação de um perfil de certificado confiável que contenha a CA raiz ao mesmo grupo do Entra ID para evitar falhas no handshake de autenticação.

O que a validação de servidor em um perfil de WiFi do Intune realmente faz?

Um perfil de WiFi corporativo no Intune tem duas metades. A metade do cliente prova quem é o dispositivo. A metade do servidor prova que a rede pertence a você. A maioria das implantações paralisadas falha na metade do servidor, portanto, este guia aborda apenas essa metade.

Primeiro, algumas definições. O IEEE 802.1X é o padrão de controle de acesso baseado em porta. Ele mantém um dispositivo fora da rede até que um servidor RADIUS (Remote Authentication Dial-In User Service) o aprove. O EAP-TLS (Extensible Authentication Protocol com Transport Layer Security, RFC 5216) autentica ambos os lados com certificados. O PEAP (Protected EAP) envolve uma troca de senhas dentro de um túnel TLS.

Em ambos os métodos, o servidor RADIUS apresenta seu certificado primeiro. O dispositivo decide se confia nele antes de enviar um certificado ou senha.

Verificações e decisões

O dispositivo executa dois testes no certificado do servidor RADIUS:

• Cadeia de confiança. O certificado se encadeia a uma autoridade de certificação (CA) raiz que o perfil nomeia? No Intune, essa raiz chega ao dispositivo como um perfil de certificado confiável.
• Identidade. O nome no certificado corresponde ao campo de nomes de servidor de certificados? No Windows, iOS e macOS, o campo tem esse nome. No Android Enterprise, é o campo de nome do servidor Radius.

Ambos os testes devem passar. Um certificado de uma CA confiável com o nome errado falha. O nome correto de uma CA não listada também falha. Esse emparelhamento bloqueia um ponto de acesso invasor que apresenta um certificado válido para o domínio de outra pessoa. Esse ataque coleta credenciais PEAP de dispositivos que ignoram a validação.

Por que as falhas permanecem ocultas

O Intune informa se um perfil chegou ao dispositivo. Ele não informa se o dispositivo aceita o seu servidor RADIUS. Um perfil pode aparecer como bem-sucedido enquanto todos os handshakes falham no ponto de acesso. Você só vê o problema quando a equipe relata que a rede não conecta.

O que você precisa antes de começar?

Colete estes itens antes de abrir o Intune:

• O certificado do servidor RADIUS ativo. Registre o nome comum (CN) do assunto, cada entrada DNS de nome alternativo do assunto (SAN), a data de expiração, a intermediária emissora e a CA raiz.
• O certificado de cada servidor RADIUS. Os servidores primários e secundários geralmente possuem certificados diferentes. Os dispositivos devem validar ambos.
• O arquivo de certificado da CA raiz. Exporte-o como um arquivo .cer. Você fará o upload dele em um perfil de certificado confiável.- Infraestrutura de certificado de cliente para EAP-TLS. Você precisa de um perfil de certificado SCEP (Simple Certificate Enrollment Protocol) ou PKCS e da AC que o emite. O Intune também requer um perfil de certificado confiável para essa AC.
• Design de grupo do Entra ID. Decida se cada plataforma tem como alvo grupos de usuários ou grupos de dispositivos. Mantenha essa escolha idêntica em todos os perfis vinculados.
• Pontos de acesso configurados para WPA2-Enterprise ou WPA3-Enterprise. O SSID deve apontar para o seu servidor RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet suportam 802.1X.
• Um grupo piloto. Inclua pelo menos um dispositivo Windows, um Apple e um Android.

Uma distinção é importante se os seus pontos de acesso alcançam o RADIUS via RadSec (RADIUS sobre TLS, RFC 6614). O ponto de acesso executa sua própria verificação de nome de certificado nessa etapa. A configuração Juniper Mist da Purple para SecurePass define um nome de servidor RadSec curinga sob o domínio da Purple. Ela também carrega um certificado RadSec no nível da organização. Essa verificação fica entre o ponto de acesso e o servidor. O Intune nunca a toca. Mantenha as duas camadas separadas ao solucionar problemas.

Como configurar os nomes dos servidores de certificados e a AC raiz no Intune?

A documentação do Intune da Microsoft contém as etapas detalhadas passo a passo. As decisões abaixo são as que determinam se essas etapas funcionarão.

Etapa 1: leia os nomes do certificado que o servidor apresenta

Leia o certificado que o seu servidor RADIUS apresenta hoje. Não confie na solicitação de certificado ou nas notas de um colega. Um balanceador de carga, um novo nó ou uma renovação recente podem alterar o que os dispositivos recebem.

Idealmente, o CN e a primeira entrada DNS do SAN são idênticos, por exemplo, radius.contoso.com. Se você executa dois servidores, escolha entre estes padrões:

• Dê a cada servidor seu próprio nome e liste ambos os nomes no perfil.
• Dê a ambos os servidores nomes sob um sufixo compartilhado, como radius1.contoso.com e radius2.contoso.com.

Etapa 2: crie um perfil de certificado confiável para a raiz do servidor

Crie um perfil de certificado confiável por plataforma: Windows, iOS e iPadOS, macOS e Android Enterprise. Cada um contém a AC raiz que emitiu o certificado do servidor RADIUS.

Erros comuns acontecem aqui:

• Fazer upload da AC emissora do cliente em vez disso. Se os seus certificados SCEP vierem de uma AC diferente do certificado RADIUS, você precisará de perfis de certificado confiáveis separados. O campo de validação do servidor deve fazer referência à raiz do servidor.
• Fazer upload da intermediária em vez da raiz. Faça o upload da raiz. Configure o servidor RADIUS para enviar seus certificados intermediários durante o handshake TLS, para que os dispositivos possam construir a cadeia completa.

Etapa 3: preencha os campos de validação do servidor por plataforma

• Windows: Adicione o nome de cada servidor RADIUS em nomes de servidores de certificados. Selecione o perfil de certificado confiável em certificados raiz para validação do servidor. O Windows aceita mais de um perfil de raiz.
• iOS, iPadOS e macOS: Insira o nome em nomes de servidores de certificados. O documento de referência de perfil de configuração da Apple documenta este campo como uma lista de nomes comuns de certificados de servidor aceitos, e caracteres curinga como *.contoso.com são aceitos. Selecione o perfil de certificado confiável como a raiz para validação do servidor.
• Android Enterprise: Insira o nome DNS ou sufixo em nome do servidor Radius. As orientações da Microsoft recomendam inserir apenas o sufixo compartilhado quando vários servidores o compartilham. Selecione o certificado raiz para validação do servidor.

Passo 4: atribua cada perfil vinculado ao mesmo grupo

Atribua o perfil de certificado confiável, o perfil SCEP ou PKCS e o perfil de WiFi ao mesmo grupo do Microsoft Entra ID. Não envie um perfil para um grupo de usuários e outro para um grupo de dispositivos. Se o perfil de certificado confiável nunca chegar a um dispositivo, o perfil de WiFi dependente falhará ou nunca será instalado.

Para a parte de identidade de uma implementação do Microsoft Entra ID, consulte como ativar o logon único.

Como cada plataforma aplica o campo

Comportamento	Windows 10 e 11	iOS, iPadOS e macOS	Android Enterprise
Nome do campo no Intune	Nomes de servidores de certificados	Nomes de servidores de certificados	Nome do servidor Radius
Contra o que é comparado	Nome DNS no certificado do servidor	Nome comum do certificado do servidor	Nome DNS ou sufixo no certificado do servidor
Suporte a padrões	Insira cada nome de servidor completo	Caractere curinga, por exemplo *.contoso.com	Sufixo, por exemplo contoso.com
Configuração de raiz	Perfis de certificado confiável	Um perfil de certificado confiável	Um perfil de certificado confiável
Se o campo de nome for deixado em branco	O Windows pode solicitar que a equipe confie no servidor	O dispositivo pode solicitar que a equipe confie no servidor	O Android 11 e versões posteriores removem a opção de ignorar a validação
O que a equipe visualiza em caso de incompatibilidade	A conexão falha sem aviso	Mensagem "Não foi possível conectar" ou um aviso de confiança	Problema de autenticação exibido na entrada da rede
Onde você lê o erro	Log operacional WLAN-AutoConfig	Console do macOS, processo eapolclient	adb logcat, linhas TLS do suplicante

Como você verifica se a validação do servidor funciona?

Execute estas verificações em cada dispositivo piloto antes de expandir a atribuição:

1. Status do perfil. Confirme no Intune se o certificado confiável, o certificado do cliente e os perfis de WiFi relatam sucesso no dispositivo.
2. Conexão ativa. Conecte-se ao SSID. No Windows, o comando netsh wlan show interfaces confirma a conexão e o método de autenticação.
3. Aceitação do lado do servidor. Verifique o log do RADIUS para um Access-Accept contra aquele dispositivo ou conta.
4. Teste negativo. Aponte um SSID de teste para um servidor RADIUS cujo certificado tenha um nome diferente. O dispositivo deve recusá-lo. Isso prova que a validação é aplicada, e não ignorada por um aviso de confiança.
5. Registro de expiração. Observe a data de expiração do certificado RADIUS e sua raiz. Agende a renovação com bastante antecedência.

O teste negativo é a etapa que as equipes costumam pular. Sem ele, você não consegue distinguir um perfil que valida corretamente de outro que confia em qualquer certificado.

O que dá errado e como corrigir?

Padrões de falha comuns

• O nome errado no campo. As equipes inserem um endereço IP, um nome de host curto ou o nome do balanceador de carga. Insira o nome impresso no próprio certificado.
• A raiz errada. O perfil faz referência à CA emissora do cliente ou a uma intermediária. Faça referência à raiz que assinou a cadeia do certificado do servidor.
• Atribuição incompatível. O perfil de WiFi tem como alvo grupos de usuários, enquanto o perfil de certificado confiável tem como alvo grupos de dispositivos. Alinhe-os.
• Uma intermediária ausente. O servidor RADIUS envia apenas seu certificado folha (leaf). Os dispositivos não conseguem construir a cadeia, por isso o rejeitam. Instale a intermediária no servidor.
• Um CN que difere do SAN. A Apple faz a correspondência com o common name. Um certificado com o SAN correto e um CN diferente pode passar no Android e falhar no iPhone. Mantenha ambos idênticos.

Como um certificado RADIUS renovado interrompe conexões silenciosamente

Uma renovação que mantém a mesma raiz e os mesmos nomes não altera nada nos dispositivos. As conexões continuam funcionando.

Uma renovação interrompe as conexões quando qualquer um destes itens muda:

• A CA raiz. Seu provedor emite o novo certificado a partir de uma raiz diferente. Todos os dispositivos ainda apontam para a raiz antiga.
• A cadeia intermediária. A nova cadeia precisa de uma intermediária que o servidor não envia.
• O nome. Alguém emite novamente o certificado com um novo nome de host ou remove o SAN antigo.
• Um servidor em uma configuração multisservidor. Apenas o servidor secundário muda, fazendo com que as falhas pareçam aleatórias e intermitentes.

A falha é silenciosa porque nada muda no Intune. O perfil ainda é exibido como bem-sucedido e os dispositivos ainda mantêm a raiz antiga.

As renovações estão prestes a se tornar mais frequentes. A votação SC-081 do CA/Browser Forum reduz o tempo de vida máximo dos certificados TLS publicamente confiáveis. O limite diminuirá significativamente nos próximos anos. Um servidor RADIUS em um certificado de CA pública será renovado várias vezes por ano.

As correções eliminam a maior parte do risco:

• Emita o certificado RADIUS a partir de uma CA privada que você controla. Sua raiz pode durar mais do que muitos certificados de servidor. As renovações sob a mesma raiz são invisíveis para os dispositivos.
• Prepare qualquer mudança de raiz antes da renovação. Implante a nova raiz como um perfil de certificado confiável adicional primeiro. Os perfis do Windows podem fazer referência a ambas as raízes durante o período de sobreposição. Substitua o certificado do servidor somente depois que os dispositivos relatarem o novo perfil.

Lendo os erros em cada plataforma

• Windows: Abra o log operacional Microsoft-Windows-WLAN-AutoConfig no Visualizador de Eventos. Falhas de conexão aparecem lá com um motivo. netsh wlan show wlanreport cria um relatório HTML das sessões recentes.
• macOS: Filtre o Console no processo eapolclient. Falhas de confiança de TLS nomeiam o certificado que foi rejeitado.
• iOS e iPadOS: O dispositivo exibe uma mensagem de "Não foi possível conectar" ou um aviso de confiança. Confirme os conteúdos do perfil no Intune, depois reproduza em um Mac com o mesmo perfil para ler os logs.
• Android: A entrada de rede mostra um problema de autenticação. Em um dispositivo de teste, o adb logcat mostra linhas do supplicant que nomeiam a falha de verificação do certificado.
• Servidor RADIUS: Uma troca EAP que começa e depois para sem uma resposta do cliente geralmente significa que o dispositivo rejeitou seu certificado.

Cenários reais resolvidos

Cenário 1: uma rede de varejo renova em uma nova raiz. Uma rede de varejo utilizava PEAP para coletores de dados de funcionários e caixas Windows. Sua CA pública renovou o certificado RADIUS a partir de uma raiz mais recente. Todos os dispositivos ainda apontavam para a raiz antiga, e nenhuma loja conseguiu se conectar na manhã seguinte. A equipe implantou um perfil de certificado confiável para a nova raiz no mesmo grupo de dispositivos. Em seguida, forçou uma sincronização a partir do Intune. As lojas se reconectaram dentro de um ciclo de sincronização do Intune, e a equipe moveu os certificados RADIUS para uma CA privada. Renovações posteriores não geraram falhas de conexão. Estabelecimentos de Varejo com coletores de dados e caixas compartilham essa exposição.

Cenário 2: um hotel e o nome comum da Apple. Um hotel distribuiu iPads para a governança e tablets Android em um SSID EAP-TLS. O certificado RADIUS reemitido manteve o SAN correto, mas seu CN reverteu para o nome de host curto do servidor. Os tablets Android corresponderam ao sufixo DNS e se conectaram. Os iPads recusaram a conexão. A reemissão do certificado com um CN e SAN idênticos restaurou todos os iPads sem precisar tocar no Intune. Hotéis que operam frotas mistas devem manter o CN e o SAN alinhados por padrão.

Cenário 3: um centro de convenções com atribuições divididas. Um centro de convenções do setor público implantou EAP-TLS para notebooks Windows da equipe do evento. O perfil de WiFi tinha como alvo um grupo de usuários, enquanto o certificado confiável e os perfis SCEP tinham como alvo um grupo de dispositivos. Alguns notebooks nunca receberam o perfil de WiFi. Direcionar novamente os perfis para um único grupo de dispositivos corrigiu a entrega. Os notebooks se conectaram em sua próxima verificação.

Assim que a validação é aprovada, as quedas restantes geralmente são problemas de rádio ou roaming. Consulte resolvendo problemas de roaming em WLANs corporativas. Para mudanças de canal em locais movimentados, consulte eventos de radar DFS no Cisco Meraki, HPE Aruba e Ruckus: um checklist de diagnóstico para mudanças de canal.

Checklist para frotas integradas ao Microsoft Entra ID

1. Leia o CN e cada entrada DNS do SAN a partir do certificado que cada servidor RADIUS apresenta.
2. Torne o CN idêntico ao nome DNS do SAN primário.
3. Confirme que cada servidor RADIUS envia seus certificados intermediários no handshake TLS.
4. Exporte a CA raiz que emitiu o certificado do servidor, não a intermediária.
5. Crie um perfil de certificado confiável para essa raiz em todas as plataformas que você gerencia.
6. Mantenha a CA emissora do cliente em seu próprio perfil de certificado confiável separado.
7. Insira os nomes exatos dos servidores no Windows, um curinga no Apple e o sufixo DNS no Android.
8. Atribua o certificado confiável, SCEP ou PKCS, e os perfis de WiFi a um grupo do Entra ID.
9. Use o mesmo tipo de grupo, usuário ou dispositivo, para cada perfil vinculado em uma plataforma.
10. Execute o teste negativo com um certificado de servidor incompatível em cada plataforma.
11. Registre a data de expiração e a raiz de cada certificado RADIUS e revise-os bem antes do prazo.
12. Prepare qualquer nova raiz como um perfil de certificado confiável adicional antes de trocar o certificado do servidor.

Quanto custa e o que você recebe de volta?

O Intune está incluído no Microsoft 365 E3, E5 e Business Premium. A maioria das frotas integradas ao Entra ID já possui a licença. Uma CA privada pode ser executada nos Serviços de Certificado do Active Directory no Windows Server. O Microsoft Cloud PKI está disponível como um complemento do Intune licenciado separadamente.

O custo principal é o tempo da equipe. Cada renovação malsucedida traz uma onda de chamados de suporte em todos os locais ao mesmo tempo. O checklist acima leva algumas horas por plataforma e elimina essa onda recorrente.

O retorno é uma rede sem chave compartilhada para vazar. Você revoga o acesso desativando a conta ou revogando o certificado. O EAP-TLS também atende ao requisito 4.2.1.2 do PCI DSS v4.0, que exige criptografia forte em redes sem fio conectadas ao ambiente de dados do portador do cartão. Locais de Saúde e operadoras de Trens que utilizam dispositivos de funcionários se beneficiam do mesmo controle.

O Purple Staff WiFi traz Redes Baseadas em Identidade e RADIUS em nuvem para este modelo. Ele funciona com Microsoft Entra ID, Okta e Google Workspace, de modo que novos contratados, transferências e demissões atualizam o acesso à rede automaticamente. Ele é agnóstico em relação ao hardware, funcionando com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A Purple opera em mais de 80.000 locais ativos e possui as certificações ISO 27001 e Cyber Essentials.

Perguntas frequentes

A autenticação de certificado WiFi do Intune funciona com os pontos de acesso que já possuímos?

Sim. A validação do servidor ocorre entre o dispositivo e o servidor RADIUS, portanto o ponto de acesso só precisa suportar WPA2-Enterprise ou WPA3-Enterprise. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet suportam 802.1X. O Purple Staff WiFi é agnóstico em relação ao hardware e funciona como uma sobreposição em nuvem nessa infraestrutura existente. Você não precisa substituir o hardware para migrar a equipe para a autenticação baseada em certificados.

Precisamos de licenças adicionais da Microsoft para implantar perfis de WiFi do Intune?

Não, se você já possui o Microsoft 365 E3, E5 ou Business Premium. Essas suítes incluem o Intune, que cobre perfis de WiFi, certificado confiável e perfis SCEP ou PKCS. Você pode pagar separadamente por uma autoridade de certificação. O Active Directory Certificate Services roda no Windows Server. O Microsoft Cloud PKI é um complemento do Intune licenciado separadamente. Seu servidor RADIUS é um custo separado, quer você execute o Network Policy Server ou um serviço RADIUS em nuvem.

O certificado do servidor RADIUS deve vir de uma CA pública ou de uma CA privada?

Uma CA privada é a escolha mais segura para a maioria das frotas. Você controla sua raiz, portanto as renovações sob essa raiz nunca quebram a confiança do dispositivo. Os certificados de CA pública estão encurtando de acordo com a votação SC-081 do CA/Browser Forum. Cada renovação pública corre o risco de uma alteração de raiz ou intermediária que os dispositivos rejeitarão até que você implante novamente o perfil de confiança.

Podemos migrar de senhas PEAP para EAP-TLS sem interromper a equipe?

Sim. Implante o perfil de certificado SCEP ou PKCS e o novo perfil de WiFi EAP-TLS ao lado do perfil PEAP existente. Faça um piloto com um grupo por plataforma e confirme as conexões em seus logs do RADIUS. Remova o perfil PEAP assim que cada grupo se conectar de forma confiável. As configurações de validação do servidor, nomes e raiz, podem permanecer as mesmas em ambos os métodos. Isso remove a variável de maior risco da migração.

O que acontece com os perfis de WiFi do Intune quando o certificado RADIUS é renovado?

Nada, desde que o certificado renovado mantenha a mesma CA raiz e os mesmos nomes. Os dispositivos continuam se conectando. Se a raiz, a cadeia intermediária, o CN ou o SAN mudarem, os dispositivos rejeitarão o servidor, embora o Intune ainda relate o perfil como bem-sucedido. Prepare qualquer nova raiz como um perfil de certificado confiável adicional primeiro. Confirme se os dispositivos a receberam e, em seguida, instale o certificado renovado no servidor RADIUS.

O WiFi corporativo baseado em certificado ajuda com o PCI-DSS e GDPR?

Sim. O requisito 4.2.1.2 do PCI-DSS v4.0 exige criptografia forte para redes sem fio conectadas ao ambiente de dados de portadores de cartão. O EAP-TLS com validação de servidor atende a esse padrão sem uma chave compartilhada. Para a GDPR, a autenticação por certificado vincula cada sessão a uma identidade conhecida, o que oferece suporte ao registro de acesso e à revogação imediata. A Purple possui certificação ISO 27001 e Cyber Essentials, e sua plataforma está em conformidade com a GDPR.

Quanto tempo leva para as alterações de perfil chegarem aos dispositivos?

A maioria dos dispositivos inscritos recebe as alterações no próximo check-in do Intune. Para dispositivos Windows, iOS e Android, esse check-in ocorre periodicamente ao longo do dia. Você pode forçar uma sincronização imediata a partir do Intune ou do próprio dispositivo. Planeje as alterações de raiz pelo menos um ciclo completo de check-in antes da troca do certificado RADIUS. Os dispositivos que estiverem desligados receberão a atualização no próximo check-in.