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

Sim. O Microsoft Cloud PKI, a autoridade de certificação alojada na Intune Suite, emite certificados WiFi EAP-TLS para dispositivos geridos pelo Intune. Um perfil de certificado SCEP solicita-os diretamente, pelo que não necessita de servidor NDES, conector de certificado ou CA no local. O seu servidor RADIUS confia na raiz do Cloud PKI importada e verifica cada certificado relativamente à CRL que o serviço publica.

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

O EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) é o método 802.1X em que ambas as partes provam a sua identidade com certificados. O IEEE 802.1X é o padrão de controlo de acesso baseado em portas por trás do WPA2-Enterprise e WPA3-Enterprise. O ponto de acesso encaminha cada tentativa de ligação para um servidor RADIUS, o servidor de autenticação que aceita ou rejeita o dispositivo. Com o EAP-TLS não existe palavra-passe para ser alvo de phishing nem chave partilhada para ser divulgada. Cada dispositivo possui a sua própria chave privada e certificado.

A parte difícil sempre foi a PKI (public key infrastructure) por trás dele. A disponibilização de certificados em dispositivos geridos pelo Intune exigia tradicionalmente quatro elementos:

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

Cada um deles requer atualizações, cópias de segurança e monitorização.

O Microsoft Cloud PKI substitui essa pilha por uma autoridade de certificação alojada no seu tenant do Intune. Os dispositivos solicitam certificados através de SCEP (Simple Certificate Enrollment Protocol) e o Cloud PKI responde a essas solicitações diretamente. Valida cada pedido junto do Intune, assina o certificado e devolve-o. O dispositivo gera a sua chave privada localmente e a chave nunca sai do mesmo.

Para frotas associadas ao Entra ID, isto elimina a última dependência no local na cadeia de certificados. Dispositivos que nunca contactaram um controlador de domínio podem continuar a obter um certificado WiFi.

Como funciona a hierarquia de CAs do Cloud PKI

O Cloud PKI utiliza uma hierarquia de dois níveis. Uma CA raiz assina uma ou mais CAs emissoras, e a CA emissora assina os certificados dos dispositivos. A Microsoft guarda as chaves de assinatura da CA em módulos de segurança de hardware (HSMs), para que nunca tenha de gerir material de chaveamento.

Pode escolher uma de duas âncoras:

• Raiz do Cloud PKI. A Microsoft aloja tanto a raiz como a CA emissora no seu tenant. Esta é a opção mais simples para um ambiente Entra ID do zero.
• Traga a sua própria CA (BYOCA). Cria uma CA emissora no Cloud PKI, transfere o seu pedido de assinatura de certificado e assina-o com a sua raiz privada existente, como uma raiz AD CS. Tudo o que já confiar nessa raiz passa a confiar na cadeia da nova CA emissora.

Define utilizações alargadas de chave (EKUs) quando cria cada CA. Os certificados de cliente WiFi precisam da EKU de Autenticação do Cliente, portanto inclua-a em ambos os níveis. Planeie isto com cuidado, porque as EKUs ficam fixas quando a CA é criada.

Existe uma fronteira importante no design. O Cloud PKI emite certificados para dispositivos geridos pelo Intune através de SCEP. Não foi concebido para emitir o próprio certificado do seu servidor RADIUS, pelo que esse certificado normalmente provém de uma CA pública ou da sua PKI existente.

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

	Cloud PKI (SCEP)	SCEP com NDES	PKCS
Alojamento da CA	Alojado pela Microsoft no seu inquilino Intune	A sua AD CS ou CA de terceiros	A sua AD CS ou CA de terceiros
Servidores no local	Nenhum	CA emissora, servidor NDES, anfitrião do conector	CA emissora, anfitrião do conector
Componente publicado na Internet	Nenhum	NDES, via proxy inverso ou proxy de aplicação	Nenhum
Onde a chave privada é gerada	No dispositivo	No dispositivo	No lado da CA, entregue ao dispositivo como PFX
Adequado para frotas exclusivas do Entra ID	Nativo	Funciona, mas mantém dependências no local	Funciona, mas mantém dependências no local
Revogação	Revogue no centro de administração do Intune, publicado por CRL	Através do conector e da CRL da sua CA	Através do conector e da CRL da sua CA
Modelo de licença	Intune Suite ou suplemento Cloud PKI, por utilizador	Licenças do Windows Server e Intune	Licenças do Windows Server e Intune
A quem se adequa	Ambientes cloud-first que pretendem desativar a PKI no local	Ambientes com uma equipa de AD CS experiente e um roteiro longo de CA	Casos que precisam da mesma chave em mais do que uma plataforma, como S/MIME

