Microsoft Cloud PKI para WiFi: implantação de certificado EAP-TLS com Intune e Entra ID

Sim. O Microsoft Cloud PKI, a autoridade de certificação hospedada no Intune Suite, emite certificados WiFi EAP-TLS para dispositivos gerenciados pelo Intune. Um perfil de certificado SCEP solicita os certificados diretamente, de modo que você não precisa de um servidor NDES, conector de certificado ou CA local. Seu servidor RADIUS confia no Cloud PKI root importado e verifica cada certificado em relação à CRL que o serviço publica.

O que o Microsoft Cloud PKI faz pela autenticação WiFi?

O EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) é o método 802.1X no qual ambos os lados comprovam sua identidade com certificados. O IEEE 802.1X é o padrão de controle de acesso baseado em porta por trás do WPA2-Enterprise e do WPA3-Enterprise. O ponto de acesso encaminha cada tentativa de conexão para um servidor RADIUS, o servidor de autenticação que aceita ou rejeita o dispositivo. Com o EAP-TLS não há senha para sofrer phishing nem chave compartilhada para vazar. Cada dispositivo possui sua própria chave privada e certificado.

A parte difícil sempre foi a PKI (infraestrutura de chaves públicas) por trás disso. Tradicionalmente, para colocar certificados em dispositivos gerenciados pelo Intune, eram necessários quatro itens:

• uma CA emissora do Active Directory Certificate Services (AD CS)
• um servidor NDES (Network Device Enrollment Service)
• o Intune Certificate Connector
• um proxy reverso ou proxy de aplicativo do Microsoft Entra para publicar o NDES na internet

Cada um desses itens exige correções, backups e monitoramento.

O Microsoft Cloud PKI substitui essa pilha por uma autoridade de certificação hospedada no seu tenant do Intune. Os dispositivos solicitam certificados via SCEP (Simple Certificate Enrollment Protocol), e o Cloud PKI responde a essas solicitações diretamente. Ele valida cada solicitação junto ao Intune, assina o certificado e o retorna. O dispositivo gera sua chave privada localmente, e a chave nunca sai dele.

Para frotas associadas ao Entra ID, isso remove a última dependência local na cadeia de certificados. Dispositivos que nunca viram um controlador de domínio ainda podem obter um certificado WiFi.

Como funciona a hierarquia de CA do Cloud PKI

O Cloud PKI usa uma hierarquia de dois níveis. Uma root CA assina uma ou mais CAs emissoras, e a CA emissora assina os certificados dos dispositivos. A Microsoft mantém as chaves de assinatura da CA em módulos de segurança de hardware (HSMs), para que você nunca precise gerenciar o material de chaves.

Você escolhe uma de duas âncoras:

• Cloud PKI root. A Microsoft hospeda tanto a root quanto a CA emissora no seu tenant. Esta é a opção mais simples para um ambiente Entra ID totalmente novo.
• Bring your own CA (BYOCA). Você cria uma CA emissora do Cloud PKI, baixa sua solicitação de assinatura de certificado e a assina com sua root privada existente, como uma root do AD CS. Qualquer item que já confie nessa root passará a confiar na cadeia da nova CA emissora.

Você define os usos estendidos de chave (EKUs) ao criar cada CA. Os certificados de cliente WiFi precisam do EKU de Autenticação do Cliente, portanto, inclua-o em ambas as camadas. Planeje isso com cuidado, pois os EKUs são fixos quando a CA é criada.

Uma limitação é importante para o projeto. O Cloud PKI emite certificados para dispositivos gerenciados pelo Intune por meio do SCEP. Ele não foi construído para emitir o próprio certificado do seu servidor RADIUS, portanto, esse certificado normalmente vem de uma CA pública ou da sua PKI existente.

Como o Cloud PKI se compara ao SCEP com NDES e PKCS

	Cloud PKI (SCEP)	SCEP com NDES	PKCS
