Fidedignidade do servidor do perfil WiFi do Intune: nomes de servidor de certificados e lista de verificação de CA raiz para Entra ID

To establish Intune WiFi profile server trust with Microsoft Entra ID integration, match your certificate server names to your RADIUS server certificate. Deploying this IEEE 802.1X standard across 80,000+ venues requires linking a trusted certificate profile containing the root CA to the same Entra ID group to prevent authentication handshake failures.

What does server validation in an Intune WiFi profile actually do?

An enterprise WiFi profile in Intune has two halves. The client half proves who the device is. The server half proves the network belongs to you. Most stalled rollouts fail in the server half, so this guide covers that half only.

A few definitions first. IEEE 802.1X is the port-based access control standard. It holds a device off the network until a RADIUS (Remote Authentication Dial-In User Service) server approves it. EAP-TLS (Extensible Authentication Protocol with Transport Layer Security, RFC 5216) authenticates both sides with certificates. PEAP (Protected EAP) wraps a password exchange inside a TLS tunnel.

In both methods, the RADIUS server presents its certificate first. The device decides whether to trust it before it sends a certificate or password.

Checks and decisions

The device runs two tests on the RADIUS server certificate:

• Chain of trust. Does the certificate chain up to a root certificate authority (CA) that the profile names? In Intune, that root arrives on the device as a trusted certificate profile.
• Identity. Does the name on the certificate match the certificate server names field? On Windows, iOS and macOS the field has that name. On Android Enterprise it is the Radius server name field.

Both tests must pass. A certificate from a trusted CA with the wrong name fails. The right name from an unlisted CA also fails. This pairing blocks a rogue access point that presents a valid certificate for someone else's domain. That attack harvests PEAP credentials from devices that skip validation.

Why failures stay hidden

Intune reports whether a profile reached the device. It does not report whether the device accepts your RADIUS server. A profile can show as succeeded while every handshake fails at the access point. You only see the problem when staff report that the network will not connect.

What do you need before you start?

Collect these items before you open Intune:

• The live RADIUS server certificate. Record the subject common name (CN), every subject alternative name (SAN) DNS entry, the expiry date, the issuing intermediate and the root CA.
• Every RADIUS server's certificate. Primary and secondary servers often carry different certificates. Devices must validate both.
• The root CA certificate file. Export it as a .cer file. You will upload it to a trusted certificate profile.- Infraestrutura de certificados de cliente para EAP-TLS. Precisa de um perfil de certificado SCEP (Simple Certificate Enrollment Protocol) ou PKCS e da AC que o emite. O Intune também exige um perfil de certificado fidedigno para essa AC.
• Design do grupo Entra ID. Decida se cada plataforma se destina a grupos de utilizadores ou a grupos de dispositivos. Mantenha essa escolha idêntica em todos os perfis associados.
• 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.

A distinção é importante se os seus pontos de acesso acederem ao RADIUS através de RadSec (RADIUS sobre TLS, RFC 6614). O ponto de acesso executa a sua própria verificação do nome do certificado nessa ligação. A configuração Juniper Mist da Purple para o SecurePass define um nome de servidor RadSec com caráter universal (wildcard) sob o domínio da Purple. Também carrega um certificado RadSec ao nível da organização. Essa verificação situa-se entre o ponto de acesso e o servidor. O Intune nunca lhe toca. Mantenha as duas camadas separadas quando resolver problemas.

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

A documentação do Intune da Microsoft contém os passos clique a clique. As decisões abaixo são as que determinam se esses passos funcionam.

Passo 1: ler os nomes a partir do certificado que o servidor apresenta

Leia o certificado que o seu servidor RADIUS apresenta hoje. Não dependa do pedido de certificado ou das 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 executar dois servidores, escolha entre estes padrões:

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

Passo 2: criar um perfil de certificado fidedigno para a raiz do servidor

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

Os erros mais comuns acontecem aqui:

• Carregar a AC emitente de clientes. Se os seus certificados SCEP provêm de uma AC diferente do certificado RADIUS, precisa de perfis de certificados fidedignos separados. O campo de validação do servidor deve fazer referência à raiz do servidor.
• Carregar a AC intermédia em vez da raiz. Carregue a raiz. Configure o servidor RADIUS para enviar os seus certificados intermédios durante o handshake TLS, para que os dispositivos possam construir a cadeia completa.