O nosso guia separado para a implementação de certificados Intune com SCEP e PKCS abrange os dois caminhos no local em detalhe.

O que precisa antes de implementar o Cloud PKI para EAP-TLS?

Verifique estes seis itens antes de criar qualquer recurso. Cada um deles corresponde a uma falha na secção de resolução de problemas abaixo.

• Licenciamento. Uma subscrição do Intune Plano 1 e a Microsoft Intune Suite ou o suplemento autónomo Cloud PKI.
• Permissões. A função de Administrador do Intune, ou uma função personalizada com permissões de Cloud PKI.
• Dispositivos registados. Dispositivos Windows, macOS, iOS/iPadOS ou Android registados no Intune, agrupados em grupos de segurança do Microsoft Entra ID.
• Um servidor RADIUS compatível com EAP-TLS. Deve permitir importar certificados de CA, aceder à CRL do Cloud PKI via HTTP e mapear identidades de certificados para objetos do Entra ID. O Microsoft NPS (Network Policy Server) procura contas no Active Directory no local, pelo que os dispositivos exclusivos da nuvem falham nesse ponto.
• Um certificado de servidor RADIUS. Também precisa da raiz e de quaisquer certificados intermédios que o emitiram, porque os dispositivos têm de validar o servidor.
• Pontos de acesso compatíveis com 802.1X. Estes 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 suportam 802.1X. Isto inclui Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Para obter um guia passo a passo específico por fornecedor, consulte Configurar 802.1X na Juniper Mist com cloud RADIUS.

Como configurar certificados Cloud PKI para WiFi?

A sequência abaixo resume a implementação. Utilize a documentação da Cloud PKI da Microsoft no Microsoft Learn para aceder aos ecrãs e passos detalhados atualizados, uma vez que a disposição do centro de administração se altera entre versões.

Passo 1: criar a AC raiz ou utilizar a sua própria

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

Para BYOCA, ignore a raiz. Crie a AC de emissão como um tipo BYOCA e exporte o respetivo pedido de assinatura de certificado. Assine o pedido na sua AC privada utilizando um modelo que inclua Autenticação do Cliente e, em seguida, carregue o certificado assinado e a sua cadeia.

Passo 2: criar a AC de emissão

Crie uma AC de emissão ancorada à raiz do passo 1. Os seus EKUs devem incluir Autenticação do Cliente. Uma vez criada, a sua página de propriedades mostra três elementos de que precisará mais tarde:

• o URI SCEP
• a transferência do certificado da AC
• o ponto de distribuição CRL

Passo 3: implementar perfis de certificados fidedignos

Transfira os certificados da AC raiz e da AC de emissão. Crie um perfil de certificado fidedigno para cada um, por plataforma. Atribua-os aos mesmos grupos que irão receber os perfis SCEP e WiFi.

Os dispositivos precisam desta cadeia antes que o perfil SCEP possa ter sucesso. Crie outro perfil de certificado fidedigno para a AC que emitiu o certificado do seu servidor RADIUS, caso os dispositivos ainda não confiem nele.

Passo 4: criar o perfil de certificado SCEP

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

• URL do servidor SCEP. Cole o URI SCEP da AC de emissão exatamente como é apresentado. Deixe o texto do marcador de posição inalterado, pois o Intune resolve-o no momento da emissão.
• Certificado raiz. Selecione o perfil de certificado fidedigno para a raiz da Cloud PKI, e não para a AC de emissão.
• Tipo de certificado. Escolha certificados de dispositivo para dispositivos partilhados, como tablets de receção ou terminais portáteis de loja. Escolha certificados por pessoa quando os funcionários utilizam o seu próprio portátil e pretender que a política esteja associada ao indivíduo.
• Subject e subject alternative name (SAN). Inclua um identificador que o seu servidor RADIUS possa mapear para o Entra ID. Exemplos incluem a variável de ID de dispositivo Entra {{AAD_Device_ID}} ou a variável UPN {{UserPrincipalName}}.
• Key usage e EKU. Defina Digital signature e Key encipherment, com Autenticação do Cliente.
• Armazenamento de chaves no Windows. Registe no fornecedor de armazenamento de chaves TPM (Trusted Platform Module), para que a chave privada fique associada ao hardware e não seja exportável.
• Limite de renovação. Defina a percentagem de tempo de vida restante na qual o Intune renova, para que os certificados nunca caduquem sem ser notado.

Passo 5: fazer com que o servidor RADIUS confie na Cloud PKI

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

Ative 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 a BYOCA, o servidor RADIUS pode já confiar na sua raiz, pelo que apenas adiciona o novo certificado de CA emissora.