Hospedagem da CA	Hospedada pela Microsoft no seu tenant do Intune	Sua AD CS ou CA de terceiros	Sua AD CS ou CA de terceiros
Servidores locais	Nenhum	CA emissora, servidor NDES, host do conector	CA emissora, host do conector
Componente publicado na Internet	Nenhum	NDES, via proxy reverso ou proxy de aplicativo	Nenhum
Onde a chave privada é gerada	No dispositivo	No dispositivo	No lado da CA, entregue ao dispositivo como um PFX
Adequado para frotas exclusivas do Entra ID	Nativo	Funciona, mas mantém dependências locais	Funciona, mas mantém dependências locais
Revogação	Revogue no centro de administração do Intune, publicado por CRL	Por meio do conector e da CRL da sua CA	Por meio do conector e da CRL da sua CA
Modelo de licença	Intune Suite ou complemento do Cloud PKI, por usuário	Licenças do Windows Server mais Intune	Licenças do Windows Server mais Intune
A quem se destina	Ambientes voltados para a nuvem que estão descontinuando a PKI local	Ambientes com uma equipe experiente de AD CS e um roteiro longo de CA	Casos que precisam da mesma chave em mais de uma plataforma, como S/MIME

Nosso guia separado sobre a implantação de certificados do Intune com SCEP e PKCS cobre as duas rotas locais em detalhes.

O que você precisa antes de implantar o Cloud PKI para EAP-TLS?

Verifique estes seis itens antes de criar qualquer coisa. Cada um deles corresponde a uma falha na seção de solução de problemas abaixo.

• Licenciamento. Uma assinatura do Intune Plano 1 mais o Microsoft Intune Suite ou o complemento individual do Cloud PKI.
• Permissões. A função de Administrador do Intune, ou uma função personalizada com as permissões do Cloud PKI.
• Dispositivos inscritos. Dispositivos Windows, macOS, iOS/iPadOS ou Android inscritos no Intune, agrupados em grupos de segurança do Microsoft Entra ID.
• Um servidor RADIUS compatível com EAP-TLS. Ele deve permitir que você importe certificados de CA, acesse a CRL do Cloud PKI via HTTP e mapeie identidades de certificado para objetos do Entra ID. O Microsoft NPS (Network Policy Server) busca contas no Active Directory local, portanto, dispositivos exclusivos da nuvem falham nele.
• Um certificado de servidor RADIUS. Você também precisa do certificado raiz e de quaisquer certificados intermediários que o emitiram, porque os dispositivos devem validar o servidor.
• Pontos de acesso compatíveis com 802.1X. Eles devem transmitir um SSID WPA2-Enterprise ou WPA3-Enterprise apontado para o seu servidor RADIUS.

Do lado do ponto de acesso, todas as principais plataformas oferecem suporte ao 802.1X. Isso inclui Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Para ver um passo a passo específico por fornecedor, consulte Configurando o 802.1X na Juniper Mist com cloud RADIUS.

Como configurar certificados Cloud PKI para WiFi?

A sequência abaixo resume o processo de criação. Utilize a documentação do Cloud PKI da Microsoft no Microsoft Learn para ver as telas e o passo a passo detalhado atualizados, pois o layout do centro de administração muda entre as versões.

Etapa 1: criar a CA raiz ou trazer a sua própria (BYOCA)

No centro de administração do Intune, crie uma CA raiz em administração do locatário. Escolha o tamanho da chave, o período de validade e os EKUs, incluindo a Autenticação do Cliente.

Para BYOCA, pule a raiz. Crie a CA emissora como um tipo BYOCA e exporte sua solicitação de assinatura de certificado. Assine a solicitação em sua CA privada usando um modelo que inclua a Autenticação do Cliente e, em seguida, faça o upload do certificado assinado e de sua cadeia.

Etapa 2: criar a CA emissora

Crie uma CA emissora ancorada à raiz da etapa 1. Seus EKUs devem incluir a Autenticação do Cliente. Uma vez criada, sua página de propriedades mostrará três itens dos quais você precisará mais tarde:

• o URI do SCEP
• o download do certificado da CA
• o ponto de distribuição CRL

Etapa 3: implantar perfis de certificado confiável

Faça o download dos certificados da CA raiz e emissora. Crie um perfil de certificado confiável para cada uma, por plataforma. Atribua-os aos mesmos grupos que receberão os perfis SCEP e WiFi.

Os dispositivos precisam dessa cadeia antes que o perfil SCEP possa ter sucesso. Crie um perfil de certificado confiável adicional para a CA que emitiu o certificado do seu servidor RADIUS, caso os dispositivos ainda não confiem nele.

Etapa 4: criar o perfil de certificado SCEP

Crie um perfil de certificado SCEP por plataforma e aponte-o para o Cloud PKI. Estas são as decisões principais:

• URL do servidor SCEP. Cole o URI do SCEP da CA emissora exatamente como mostrado. Mantenha o texto do marcador de posição sem alterações, pois o Intune o resolve no momento da emissão.
• Certificado raiz. Selecione o perfil de certificado confiável para a raiz do Cloud PKI, não para a CA emissora.
• Tipo de certificado. Escolha certificados de dispositivo para dispositivos compartilhados, como tablets de recepção ou coletores de dados de lojas. Escolha certificados por pessoa onde os funcionários utilizam seu próprio notebook e você deseja que a política esteja vinculada ao indivíduo.
• Nome do assunto e nome alternativo do assunto (SAN). Inclua um identificador que seu servidor RADIUS possa mapear para o Microsoft Entra ID. Exemplos são a variável de ID do dispositivo Entra {{AAD_Device_ID}} ou a variável UPN {{UserPrincipalName}}.
• Uso da chave e EKU. Defina Assinatura digital e Criptografia de chave, com Autenticação do Cliente.
• Armazenamento de chaves no Windows. Registre no provedor de armazenamento de chaves TPM (Trusted Platform Module), para que a chave privada fique vinculada ao hardware e não possa ser exportada.
• Limite de renovação. Defina a porcentagem de vida útil restante na qual o Intune realiza a renovação, para que os certificados nunca expirem sem aviso.

Passo 5: faça com que o servidor RADIUS confie no Cloud PKI

Importe os certificados da AC raiz e emissora do Cloud PKI para o repositório de ACs confiáveis do seu servidor RADIUS. Importar apenas a raiz é a causa mais comum de rejeições por "AC desconhecida".

Habilite a verificação de CRL e permita ao servidor RADIUS acesso HTTP de saída ao ponto de distribuição de CRL listado em cada certificado. Com BYOCA, o servidor RADIUS já pode confiar na sua raiz, portanto você adiciona apenas o novo certificado da AC emissora.

Se o cloud RADIUS da Purple autentica o seu Staff WiFi, a equipe da sua conta Purple confirmará como a cadeia do Cloud PKI é carregada para o seu tenant.

Passo 6: crie o perfil de WiFi

Crie um perfil de WiFi no Intune com segurança enterprise e EAP-TLS como o tipo de EAP. Defina três campos:

• Certificado de autenticação do cliente. Selecione o perfil SCEP do passo 4.
• Certificados raiz para validação do servidor. Selecione o perfil de certificado confiável para a raiz emissora do seu servidor RADIUS.
• Nomes de servidor do certificado. Insira nomes que correspondam exatamente ao certificado do servidor RADIUS.

Atribua o perfil aos mesmos grupos dos perfis SCEP e de certificado confiável.

Como funciona a revogação com o Cloud PKI?

Você revoga certificados do Cloud PKI a partir da AC emissora no centro de administração do Intune. Abra a lista de certificados emitidos, selecione o certificado do dispositivo e revogue-o. O Cloud PKI então publica a alteração em sua CRL (lista de revogação de certificados), que fica no ponto de distribuição HTTP incorporado em cada certificado que ele emite.

Seu servidor RADIUS aplica a revogação, não o Intune. Ele faz o download da CRL e rejeita qualquer certificado cujo número de série apareça nela.

A maioria dos servidores RADIUS armazena a CRL em cache até o horário da próxima atualização. Um dispositivo revogado pode, portanto, continuar se conectando até que o servidor RADIUS busque uma nova lista. Feche essa janela de três maneiras:

1. Revogue explicitamente. Não confie na remoção da atribuição de um perfil ou na exclusão do registro de um dispositivo. Revogue o próprio certificado como parte do seu processo de admissão, movimentação e desligamento de funcionários (JML).
2. Combine a revogação com verificações de identidade. Se o seu serviço RADIUS verifica o status da conta no Entra ID ou do dispositivo a cada autenticação, desativar a conta bloqueia o acesso antes que a CRL seja atualizada.
3. Monitore a busca da CRL. Crie alertas para falhas no download da CRL. Um servidor RADIUS que mantém uma CRL desatualizada continuará permitindo dispositivos revogados ou rejeitará todos os dispositivos, dependendo da sua política de falha.

Como verificar se a autenticação WiFi do Cloud PKI funciona?

Faça um piloto com um grupo de teste de cinco a 10 dispositivos em cada plataforma suportada. Confirme cinco coisas:

1. Status do perfil. Os perfis de certificado confiável, SCEP e WiFi relatam sucesso nos relatórios de configuração de dispositivos do Intune.
2. Certificado no dispositivo. No Windows, o certificado aparece no repositório pessoal com o assunto, SAN e Client Authentication EKU esperados. Sua cadeia deve ser construída até a raiz da PKI em nuvem.
3. Registro de emissão. O certificado aparece na lista de certificados emitidos da CA emissora no centro de administração do Intune.
4. Logs do RADIUS. O log de autenticação mostra o sucesso do EAP-TLS, a identidade esperada e uma cadeia válida.
5. Teste de revogação. Revogue um certificado de teste. Assim que o servidor RADIUS identificar a nova CRL, confirme se o dispositivo é rejeitado.

Execute o teste de revogação antes de entrar em operação. É a única verificação que prova que seu servidor RADIUS consegue alcançar a CRL.

O que dá errado com o Cloud PKI EAP-TLS e como corrigir?

Sintoma	Causa provável	Correção
Perfil SCEP preso em erro ou pendente	Perfis de certificado confiável não atribuídos ao mesmo grupo, ou o perfil SCEP faz referência à CA emissora em vez da raiz	Atribua perfis confiáveis da raiz e da emissora aos mesmos grupos e selecione a raiz no perfil SCEP
Certificado emitido, RADIUS rejeita com "CA desconhecida"	Apenas a raiz foi importada para o RADIUS	Importe também o certificado da CA emissora
Todos os dispositivos rejeitados após a entrada em operação	O RADIUS não consegue alcançar o ponto de distribuição da CRL e falha no modo fechado	Permita HTTP de saída do RADIUS para o host da CRL
Dispositivos Android se recusam a conectar	Nenhuma validação de servidor configurada; o Android 11 e versões posteriores a exigem	Implante a raiz do servidor RADIUS como um perfil confiável e defina os nomes dos servidores de certificados
O Windows solicita que a equipe confie no servidor	Os nomes dos servidores no perfil de WiFi não correspondem ao certificado do RADIUS	Corrija os nomes dos servidores para corresponderem exatamente ao certificado
O NPS rejeita dispositivos integrados ao Entra ID	O NPS procura por uma conta do Active Directory local que não existe	Use um serviço RADIUS que mapeie certificados para objetos do Entra ID
Dispositivo revogado ainda se conecta	O RADIUS está mantendo uma CRL em cache	Combine a revogação com uma conta do Entra ID ou desativação do dispositivo e revise o cache da CRL
O certificado não possui autenticação de cliente (Client Authentication)	CA emissora criada sem essa EKU	Crie uma nova CA emissora com Client Authentication e reapronte o perfil SCEP

Se as falhas se concentrarem em salas ou andares específicos, enquanto os mesmos dispositivos se autenticam em outros locais, a falha é na cobertura de rádio, não na PKI. O EAP-TLS troca mais pacotes do que um handshake de chave pré-compartilhada, portanto, um sinal marginal é exibido como tempo limite esgotado. WiFi Site Surveys: A Practical Planning Guide aborda como encontrar essas lacunas.

Cloud PKI ou SCEP com NDES: qual você deve escolher?

Baseie a decisão no que você já executa e no que planeja descontinuar.

Sua situação	Recomendação	Por quê
Frota integrada ao Entra ID, sem AD CS	Cloud PKI com uma raiz de Cloud PKI	Nenhuma PKI local para criar ou executar
AD CS em uso, servidores NDES precisando de atualização de SO	Cloud PKI com BYOCA	Mantém sua confiança raiz existente e aposenta o NDES e o conector
Equipe de AD CS com um roadmap de CA de longo prazo e outros modelos de certificado	SCEP com NDES, revisão na próxima atualização do servidor	O investimento existente já cobre casos de uso que não são de WiFi
Necessidade do mesmo par de chaves em vários dispositivos, como S/MIME	PKCS para esse caso de uso, Cloud PKI para WiFi	O PKCS fornece chaves exportáveis; os certificados de WiFi devem permanecer vinculados ao dispositivo
Dispositivos com ingresso híbrido no NPS hoje, migrando para ingresso no Entra ID	Cloud PKI mais um serviço cloud RADIUS	As consultas de NPS falham assim que os dispositivos saem do Active Directory