Passo 3: preencher 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 fidedigno em certificados raiz para validação do servidor. O Windows aceita mais do que um perfil raiz.
• iOS, iPadOS e macOS: Introduza o nome em nomes de servidores de certificados. Os documentos de referência do perfil de configuração da Apple documentam este campo como uma lista de nomes comuns de certificados de servidor aceites, sendo aceites caracteres universais como *.contoso.com. Selecione o perfil de certificado fidedigno como a raiz para validação do servidor.
• Android Enterprise: Introduza o nome DNS ou sufixo em nome do servidor Radius. As diretrizes da Microsoft indicam para introduzir apenas o sufixo partilhado quando vários servidores o partilham. Selecione o certificado raiz para validação do servidor.

Passo 4: atribuir todos os perfis associados ao mesmo grupo

Atribua o perfil de certificado fidedigno, 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 utilizadores e outro para um grupo de dispositivos. Se o perfil de certificado fidedigno nunca chegar a um dispositivo, o perfil de WiFi dependente falha ou nunca é instalado.

Para o lado da identidade de uma implementação do Microsoft Entra ID, consulte como ativar o início de sessão único.

Como cada plataforma aplica o campo

Comportamento	Windows 10 e 11	iOS, iPadOS e macOS	Android Enterprise
Nome do campo Intune	Nomes de servidores de certificados	Nomes de servidores de certificados	Nome do servidor Radius
Com o que é comparado	Nome DNS no certificado do servidor	Nome comum do certificado do servidor	Nome DNS ou sufixo no certificado do servidor
Suporte de padrões	Introduza cada nome de servidor completo	Caracter universal, por exemplo *.contoso.com	Sufixo, por exemplo contoso.com
Definição de raiz	Perfis de certificados fidedignos	Um perfil de certificado fidedigno	Um perfil de certificado fidedigno
Se o campo do nome for deixado em branco	O Windows pode solicitar aos colaboradores que confiem no servidor	O dispositivo pode solicitar aos colaboradores que confiem no servidor	O Android 11 e posterior removem a opção de ignorar a validação
O que os colaboradores veem em caso de incompatibilidade	A ligação falha sem qualquer aviso	Mensagem "Não foi possível aderir" ou um aviso de fidedignidade	Problema de autenticação apresentado na entrada da rede
Onde ler o erro	Registo operacional WLAN-AutoConfig	Consola macOS, processo eapolclient	adb logcat, linhas TLS do supplicant

Como verificar se a validação do servidor funciona?

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

1. Estado do perfil. Confirme no Intune se o certificado fidedigno, o certificado de cliente e os perfis de WiFi reportam todos sucesso no dispositivo.
2. Ligação em direto. Adira ao SSID. No Windows, netsh wlan show interfaces confirma a ligação e o método de autenticação.
3. Aceitação do lado do servidor. Verifique o registo RADIUS para confirmar um Access-Accept para esse dispositivo ou conta.
4. Teste negativo. Aponte um SSID de teste para um servidor RADIUS cujo certificado tenha um nome diferente. O dispositivo deve rejeitá-lo. Isto prova que a validação é aplicada e não contornada por um aviso de confiança.
5. Registo de expiração. Anote a data de expiração do certificado RADIUS e a sua raiz. Agende a renovação com bastante antecedência.

O teste negativo é o passo que as equipas costumam saltar. Sem ele, não é possível distinguir um perfil que valida corretamente de um que confia em qualquer certificado.

O que corre mal e como resolver?

Padrões de falha comuns

• O nome errado no campo. As equipas introduzem um endereço IP, um nome de anfitrião curto ou o nome do balanceador de carga. Introduza o nome impresso no próprio certificado.
• A raiz errada. O perfil faz referência à CA emissora do cliente ou a uma intermédia. Faça referência à raiz que assinou a cadeia do certificado do servidor.
• Atribuição incompatível. O perfil de WiFi visa grupos de utilizadores, enquanto o perfil de certificado confiável visa grupos de dispositivos. Alinhe-os.
• Falta de uma intermédia. O servidor RADIUS envia apenas o seu certificado folha. Os dispositivos não conseguem construir a cadeia, pelo que o rejeitam. Instale a intermédia 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 funcionar no Android e falhar no iPhone. Mantenha ambos idênticos.

Como um certificado RADIUS renovado quebra as ligações de forma silenciosa

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

Uma renovação quebra as ligações quando ocorre qualquer uma destas alterações:

• A CA raiz. O seu fornecedor emite o novo certificado a partir de uma raiz diferente. Todos os dispositivos continuam a apontar para a raiz antiga.
• A cadeia intermédia. A nova cadeia precisa de uma intermédia que o servidor não envia.
• O nome. Alguém emite novamente o certificado com um novo nome de anfitrião ou remove o SAN antigo.
• Um servidor numa configuração multi-servidor. Apenas o servidor secundário muda, pelo que as falhas parecem aleatórias e intermitentes.

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