Se o cloud RADIUS da Purple autenticar o seu WiFi para funcionários, a equipa da sua conta Purple confirmará como a cadeia da Cloud PKI é carregada para o seu ambiente.

Passo 6: criar o perfil de WiFi

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

• Certificado de autenticação de cliente. Selecione o perfil SCEP do passo 4.
• Certificados de raiz para validação do servidor. Selecione o perfil de certificado de confiança para a raiz emissora do seu servidor RADIUS.
• Nomes dos servidores de certificados. Introduza nomes que correspondam exatamente ao certificado do servidor RADIUS.

Atribua o perfil aos mesmos grupos que os perfis SCEP e de certificado de confiança.

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

Revoga os certificados da Cloud PKI a partir da CA emissora no centro de administração do Intune. Abra a lista de certificados emitidos, selecione o certificado do dispositivo e revogue-o. A Cloud PKI publica depois a alteração na sua CRL (lista de revogação de certificados), que se encontra no ponto de distribuição HTTP integrado em cada certificado que emite.

O seu servidor RADIUS aplica a revogação, e não o Intune. Transfere a 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é à hora da sua próxima atualização. Um dispositivo revogado pode, portanto, continuar a ligar-se até que o servidor RADIUS obtenha uma lista atualizada. Feche essa janela de oportunidade de três formas:

1. Revogue explicitamente. Não confie na remoção da atribuição de um perfil ou na eliminação do registo de um dispositivo. Revogue o próprio certificado como parte do seu processo de entradas, transferências e saídas (JML).
2. Combine a revogação com verificações de identidade. Se o seu serviço RADIUS verificar o estado do dispositivo ou da conta do Microsoft Entra ID em cada autenticação, desativar a conta bloqueia o acesso antes de a CRL ser atualizada.
3. Monitorize a obtenção da CRL. Crie alertas para transferências de CRL com falha. Um servidor RADIUS com uma CRL desatualizada continuará a admitir dispositivos revogados ou rejeitará todos os dispositivos, dependendo da sua política de falha.

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

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

1. Estado do perfil. Os perfis de certificado de confiança, SCEP e WiFi reportam todos sucesso no relatório de configuração de dispositivos do Intune.
2. Certificado no dispositivo. No Windows, o certificado aparece no armazenamento pessoal com o assunto esperado, SAN e EKU de Autenticação de Cliente. A sua cadeia deve ser construída até à raiz do Cloud PKI.
3. Registo de emissão. O certificado aparece na lista de certificados emitidos pela AC emissora no centro de administração do Intune.
4. Registos do RADIUS. O registo de autenticação mostra o sucesso do EAP-TLS, a identidade esperada e uma cadeia válida.
5. Teste de revogação. Revoque um certificado de teste. Assim que o servidor RADIUS obtiver a nova CRL, confirme que o dispositivo é rejeitado.

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

O que corre mal com o Cloud PKI EAP-TLS e como resolver?

Sintoma	Causa provável	Solução
Perfil SCEP bloqueado em erro ou pendente	Perfis de certificados fidedignos não atribuídos ao mesmo grupo, ou o perfil SCEP referencia a AC emissora em vez da raiz	Atribua os perfis fidedignos de raiz e de emissão aos mesmos grupos, e selecione a raiz no perfil SCEP
Certificado emitido, o RADIUS rejeita com "AC desconhecida"	Apenas a raiz foi importada para o RADIUS	Importe também o certificado da AC emissora
Todos os dispositivos rejeitados após a entrada em funcionamento	O RADIUS não consegue alcançar o ponto de distribuição da CRL e falha por segurança	Permita o tráfego HTTP de saída do RADIUS para o anfitrião da CRL
Dispositivos Android recusam-se a ligar	Nenhuma validação de servidor configurada; o Android 11 e posterior exigem-na	Implante a raiz do servidor RADIUS como um perfil fidedigno e defina os nomes dos servidores de certificados
O Windows pede aos colaboradores para confiarem no servidor	Os nomes dos servidores no perfil de WiFi não correspondem ao certificado do RADIUS	Corrija os nomes dos servidores para que correspondam exatamente ao certificado
O NPS rejeita dispositivos associados ao Microsoft Entra ID	O NPS procura uma conta do Active Directory no local que não existe	Utilize um serviço RADIUS que mapeie certificados para objetos do Microsoft Entra ID
Dispositivo revogado continua a ligar-se	O RADIUS está a manter uma CRL em cache	Associe a revogação à desativação da conta ou dispositivo no Microsoft Entra ID, e reveja o armazenamento em cache da CRL
O certificado não tem Autenticação de Cliente	AC emissora criada sem esse EKU	Crie uma nova AC emissora com Autenticação de Cliente e reaponte o perfil SCEP