Ambientes regulamentados em Saúde geralmente mantêm o AD CS para outras cargas de trabalho. Para eles, o BYOCA costuma ser a melhor opção, pois mantém uma única raiz de confiança em toda a organização. Operadores ferroviários que emitem certificados para tablets da equipe a bordo em Trens tendem a se adaptar à rota de raiz da Cloud PKI. Esses dispositivos são gerenciados na nuvem desde o primeiro dia.

Quanto custa a Cloud PKI e o que você recebe em troca?

A Microsoft licencia a Cloud PKI por usuário, por mês. Ela vem incluída no Intune Suite ou como um complemento individual, além do Intune Plano 1. Consulte a lista de preços atual da Microsoft, pois as ofertas em pacote mudam.

Pondere isso em relação ao custo da opção local:

• Licenças do Windows Server e máquinas virtuais para a CA emissora, NDES e hosts de conectores
• O proxy reverso ou proxy de aplicativo que publica o NDES
• Backups do banco de dados da CA
• Aplicação de patches e administração de modelos de certificado

O retorno é menos servidores, nenhum ponto de extremidade NDES publicado na internet e chaves vinculadas ao dispositivo em todas as plataformas que você gerencia.

Cenário prático: um grupo hoteleiro de 30 propriedades

Situação. Um grupo de 30 hotéis executava 900 laptops e tablets de recepção com ingresso no Entra ID em um SSID de funcionários protegido por uma única chave pré-compartilhada. Alternar essa chave a cada trimestre significava intervir em cada dispositivo em cada propriedade. Um tablet perdido deixava a chave exposta até a próxima alternância.

O que foi feito. A TI criou uma raiz de Cloud PKI e uma CA emissora e, em seguida, emitiu certificados de dispositivo respaldados por TPM por meio do SCEP. Um serviço cloud RADIUS validou a cadeia e verificou a CRL. O grupo executou um SSID EAP-TLS ao lado do antigo para o projeto piloto, migrou as propriedades em ondas e, em seguida, desligou a rede de chave pré-compartilhada.

Resultado. Os cálculos do cenário são simples:

• Os segredos compartilhados na rede de funcionários caem de um para zero.
• A alternância trimestral de chaves em 30 propriedades para completamente.
• Um tablet perdido torna-se uma revogação de certificado em vez de uma nova chave em 900 dispositivos.
• Nenhuma CA local, servidor NDES ou conector é necessário.

Cenário prático: uma rede de varejo de 250 lojas

Situação. Uma rede do varejo emitiu certificados de WiFi para 4.000 coletores de dados e notebooks de lojas por meio do AD CS e dois servidores NDES. O Intune Certificate Connector era executado em um terceiro servidor. Todos os três servidores estavam previstos para substituição do sistema operacional, e o NDES era publicado por meio de um proxy de aplicação.

O que foi feito. A equipe criou uma CA emissora do Cloud PKI como BYOCA e a assinou com a raiz existente do AD CS. Como o servidor RADIUS já confiava nessa raiz, apenas o novo certificado da CA emissora foi importado. Os perfis SCEP foram migrados para o Cloud PKI um grupo de lojas por vez. Os certificados existentes permaneceram válidos até a renovação, garantindo a opção de reversão (rollback).

Resultado. A rede desativou três servidores: dois NDES e um host do conector. Também removeu o endpoint NDES publicado na internet. Nenhuma nova relação de confiança com a raiz foi necessária no RADIUS ou em qualquer dispositivo. A raiz do AD CS permaneceu ativa para outras cargas de trabalho.

Onde a Purple se encaixa

O Purple Staff WiFi usa Redes Baseadas em Identidade com RADIUS na nuvem, conectado ao Microsoft Entra ID, Okta ou Google Workspace. A Purple é agnóstica em relação ao hardware em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. O artigo Por que sua próxima atualização de WiFi não precisa de novo hardware explica por que migrar para o acesso de funcionários baseado em certificados raramente exige a substituição de pontos de acesso.

A Purple opera em mais de 80.000 locais ativos (dados da Purple) com 99,999% de disponibilidade e possui certificação ISO 27001. Mantenha funcionários e visitantes em redes separadas: Staff WiFi baseado em certificados para dispositivos gerenciados por você e Guest WiFi para todos os outros.

Perguntas frequentes

O Microsoft Cloud PKI pode emitir certificados de WiFi?