As renovações estão prestes a tornar-se 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 num 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 controla. A 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 alteração de raiz antes da renovação. Implemente primeiro a nova raiz como um perfil de certificado confiável adicional. Os perfis Windows podem referenciar ambas as raízes durante o período de sobreposição. Substitua o certificado do servidor apenas depois de os dispositivos reportarem o novo perfil.

Ler os erros em cada plataforma

• Windows: Abra o registo operacional Microsoft-Windows-WLAN-AutoConfig no Visualizador de Eventos. As falhas de ligação aparecem aí com um motivo. netsh wlan show wlanreport cria um relatório HTML das sessões recentes.
• macOS: Filtre a Consola pelo processo eapolclient. As falhas de confiança TLS identificam o certificado que foi rejeitado.
• iOS e iPadOS: O dispositivo mostra uma mensagem de "Não foi possível ligar" ou um aviso de confiança. Confirme o conteúdo do perfil no Intune e, em seguida, reproduza num Mac com o mesmo perfil para ler os registos.
• Android: A entrada de rede mostra um problema de autenticação. Num dispositivo de teste, adb logcat mostra linhas supplicant que identificam a falha de verificação de certificado.
• Servidor RADIUS: Uma troca EAP que se inicia e depois para sem resposta do cliente normalmente significa que o dispositivo rejeitou o seu certificado.

Cenários reais

Cenário 1: uma cadeia de retalho renova com uma nova raiz. Uma cadeia de retalho utilizava PEAP para os dispositivos portáteis do pessoal e caixas registadoras Windows. A 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 ligar na manhã seguinte. A equipa implementou 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 voltaram a ligar num ciclo de verificação do Intune e a equipa transferiu os certificados RADIUS para uma CA privada. As renovações posteriores não causaram falhas de ligação. Os setores de retalho com dispositivos portáteis e caixas registadoras partilham esta exposição.

Cenário 2: um hotel e o common name da Apple. Um hotel distribuiu iPads de limpeza e tablets Android num SSID EAP-TLS. O certificado RADIUS reemitido manteve o SAN correto, mas o seu CN reverteu para o hostname curto do servidor. Os tablets Android corresponderam ao sufixo DNS e ligaram-se. Os iPads recusaram a ligação. A reemissão do certificado com um CN e SAN idênticos restaurou todos os iPads sem tocar no Intune. Os hotéis que gerem frotas mistas devem manter o CN e o SAN alinhados por norma.

Cenário 3: um centro de conferências com atribuições divididas. Um centro de conferências do setor público implementou EAP-TLS em portáteis Windows para a equipa de eventos. O perfil de WiFi tinha como alvo um grupo de utilizadores, enquanto o certificado confiável e os perfis SCEP tinham como alvo um grupo de dispositivos. Alguns portáteis nunca receberam o perfil de WiFi. Redirecionar os perfis para um único grupo de dispositivos corrigiu a entrega. Os portáteis ligaram-se na verificação seguinte.

Assim que a validação for bem-sucedida, as quebras restantes são normalmente problemas de rádio ou de roaming. Consulte resolução de problemas de roaming em WLANs corporativas. Para alterações de canal em locais movimentados, consulte eventos de radar DFS no Cisco Meraki, HPE Aruba e Ruckus: uma lista de verificação de diagnóstico para alterações de canal.

Lista de verificação para frotas associadas ao Microsoft Entra ID

1. Leia o CN e cada entrada DNS SAN do certificado que cada servidor RADIUS apresenta.
2. Torne o CN idêntico ao nome DNS SAN principal.
3. Confirme que cada servidor RADIUS envia os seus certificados intermédios no handshake TLS.
4. Exporte a CA raiz que emitiu o certificado do servidor, não a intermédia.
5. Crie um perfil de certificado fidedigno para essa raiz em todas as plataformas que gere.
6. Mantenha a CA emissora do cliente no seu próprio perfil de certificado fidedigno separado.
7. Introduza nomes de servidor exatos no Windows, um caráter universal (wildcard) na Apple e o sufixo DNS no Android.
8. Atribua o certificado fidedigno, SCEP ou PKCS, e os perfis de WiFi a um grupo do Entra ID.
9. Utilize o mesmo tipo de grupo, utilizador ou dispositivo, para cada perfil associado numa plataforma.
10. Execute o teste negativo com um certificado de servidor incompatível em cada plataforma.
11. Registe a data de expiração e a raiz de cada certificado RADIUS e reveja-as bem antes do prazo.
12. Prepare qualquer nova raiz como um perfil de certificado fidedigno extra antes de substituir o certificado do servidor.

Quanto custa e o que recebe em troca?

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