Se as falhas se concentrarem em salas ou pisos específicos enquanto os mesmos dispositivos se autenticam noutros locais, a falha é na cobertura de rádio, não na PKI. O EAP-TLS troca mais pacotes do que uma sincronização de chave pré-partilhada, pelo que um sinal fraco resulta em tempos limite esgotados. O Levantamentos de Sites WiFi: Um Guia Prático de Planeamento explica como encontrar essas lacunas.

Cloud PKI ou SCEP com NDES: qual deve escolher?

Baseie a decisão no que já executa e no que planeia desativar.

A sua situação	Recomendação	Porquê
Frota associada ao Microsoft Entra ID, sem AD CS	Cloud PKI com uma raiz Cloud PKI	Sem PKI no local para construir ou executar
AD CS implementado, servidores NDES a precisar de atualização de SO	Cloud PKI com BYOCA	Mantém a sua confiança raiz existente e descontinua o NDES e o conetor
Equipa de AD CS com um plano de CA a longo prazo e outros modelos de certificados	SCEP com NDES, a rever na próxima atualização de servidores	O investimento existente já cobre casos de utilização fora do WiFi
Necessidade do mesmo par de chaves em vários dispositivos, como S/MIME	PKCS para esse caso de utilização, Cloud PKI para WiFi	O PKCS fornece chaves exportáveis; os certificados de WiFi devem permanecer associados ao dispositivo
Dispositivos com junção híbrida atualmente no NPS, a migrar para a junção ao Entra ID	Cloud PKI acrescido de um serviço RADIUS na nuvem	As pesquisas do NPS falham assim que os dispositivos deixam o Active Directory

Infraestruturas reguladas no setor da Saúde mantêm frequentemente o AD CS para outras cargas de trabalho. Para estas, o BYOCA é geralmente 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 de pessoal a bordo em Comboios tendem a optar pela rota da raiz Cloud PKI. Esses dispositivos são geridos na nuvem desde o primeiro dia.

Quanto custa a Cloud PKI e qual é o retorno?

A Microsoft licencia a Cloud PKI por utilizador, por mês. Está disponível no Intune Suite ou como um suplemento autónomo, além do Intune Plan 1. Consulte a lista de preços atual da Microsoft, pois os pacotes podem mudar.

Pondere esse custo face ao que a opção no local lhe custa:

• Licenças do Windows Server e máquinas virtuais para a CA emissora, hosts do NDES e do conetor
• O reverse proxy ou application proxy que publica o NDES
• Cópias de segurança da base de dados da CA
• Gestão de atualizações e administração de modelos de certificados

O retorno traduz-se em menos servidores, nenhum endpoint NDES publicado na internet e chaves associadas ao dispositivo em todas as plataformas que gere.

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

Situação. Um grupo de 30 hotéis operava 900 portáteis e tablets de receção com junção ao Entra ID numa SSID de funcionários protegida com uma chave pré-partilhada. Rolar essa chave a cada trimestre significava intervir em todos os dispositivos de cada propriedade. Um tablet perdido deixava a chave exposta até à rotação seguinte.

O que foi feito. A equipa de TI criou uma raiz Cloud PKI e uma CA emissora, emitindo depois certificados de dispositivo suportados por TPM através de SCEP. Um serviço RADIUS na nuvem validou a cadeia e verificou a CRL. O grupo operou uma SSID EAP-TLS em paralelo com a antiga para o piloto, migrou as propriedades por fases e depois desligou a rede com chave pré-partilhada.

Resultado. A matemática do cenário é simples:

• Os segredos partilhados na rede de funcionários passam de um para zero.
• A rotação trimestral de chaves em 30 propriedades cessa completamente.
• Um tablet perdido passa a ser apenas uma revogação de certificado em vez da alteração da chave em 900 dispositivos.
• Não é necessária qualquer CA no local, servidor NDES ou conetor.

Cenário prático: uma cadeia de retalho com 250 lojas

Situação. Uma cadeia de retalho emitiu certificados WiFi a 4.000 terminais portáteis e portáteis de lojas através do AD CS e de dois servidores NDES. O Intune Certificate Connector era executado num terceiro servidor. Todos os três servidores deviam ser submetidos a substituição de sistema operativo, e o NDES era publicado através de um proxy de aplicação.