Sim. O Cloud PKI emite certificados de autenticação de cliente para dispositivos Windows, macOS, iOS/iPadOS e Android gerenciados pelo Intune por meio de um perfil de certificado SCEP. Esses certificados autenticam dispositivos em redes WPA2-Enterprise ou WPA3-Enterprise usando EAP-TLS. Sua CA emissora deve incluir a EKU de Autenticação do Cliente, e seu servidor RADIUS deve confiar na raiz do Cloud PKI e na CA emissora. O Cloud PKI normalmente não emite o próprio certificado do servidor RADIUS. Esse certificado vem de uma CA pública ou da sua PKI existente.

Ainda preciso do NDES com o Cloud PKI?

Não. O próprio Cloud PKI responde às solicitações SCEP, portanto, você não precisa de um servidor NDES, do Intune Certificate Connector nem de um proxy reverso publicando o NDES na internet. O perfil SCEP no Intune aponta diretamente para o URI do SCEP exibido na sua CA emissora do Cloud PKI. Se você usar a opção trazer sua própria CA (BYOCA), sua raiz privada assina a CA emissora do Cloud PKI uma vez. Depois disso, a ativação de dispositivos nunca mais toca seus servidores locais.

Como o servidor RADIUS confia nos certificados do Cloud PKI?

Você importa os certificados da CA raiz e emissora da Cloud PKI para o repositório de CAs confiáveis do servidor RADIUS. Baixe ambos do centro de administração do Intune. Importe ambos, pois importar apenas a raiz causa rejeições de "CA desconhecida". O servidor RADIUS também precisa de acesso HTTP de saída ao ponto de distribuição de CRL em cada certificado para que possa verificar a revogação. Para dispositivos associados ao Entra ID, ele deve mapear as identidades de certificado para o Entra ID em vez do Active Directory local.

Como funciona a revogação com a Cloud PKI?

Você revoga um certificado da CA emissora no centro de administração do Intune, e a Cloud PKI publica a alteração em sua CRL. Seu servidor RADIUS baixa essa CRL e rejeita certificados revogados. Como os servidores RADIUS armazenam CRLs em cache, um dispositivo revogado pode se conectar até a próxima atualização. Elimine essa lacuna desativando também a conta do Entra ID ou o dispositivo, desde que seu serviço RADIUS verifique o status da identidade a cada autenticação.

Devo escolher Cloud PKI ou SCEP com NDES?

Escolha a Cloud PKI se você gerencia uma frota associada ao Entra ID ou planeja desativar servidores PKI locais. Ela elimina a CA emissora, o NDES e os hosts conectores. Mantenha o SCEP com NDES se você tiver uma equipe madura de AD CS, um planejamento de CA de longo prazo e outros modelos de certificado. Se seus servidores NDES estiverem prontos para atualização, a Cloud PKI com BYOCA mantém sua confiança de raiz existente e ainda desativa o NDES.

Como a Microsoft Cloud PKI é licenciada?

A Cloud PKI é licenciada por usuário, por mês, além do Intune Plano 1. Ela vem como parte do Microsoft Intune Suite ou como um add-on independente da Cloud PKI. Verifique a lista de preços atual da Microsoft antes de definir o orçamento, pois os pacotes mudam. Compare o custo da licença com as licenças do Windows Server, máquinas virtuais, publicação de proxy e esforço de atualização que uma pilha de AD CS, NDES e conectores exige.

Posso manter minha CA raiz local existente com a Cloud PKI?

Sim, por meio da opção bring-your-own-CA. Você cria uma CA emissora da Cloud PKI, exporta sua solicitação de assinatura de certificado e a assina com sua raiz privada existente, como o AD CS. Tudo o que já confia nessa raiz, incluindo seu servidor RADIUS e dispositivos, passa a confiar na nova cadeia. Você adiciona apenas o certificado da CA emissora. Você pode migrar perfis SCEP grupo por grupo, enquanto os certificados existentes permanecem válidos até a renovação.

A Cloud PKI funciona com meus pontos de acesso existentes?

Sim, desde que seus pontos de acesso suportem 802.1X com WPA2 ou WPA3. A Cloud PKI afeta apenas os certificados nos dispositivos e a confiança no seu servidor RADIUS. Os pontos de acesso simplesmente encaminham a autenticação para o RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet suportam isso. O Staff WiFi da Purple roda em todos os oito como uma sobreposição em nuvem independente de hardware.