O custo principal é o tempo da equipa. Cada renovação falhada traz uma vaga de pedidos de suporte em todos os locais em simultâneo. A lista de verificação acima demora algumas horas por plataforma e elimina essa vaga recorrente.

O retorno é uma rede sem chave partilhada que possa ser divulgada. Revoga o acesso ao desativar a conta ou ao revogar o certificado. O EAP-TLS também suporta o requisito 4.2.1.2 do PCI DSS v4.0, que exige uma criptografia forte em redes sem fios ligadas ao ambiente de dados de titulares de cartões. Os locais de Saúde e os operadores de Comboios que gerem dispositivos de funcionários beneficiam do mesmo controlo.

O Purple Staff WiFi traz Redes Baseadas em Identidade e RADIUS na nuvem para este modelo. Funciona com o Microsoft Entra ID, Okta e Google Workspace, pelo que as entradas, transferências e saídas de funcionários atualizam o acesso à rede automaticamente. É agnóstico em termos de hardware para 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 certificados de WiFi do Intune funciona com os pontos de acesso que já possuímos?

Sim. A validação do servidor é executada entre o dispositivo e o servidor RADIUS, pelo que o ponto de acesso apenas precisa de suportar WPA2 ou WPA3-Enterprise. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet suportam todos 802.1X. O Purple Staff WiFi é agnóstico em termos de hardware e funciona como uma sobreposição na nuvem nessa infraestrutura existente. Não precisa de substituir hardware para migrar a equipa para a autenticação baseada em certificados.

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

Não, se já possuir o Microsoft 365 E3, E5 ou Business Premium. Essas suites incluem o Intune, que cobre perfis de WiFi, certificados fidedignos e perfis SCEP ou PKCS. Poderá pagar separadamente por uma autoridade de certificação. O Active Directory Certificate Services é executado no Windows Server. O Microsoft Cloud PKI é um suplemento do Intune licenciado separadamente. O seu servidor RADIUS tem um custo separado, quer execute o Network Policy Server ou um serviço de RADIUS na nuvem.

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

Uma CA privada é a escolha mais segura para a maioria das frotas de dispositivos. O utilizador controla a sua raiz, pelo que as renovações sob essa raiz nunca quebram a fidedignidade do dispositivo. Os certificados de CA públicas estão a ser encurtados ao abrigo da votação SC-081 do fórum CA/Browser. Cada renovação pública corre o risco de uma alteração de raiz ou intermédia que os dispositivos rejeitarão até que reimplemente o perfil de fidedignidade.

Podemos migrar de palavras-passe PEAP para EAP-TLS sem interromper o pessoal?

Sim. Implemente o perfil de certificado SCEP ou PKCS e o novo perfil de WiFi EAP-TLS a par do perfil PEAP existente. Faça um teste piloto com um grupo por plataforma e confirme as ligações nos seus registos RADIUS. Remova o perfil PEAP assim que cada grupo se ligar de forma fiável. As definições de validação do servidor, nomes e raiz, podem permanecer as mesmas em ambos os métodos. Isso remove a variável mais arriscada da migração.

O que acontece aos 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 a ligar-se. Se a raiz, a cadeia intermédia, o CN ou o SAN mudarem, os dispositivos rejeitam o servidor, embora o Intune continue a reportar o perfil como bem-sucedido. Prepare qualquer nova raiz como um perfil de certificado fidedigno adicional primeiro. Confirme que os dispositivos a receberam e, em seguida, instale o certificado renovado no servidor RADIUS.

O WiFi para funcionários baseado em certificados ajuda com o PCI-DSS e o GDPR?

Sim. O requisito 4.2.1.2 do PCI-DSS v4.0 exige criptografia forte para redes sem fios ligadas ao ambiente de dados de titulares de cartões. O EAP-TLS com validação de servidor cumpre esse requisito sem uma chave partilhada. Para o GDPR, a autenticação por certificado associa cada sessão a uma identidade conhecida, o que apoia o registo de acessos e a revogação rápida. A Purple possui a certificação ISO 27001 e Cyber Essentials, e a sua plataforma está em conformidade com o GDPR.

Quanto tempo demora para que as alterações de perfil cheguem aos dispositivos?

A maioria dos dispositivos registados recebe as alterações na próxima verificação do Intune. Para dispositivos Windows, iOS e Android, essa verificação é executada periodicamente ao longo do dia. Pode forçar uma sincronização imediata a partir do Intune ou do próprio dispositivo. Planeie as alterações de raiz com pelo menos um ciclo completo de verificação de antecedência em relação à troca de certificado RADIUS. Os dispositivos que estiverem desligados recolherão a atualização na próxima verificação.