O que foi feito. A equipa criou uma AC emissora de Cloud PKI como BYOCA e assinou-a com a raiz do AD CS existente. O servidor RADIUS já confiava nessa raiz, pelo que apenas o novo certificado da AC emissora foi importado. Os perfis SCEP foram migrados para a Cloud PKI, um grupo de lojas de cada vez. Os certificados existentes mantiveram-se válidos até à renovação, o que preservou a capacidade de reversão.

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

Onde a Purple se enquadra

O Purple Staff WiFi utiliza Redes Baseadas em Identidade com RADIUS na nuvem, ligado ao Microsoft Entra ID, Okta ou Google Workspace. A Purple é agnóstica em termos de hardware, sendo compatível com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. O artigo Por que razão a sua próxima atualização de WiFi não precisa de novo hardware explica por que motivo a transição para um acesso de colaboradores 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 tempo de atividade e é certificada pela norma ISO 27001. Mantenha os colaboradores e os visitantes em redes separadas: Staff WiFi baseado em certificados para dispositivos geridos por si e Guest WiFi para todos os outros.

Perguntas frequentes

O Microsoft Cloud PKI pode emitir certificados WiFi?

Sim. O Cloud PKI emite certificados de autenticação de cliente para dispositivos Windows, macOS, iOS/iPadOS e Android geridos pelo Intune através de um perfil de certificado SCEP. Esses certificados autenticam dispositivos em redes WPA2-Enterprise ou WPA3-Enterprise utilizando EAP-TLS. A sua AC emissora tem de incluir o EKU de Autenticação de Cliente e o seu servidor RADIUS deve confiar na raiz do Cloud PKI e na AC emissora. O Cloud PKI normalmente não emite o próprio certificado do servidor RADIUS. Esse certificado provém de uma AC pública ou da sua PKI existente.

Ainda preciso do NDES com o Cloud PKI?

Não. O Cloud PKI responde ele próprio aos pedidos SCEP, pelo que não precisa de um servidor NDES, de um Intune Certificate Connector ou de um proxy inverso a publicar o NDES na internet. O perfil SCEP no Intune aponta diretamente para o URI do SCEP apresentado na sua AC emissora do Cloud PKI. Se utilizar a opção de trazer a sua própria AC (BYOCA), a sua raiz privada assina a AC emissora do Cloud PKI uma vez. Depois disso, o registo de dispositivos nunca entra em contacto com os seus servidores locais.

Como é que o servidor RADIUS confia nos certificados do Cloud PKI?

Importa os certificados da CA de raiz e de emissão da Cloud PKI para o repositório de CAs de confiança do servidor RADIUS. Transfira ambos a partir 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 da CRL em cada certificado, para poder verificar a revogação. Para dispositivos associados ao Entra ID, este deve mapear as identidades dos certificados para o Entra ID e não para o Active Directory local.

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

Revoga um certificado da CA de emissão no centro de administração do Intune e a Cloud PKI publica a alteração na respetiva CRL. O seu servidor RADIUS transfere essa CRL e rejeita os certificados revogados. Como os servidores RADIUS guardam as CRLs em cache, um dispositivo revogado pode ligar-se até à próxima atualização. Elimine essa lacuna desativando também a conta do Entra ID ou o dispositivo, desde que o seu serviço RADIUS verifique o estado da identidade em cada autenticação.

Devo escolher a Cloud PKI ou SCEP com NDES?

Escolha a Cloud PKI se gerir uma frota associada ao Entra ID ou se pretender desativar os servidores PKI locais. Esta opção elimina os anfitriões da CA de emissão, do NDES e do conetor. Mantenha o SCEP com NDES se tiver uma equipa de AD CS madura, um plano de ação de CA a longo prazo e outros modelos de certificado. Se os seus servidores NDES precisarem de ser atualizados, a Cloud PKI com BYOCA mantém a sua confiança de raiz existente e continua a desativar o NDES.

Como é licenciada a Microsoft Cloud PKI?

A Cloud PKI é licenciada por utilizador, por mês, além do Intune Plano 1. É disponibilizada como parte do Microsoft Intune Suite ou como um suplemento Cloud PKI autónomo. Consulte 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 estrutura de AD CS, NDES e conetores exige.

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

Sim, através da opção traga a sua própria CA (BYOCA). Cria uma CA de emissão na Cloud PKI, exporta o respetivo pedido de assinatura de certificado e assina-o com a sua CA de raiz privada existente, como o AD CS. Tudo o que já confia nessa raiz, incluindo o seu servidor RADIUS e os dispositivos, passa a confiar na nova cadeia. Adiciona apenas o certificado da CA de emissão. Pode migrar os perfis SCEP grupo a grupo enquanto os certificados existentes permanecem válidos até à renovação.

A Cloud PKI funciona com os meus pontos de acesso existentes?

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