Comment configurer SCEP pour l'enrôlement automatisé de certificats WiFi d'entreprise

Ce guide explique comment configurer SCEP (Simple Certificate Enrollment Protocol) pour l'enrôlement automatisé de certificats WiFi d'entreprise, couvrant l'architecture complète depuis la PKI et le NDES jusqu'au déploiement de profils MDM et à la validation RADIUS. Il s'adresse aux responsables informatiques, architectes réseau et CTO d'hôtels, de chaînes de vente au détail, de stades, de centres de conférence et d'organisations du secteur public qui souhaitent dépasser les clés pré-partagées et mettre en œuvre une authentification 802.1X EAP-TLS évolutive et basée sur l'identité. La plateforme cloud overlay de Purple, indépendante du matériel, s'intègre directement à cette architecture, fournissant la couche WiFi pour les invités et le BYOD qui coexiste avec votre réseau d'employés authentifié par certificat.

📖 10 min de lecture📝 2,720 mots🔧 2 exemples concrets❓ 3 questions d'entraînement📚 9 définitions clés

Écouter ce guide

Voir la transcription du podcast

Bienvenue dans la série de fiches techniques de Purple. Je vais aborder aujourd'hui un sujet qui atterrit dans de nombreuses boîtes de réception informatiques mais qui obtient rarement une réponse claire : comment déployer concrètement une authentification WiFi basée sur des certificats à grande échelle, en utilisant SCEP, sur un grand réseau. Qu'il s'agisse d'un campus universitaire, d'un groupe hôtelier multi-sites ou d'un grand parc du secteur public, les défis sont identiques.

Nous allons couvrir l'ensemble du sujet. Ce que fait réellement SCEP, comment il s'intègre dans une architecture 802.1X, la séquence de déploiement que la plupart des équipes ratent, deux scénarios d'implémentation concrets, et les pièges qui vous coûteront un week-end entier si vous ne les anticipez pas.

Il s'agit d'un briefing de consultant, pas d'un tutoriel. Je pars du principe que vous savez ce qu'est un serveur RADIUS et que vous avez probablement déjà décidé de vous affranchir des clés pré-partagées. Ce dont vous avez besoin maintenant, c'est de la feuille de route d'implémentation.

Entrons dans le vif du sujet.

Premiers principes. SCEP signifie Simple Certificate Enrollment Protocol. Il a été formalisé par l'IETF en tant que RFC 8894 en 2020, bien qu'il ait été largement utilisé en entreprise pendant plus d'une décennie auparavant. Son rôle est simple : automatiser le processus d'obtention d'un certificat numérique sur un appareil géré sans nécessiter d'intervention humaine sur chaque machine.

Dans le cadre de l'authentification WiFi, SCEP est le mécanisme de distribution. Le protocole d'authentification réel que vous ciblez est EAP-TLS (Extensible Authentication Protocol with Transport Layer Security), qui s'inscrit dans le framework 802.1X. EAP-TLS est largement considéré comme la méthode d'authentification la plus sécurisée pour les réseaux sans fil d'entreprise car elle exige que l'appareil client et le serveur RADIUS présentent tous deux des certificats valides. Aucun des deux côtés ne fait confiance à l'autre sans preuve cryptographique. Cette authentification mutuelle est ce qui vous protège contre les attaques de type « evil twin », où un attaquant déploie un point d'accès malveillant pour intercepter des identifiants.

Voici comment fonctionne l'ensemble de la chaîne. Un appareil géré (l'ordinateur portable d'un étudiant, le téléphone d'un collaborateur, un terminal de point de vente d'un hôtel) doit rejoindre le réseau sans fil de l'entreprise. Votre plateforme MDM, qui peut être Microsoft Intune ou Jamf, pousse une charge utile SCEP vers cet appareil. La charge utile contient deux éléments : l'URL SCEP, qui pointe vers votre serveur NDES ou votre passerelle SCEP cloud, et un mot de passe de défi ou secret partagé.

L'appareil génère localement sa propre paire de clés publique et privée. C'est une étape critique. La clé privée ne quitte jamais l'appareil. Elle est générée sur l'appareil, stockée dans l'enclave sécurisée ou le TPM, et n'est jamais transmise sur le réseau. L'appareil crée ensuite une demande de signature de certificat, un CSR, et l'envoie à la passerelle SCEP. La passerelle valide le défi, transmet le CSR à votre autorité de certification (CA), et la CA le signe puis renvoie le certificat public à l'appareil.

À partir de ce moment, lorsque l'appareil se connecte à votre SSID WiFi, il présente ce certificat au serveur RADIUS. Le serveur RADIUS valide le certificat par rapport à votre chaîne de confiance CA, vérifie la liste de révocation des certificats pour confirmer que le certificat n'a pas été révoqué et, si tout est correct, envoie un message d'acceptation au point d'accès. L'appareil est sur le réseau. L'ensemble du processus est invisible pour l'utilisateur.

Parlons maintenant de la place de SCEP par rapport à l'alternative, qui est PKCS. PKCS, Public Key Cryptography Standards, est l'autre méthode de distribution de certificats prise en charge par des plateformes comme Intune. Avec PKCS, la CA génère à la fois la clé publique et la clé privée de manière centralisée, et le connecteur de certificat pousse la paire de clés vers l'appareil. Cela signifie que la clé privée voyage sur le réseau, ce qui introduit une surface d'attaque théorique. PKCS convient pour des cas d'usage comme le chiffrement d'e-mails S/MIME où le séquestre de clés est en fait souhaitable. Pour l'authentification WiFi, SCEP est le bon choix. La clé privée reste sur l'appareil, un point c'est tout.

Maintenant, la couche matérielle. SCEP et EAP-TLS sont des normes neutres vis-à-vis des fournisseurs, ce qui signifie qu'elles fonctionnent sur les points d'accès Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Votre configuration RADIUS, qu'il s'agisse de Windows NPS, FreeRADIUS ou d'un service RADIUS cloud, est l'endroit où vous définissez la politique de validation des certificats et, surtout, où vous configurez l'attribution dynamique de VLAN.

Les VLAN dynamiques permettent de segmenter le réseau par identité. Un appareil d'étudiant obtient le VLAN 20 pour un accès Internet uniquement. Un appareil d'enseignant obtient le VLAN 10 pour l'accès aux systèmes de recherche internes. Un appareil de gestion des installations obtient le VLAN 30 pour l'accès aux systèmes de gestion technique du bâtiment. Tout cela est piloté par les attributs du certificat et la politique RADIUS, sans aucune intervention manuelle par appareil.

Pour l'intégration des fournisseurs d'identité, les attributs de certificat SCEP, en particulier le Subject Alternative Name, peuvent transporter le nom principal de l'utilisateur depuis Microsoft Entra ID, Okta ou Google Workspace. Cela lie le certificat à une identité spécifique, ce qui signifie que lorsque vous désactivez un compte dans Entra ID et que le MDM désinscrit l'appareil, le certificat est révoqué et l'accès WiFi est coupé automatiquement. C'est le scénario de révocation que les clés pré-partagées ne peuvent tout simplement pas offrir.

Très bien, parlons de la séquence de déploiement, car c'est là que la plupart des équipes trébuchent.

La séquence n'est pas négociable : le certificat Trusted Root en premier, le profil de certificat SCEP en deuxième, le profil WiFi en troisième. Intune et Jamf appliquent tous deux des dépendances de profil. Si votre profil WiFi fait référence à un certificat SCEP qui n'a pas encore été déployé sur l'appareil, le profil WiFi échouera avec une erreur cryptique qui ressemble à une mauvaise configuration mais qui n'est en réalité qu'un problème de timing.

Le deuxième piège est le ciblage de groupe. Les trois profils, Trusted Root, SCEP et WiFi, doivent être déployés exactement sur le même groupe Azure AD ou Jamf. Si le profil SCEP cible un groupe d'utilisateurs et le profil WiFi cible un groupe d'appareils, Intune ne pourra pas résoudre la dépendance et le profil WiFi s'affichera comme Non applicable. C'est une erreur classique qui piège constamment les équipes.

Troisièmement : l'accessibilité du serveur NDES. Votre serveur NDES doit être accessible depuis Internet afin que les appareils puissent s'enregistrer avant d'arriver sur site. La bonne méthode consiste à passer par Azure AD Application Proxy, et non à ouvrir un port dans votre pare-feu. App Proxy vous offre un accès distant sécurisé sans ports entrants et vous permet d'appliquer des politiques d'accès conditionnel au flux d'enregistrement.

Quatrièmement : la disponibilité de la CRL. Votre serveur RADIUS vérifie la liste de révocation des certificats (CRL) à chaque fois qu'un appareil s'authentifie. Si votre point de distribution CRL est indisponible, parce qu'un serveur est en panne ou que l'URL a changé, l'authentification échoue simultanément pour tous les appareils du réseau. C'est une panne générale à l'échelle du campus. Rendez vos points de terminaison CRL hautement disponibles et testez la révocation avant la mise en production.

Pour les grands réseaux de plus de 500 appareils, envisagez une passerelle SCEP cloud plutôt qu'un NDES sur site. Les passerelles cloud éliminent le point de défaillance unique du NDES, évoluent horizontalement et s'intègrent généralement directement aux services RADIUS cloud, supprimant ainsi une autre dépendance d'infrastructure.

Abordons maintenant quelques questions rapides fréquemment posées par les CTO.

Le SCEP peut-il gérer les appareils BYOD qui ne sont pas enregistrés dans un MDM ? Pas directement. Le SCEP nécessite un enregistrement MDM pour pousser la charge utile du certificat. Pour le BYOD non géré, vous devez adopter une approche différente, soit un portail d'intégration en libre-service, soit un SSID distinct utilisant un Captive Portal avec vérification d'identité. Purple gère proprement cette couche invités et BYOD, en parallèle de votre réseau d'employés authentifié par certificat.

Qu'en est-il d'iOS et d'Android ? Les deux plateformes prennent en charge le SCEP de manière native. iOS prend en charge le SCEP depuis iOS 4. Android Enterprise prend en charge le SCEP via Intune et d'autres MDM. La configuration diffère légèrement selon la plateforme, mais le protocole sous-jacent est identique.

Le protocole EAP-TLS fonctionne-t-il avec le WPA3 ? Oui. Le WPA3-Enterprise impose un mode de sécurité 192 bits pour les environnements sensibles, et l'EAP-TLS est entièrement compatible. En fait, le WPA3-Enterprise avec EAP-TLS est la combinaison recommandée par la Wi-Fi Alliance pour les réseaux gouvernementaux et financiers.

En résumé : l'authentification WiFi par certificat SCEP est l'architecture idéale pour tout réseau comptant plus de 50 appareils gérés. Elle élimine les identifiants partagés, offre une identité par appareil, permet une segmentation VLAN dynamique et s'intègre directement à votre fournisseur d'identité pour une révocation automatisée. La séquence de déploiement (Trusted Root, puis profil SCEP, puis profil WiFi) est fixe. Le ciblage de groupe doit être cohérent. La disponibilité de la CRL n'est pas facultative.

Pour l'enseignement supérieur en particulier, la combinaison du SCEP pour les appareils du personnel et des enseignants, associée à un réseau WiFi invité distinct pour les étudiants sur leurs appareils personnels, vous offre à la fois une sécurité optimale et une excellente expérience utilisateur, sans compromis.

Si vous souhaitez approfondir le sujet, le guide de Purple sur l'authentification WiFi d'entreprise présente la démarche cloud-native. Et si vous vous interrogez sur la procédure à suivre lorsqu'un employé quitte l'entreprise, notre guide sur la révocation de l'accès WiFi détaille l'ensemble du processus de révocation.

Merci pour votre écoute. Je fais partie de l'équipe technique de Purple, et nous vous retrouverons lors du prochain briefing.

Points clés à retenir

✓SCEP (RFC 8894) automatise l'enrôlement des certificats pour les appareils gérés - la clé privée est générée sur l'appareil et n'est jamais transmise, ce qui en fait le choix idéal pour l'authentification WiFi par rapport à PKCS.
✓La séquence de déploiement est non négociable : le certificat Trusted Root en premier, le profil de certificat SCEP en deuxième, le profil WiFi en troisième. Le non-respect de cet ordre entraîne des échecs de dépendance de profil.
✓Les trois profils MDM (Trusted Root, SCEP, WiFi) doivent cibler exactement le même groupe d'annuaire. Le ciblage multi-groupe est la cause la plus fréquente d'échecs de déploiement.
✓NDES doit être publié via Azure AD Application Proxy, et non exposé directement sur Internet. Pour les réseaux de plus de 500 appareils, une passerelle SCEP cloud élimine le point de défaillance unique de NDES.
✓La disponibilité du point de distribution CRL est une dépendance réseau critique. Si le serveur RADIUS ne peut pas atteindre la CRL, il se bloque par sécurité et refuse simultanément toutes les authentications.
✓EAP-TLS avec des certificats provisionnés par SCEP répond à l'exigence 8.6 de la norme PCI DSS 4.0 pour les réseaux sans fil dans les environnements de données de titulaires de cartes et est requis pour le WPA3-Enterprise 192 bits (Suite B).
✓SCEP ne couvre que les appareils gérés. Les appareils BYOD non gérés et les invités nécessitent un SSID distinct avec Captive Portal et vérification d'identité - la plateforme de Purple gère cette couche aux côtés de votre réseau d'entreprise authentifié par certificat.

📚 Fait partie de notre série principale : Enterprise WiFi Security Guide →

Resumo executivo

Para espaços empresariais - quer se trate de um hotel de 200 quartos, de uma cadeia de retalho com 50 localizações ou de um grande centro de conferências - depender de chaves pré-partilhadas para o WiFi dos funcionários é um risco de segurança e um estrangulamento operacional. Uma única palavra-passe divulgada expõe toda a rede. A autenticação baseada em certificados via IEEE 802.1X e EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina totalmente esse risco. Cada dispositivo prova a sua identidade de forma criptográfica antes de o ponto de acesso lhe conceder acesso à rede.

O desafio reside na distribuição. Implementar manualmente certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android não é viável. O SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 pela IETF em 2020, resolve este problema. Automatiza o processo de solicitação, emissão e instalação de certificados digitais em dispositivos geridos através da sua plataforma MDM - sem qualquer interação do utilizador.

Este guia abrange toda a arquitetura: o que o SCEP faz, como se integra com o Microsoft Intune, Jamf e outras plataformas MDM, a sequência exata de implementação que a maioria das equipas erra e as armadilhas operacionais que causam interrupções de serviço. Também abordamos dois cenários reais de implementação em hotelaria e retalho, e explicamos onde a plataforma de Guest WiFi da Purple se enquadra ao lado da sua rede de funcionários autenticada por certificado.

Ouça o podcast informativo complementar:

Análise técnica detalhada: SCEP, PKI e 802.1X

O que o SCEP realmente faz

O SCEP não substitui a sua Public Key Infrastructure (PKI). É a camada de registo automatizada que se posiciona sobre ela. A sua PKI - normalmente uma hierarquia de dois níveis com uma CA raiz offline e uma CA emissora online - continua a ser a âncora de confiança. O SCEP automatiza a etapa em que um dispositivo solicita um certificado a essa CA, eliminando a necessidade de geração manual de CSR e instalação de certificados.

No contexto da autenticação WiFi, o protocolo de destino é o EAP-TLS. Este é o método de autenticação 802.1X que exige que tanto o dispositivo cliente como o servidor RADIUS apresentem certificados X.509 válidos. Nenhuma das partes confia na outra sem prova criptográfica. Esse modelo de autenticação mútua elimina o roubo de credenciais e protege contra ataques de "evil twin", em que um atacante cria um ponto de acesso falso para recolher nomes de utilizador e palavras-passe.

Para uma análise detalhada do handshake EAP-TLS, consulte o nosso guia sobre WiFi Certificate Authentication: Secure Network Access .

O fluxo de registo SCEP, passo a passo

A cadeia de registo completa funciona da seguinte forma. A sua plataforma MDM - Microsoft Intune, Jamf ou outro MDM - envia um payload SCEP para um dispositivo gerido. Esse payload contém duas coisas: o URL do SCEP que aponta para o seu servidor NDES (Network Device Enrollment Service) ou gateway SCEP na nuvem, e uma palavra-passe de desafio ou segredo partilhado.

O dispositivo gera o seu próprio par de chaves pública e privada localmente. Esta é a propriedade de segurança crítica do SCEP: a chave privada é gerada no dispositivo, armazenada no enclave seguro ou chip TPM, e nunca é transmitida pela rede. O dispositivo cria então um Certificate Signing Request (CSR) e envia-o para o gateway SCEP. O gateway valida a palavra-passe de desafio, encaminha o CSR para a sua Autoridade de Certificação (CA), e a CA assina-o e devolve o certificado público ao dispositivo.

A partir desse momento, quando o dispositivo se liga ao seu SSID de WiFi, apresenta esse certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação à sua cadeia de confiança da CA, verifica a Lista de Revogação de Certificados (CRL) para confirmar que o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem Access-Accept para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o utilizador.

SCEP vs. PKCS: qual utilizar para WiFi

As plataformas MDM como o Intune suportam dois mecanismos de entrega de certificados: SCEP e PKCS (Public Key Cryptography Standards). A diferença arquitetónica é significativa.

Com o SCEP, a chave privada é gerada no dispositivo e nunca sai dele. Com o PKCS, a Autoridade de Certificação gera a chave pública e a privada centralmente, e o conector de certificados envia o par de chaves para o dispositivo através da rede. Isso significa que a chave privada é transmitida, o que introduz uma superfície de ataque teórica.

O PKCS é adequado para casos de utilização em que a custódia de chaves é necessária, como a encriptação de e-mail S/MIME. Para a autenticação WiFi, o SCEP é a escolha correta. A chave privada permanece no dispositivo.

Propriedade	SCEP	PKCS
Geração de chave privada	No dispositivo (TPM/Secure Enclave)	Centralizada (CA)
Transmissão de chave privada	Nunca	Através da rede
Servidor NDES necessário	Sim (ou gateway na nuvem)	Não
Recomendado para WiFi	Sim	Não
Recomendado para S/MIME	Não	Sim

Compatibilidade de hardware

O SCEP e o EAP-TLS são normas independentes de fornecedor. Funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração RADIUS - quer seja Windows NPS, FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e a atribuição dinâmica de VLAN.

A atribuição dinâmica de VLAN é a forma como segmenta a rede através da identidade do dispositivo. Um dispositivo de um funcionário recebe a VLAN 10 com acesso a sistemas internos. O dispositivo de um prestador de serviços recebe a VLAN 20 apenas com acesso à internet. Um terminal de ponto de venda recebe a VLAN 30 apenas com acesso a sistemas de processamento de pagamentos. Tudo isto é gerido por atributos de certificado e pela política RADIUS, sem qualquer intervenção manual por dispositivo.

Para saber mais sobre como o WiFi Analytics se integra com a segmentação de rede baseada em identidade, consulte a nossa visão geral da plataforma de analytics.

Guia de implementação: a sequência de implementação

A configuração bem-sucedida do SCEP para WiFi empresarial exige a adesão estrita a uma sequência de implementação específica. As plataformas MDM impõem dependências de perfil: um perfil de WiFi que faça referência a um certificado SCEP não pode ser aplicado até que esse certificado exista no dispositivo. A violação desta sequência é a causa mais comum de falhas na implementação.

A sequência é: primeiro a Raiz de Confiança (Trusted Root), segundo o perfil SCEP, terceiro o perfil WiFi. Esta ordem não é negociável.

Passo 1: implementar o perfil de Certificado de Raiz de Confiança (Trusted Root)

Antes de qualquer dispositivo poder solicitar um certificado de cliente ou confiar no seu servidor RADIUS, deve confiar na Autoridade de Certificação (CA) emissora. Exporte o seu certificado de CA Raiz - e quaisquer certificados de CA Intermédia - como ficheiros .cer. No seu centro de administração MDM, crie um perfil de Certificado de Confiança, carregue o ficheiro .cer e implemente-o no seu grupo de dispositivos de destino.

Se tiver uma hierarquia PKI de dois níveis (recomendado), precisa de implementar tanto o certificado da CA raiz como o da CA emissora como perfis de Certificado de Confiança separados, ou como uma cadeia num único perfil, dependendo da sua plataforma MDM.

Passo 2: configurar o perfil de Certificado SCEP

Assim que a confiança estiver estabelecida, configure o perfil SCEP para instruir os dispositivos sobre como obter o seu certificado de cliente.

Crie um novo perfil de configuração e selecione o tipo de perfil de certificado SCEP. Configure o formato do Nome do Requerente (Subject name). Para autenticação baseada no utilizador, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivos (dispositivos partilhados, IoT, terminais POS), utilize CN={{AAD_Device_ID}}. Defina a Utilização da chave (Key usage) para Assinatura digital e Cifragem de chave. Defina a Utilização de Chave Alargada (Extended Key Usage) para Autenticação de Cliente (OID: 1.3.6.1.5.5.7.3.2). Associe este perfil ao perfil de certificado de Raiz de Confiança criado no Passo 1. Forneça o URL externo do seu servidor NDES.Para o Microsoft Intune especificamente, o servidor NDES deve ser publicado através do Azure AD Application Proxy para permitir que os dispositivos remotos se registem antes de chegarem ao local. Não exponha o NDES diretamente à internet.

Passo 3: implementar o perfil de WiFi 802.1X

O passo final é enviar a configuração de WiFi que associa os certificados ao SSID da rede. Crie um perfil de configuração de Wi-Fi. Introduza o Nome da rede (SSID) exatamente como é transmitido pelos seus pontos de acesso. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança. Defina o tipo de EAP para EAP-TLS. Nas definições de autenticação, selecione o perfil de certificado SCEP criado no Passo 2 como o certificado de autenticação do cliente. Especifique o certificado Trusted Root para validação do servidor - isto garante que o dispositivo apenas se liga ao seu servidor RADIUS legítimo e não a um ponto de acesso não autorizado.

Integração do fornecedor de identidade

Os atributos do certificado SCEP - especificamente o Subject Alternative Name (SAN) - podem conter o nome principal do utilizador do Microsoft Entra ID, Okta ou Google Workspace. Isto associa o certificado a uma identidade específica. Quando desativa uma conta no Entra ID e o MDM remove o registo do dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa revogação automatizada é a história de segurança que as chaves pré-partilhadas não conseguem igualar.

Para saber mais sobre EAP Method WiFi: A Guide to Secure Network Access , incluindo caminhos de migração PEAP-MSCHAPv2, consulte o nosso guia dedicado.

Boas práticas e padrões da indústria

Posicionamento do servidor NDES

O servidor NDES deve estar acessível a partir da internet para que os dispositivos se possam registar antes de chegarem ao local. Publique o URL do NDES através do Azure AD Application Proxy. Isto fornece um acesso remoto seguro sem abrir portas de firewall de entrada e permite-lhe aplicar políticas de Acesso Condicional ao fluxo de registo. Nunca exponha o NDES diretamente à internet.

Para redes com mais de 500 dispositivos geridos, considere um gateway SCEP na nuvem em vez de um NDES local. Os gateways na nuvem eliminam o ponto único de falha do NDES, escalam horizontalmente e, normalmente, integram-se diretamente com serviços RADIUS na nuvem.

Disponibilidade da CRL

O seu servidor RADIUS verifica a Lista de Revogação de Certificados (CRL) sempre que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL (CDP) estiver indisponível - porque um servidor está em baixo ou o URL mudou - a autenticação falha para todos os dispositivos na rede em simultâneo. Configure o seu servidor NPS ou RADIUS para impor uma verificação rigorosa da CRL e torne os seus endpoints de CRL altamente disponíveis. Teste a revogação antes de entrar em produção.

O Requisito 8.6 do PCI DSS 4.0 exige autenticação multifator na camada de rede para ambientes de dados de titulares de cartões. O EAP-TLS com certificados provisionados por SCEP satisfaz este requisito para redes sem fios em ambientes de Retail e Hospitality .

Compatibilidade com WPA3

O EAP-TLS é totalmente compatível com o WPA3-Enterprise. O WPA3-Enterprise com a suite de segurança de 192 bits (Suite B) exige o EAP-TLS e é a combinação recomendada pela Wi-Fi Alliance para redes governamentais, financeiras e de saúde. Se está a implementar em ambientes de Saúde ou Transportes com requisitos de conformidade rigorosos, o WPA3-Enterprise com EAP-TLS é a arquitetura-alvo correta.

BYOD e WiFi de convidados

O SCEP requer a inscrição no MDM para enviar o payload do certificado. Não abrange dispositivos BYOD não geridos ou convidados. Para esses casos de utilização, necessita de um SSID separado com um Captive Portal e verificação de identidade. A plataforma da Purple lida com essa camada de forma limpa, coexistindo com a sua rede de funcionários autenticada por certificado. A nossa plataforma de Guest WiFi suporta opt-ins de escolha consciente, captura de dados primários (first-party) e integração com o Microsoft Entra ID, Okta e Google Workspace para verificação de identidade.

Resolução de problemas e mitigação de riscos

Falha na aplicação do perfil de WiFi

Sintoma: O dispositivo recebe os certificados Trusted Root e SCEP, mas o perfil de WiFi é apresentado como Erro ou Não Aplicável no MDM.

Causa raiz: Incompatibilidade de segmentação de grupo. Se o perfil SCEP se destinar a um grupo de Utilizadores e o perfil de WiFi se destinar a um grupo de Dispositivos, o MDM não consegue resolver a dependência.

Solução: Audite as suas atribuições. Certifique-se de que os perfis Trusted Root, SCEP e WiFi se destinam todos exatamente ao mesmo grupo de diretório.

Erros NDES 403 Forbidden

Sintoma: Os dispositivos não conseguem obter o certificado SCEP. Os registos do IIS do NDES mostram erros HTTP 403.

Causa raiz: A conta de serviço do MDM Certificate Connector não tem permissões de Leitura e Inscrição (Read and Enroll) no modelo de certificado, ou a filtragem de URLs da firewall está a bloquear os parâmetros de query string do SCEP.

Solução: Verifique se a conta do conector tem permissões de Leitura e Inscrição no modelo da CA. Verifique os registos da firewall para garantir que os URLs que contêm ?operation=GetCACaps não estão bloqueados.

Falha de autenticação em massa após expiração da CRL

Sintoma: Todos os dispositivos na rede falham a autenticação em simultâneo.

Causa raiz: A CRL expirou ou o URL do CDP está inacessível. O servidor RADIUS não consegue confirmar se os certificados são válidos e falha por omissão (fails closed).

Solução: Configure a monitorização e alertas de CRL. Publique as CRLs com um período de validade significativamente superior ao intervalo de publicação. Teste a acessibilidade do CDP a partir do servidor RADIUS antes do lançamento.

Expiração de certificado a causar falhas silenciosas

Sintoma: Dispositivos individuais falham a ligação de forma intermitente, sem um padrão claro.

Causa raiz: Os certificados de cliente expiraram e o MDM não os renovou com sucesso.

Solução: Configure a renovação do certificado para ser acionada a 80% do tempo de vida do certificado. Monitorize os relatórios de estado de inscrição do MDM para dispositivos com erros de certificado. Defina períodos de validade de certificado adequados ao ciclo de atualização dos seus dispositivos - normalmente um a dois anos para endpoints geridos.

ROI e impacto empresarial

A transição para a autenticação por certificado 802.1X baseada em SCEP proporciona retornos mensuráveis em termos de segurança, operações e conformidade.

Redução de pedidos de suporte: O WiFi baseado em palavra-passe gera um volume significativo de pedidos de suporte - expiração de palavras-passe, bloqueios e erros de digitação. A autenticação baseada em certificado é invisível para o utilizador. As organizações registam tipicamente uma redução de 70-80% no volume de suporte relacionado com WiFi após a migração.

Postura de segurança: O EAP-TLS elimina a recolha de credenciais e os ataques Man-in-the-Middle. Isto apoia diretamente a conformidade com a norma PCI DSS 4.0 para redes de retalho e hotelaria, bem como os requisitos do Artigo 32.º do GDPR para medidas técnicas de segurança adequadas.

Revogação automatizada: Quando um colaborador sai da empresa, a desativação da sua conta no Microsoft Entra ID aciona a revogação automática do certificado e a desassociação do MDM. O acesso ao WiFi é cortado sem qualquer intervenção manual por parte da equipa de rede.

Segmentação de rede: A atribuição dinâmica de VLAN através de atributos de certificado RADIUS oferece-lhe uma segmentação de rede aplicada de forma criptográfica. Os dispositivos entram no segmento de rede correto com base nas propriedades do certificado, e não na seleção de SSID ou na filtragem de endereços MAC - ambas facilmente contornáveis.

A Purple opera em mais de 80.000 locais ativos com 99,999% de tempo de atividade, e a nossa plataforma possui as certificações ISO 27001, GDPR, CCPA e Cyber Essentials. A nossa sobreposição de nuvem agnóstica em termos de hardware integra-se com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - para que a sua rede de colaboradores autenticada por certificado e a nossa camada de WiFi de convidados funcionem a partir da mesma infraestrutura.

Para saber mais sobre como a análise comportamental ( Behavioral Analytics: Insights for WiFi Networks ) pode complementar a sua implementação de rede segura, consulte o nosso guia de análise.

Referências

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

Définitions clés

SCEP (Simple Certificate Enrollment Protocol)

Un protocole formalisé dans la RFC 8894 qui permet aux appareils gérés de demander et de recevoir automatiquement des certificats numériques X.509 auprès d'une autorité de certification via HTTP, en utilisant un mot de passe de défi partagé pour l'authentification initiale. La clé privée est générée sur l'appareil et n'est jamais transmise.

Le mécanisme standard utilisé par les plateformes MDM comme Microsoft Intune et Jamf pour déployer à grande échelle des certificats d'authentification WiFi sur les terminaux gérés.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

La méthode d'authentification 802.1X la plus sécurisée, exigeant que l'appareil client et le serveur RADIUS présentent tous deux des certificats X.509 valides. L'authentification mutuelle signifie qu'aucune des parties ne fait confiance à l'autre sans preuve cryptographique.

Le protocole d'authentification cible pour le WiFi d'entreprise. Exigé ou fortement recommandé par PCI DSS 4.0, WPA3-Enterprise 192 bits (Suite B) et HIPAA pour les réseaux sans fil traitant des données sensibles.

NDES (Network Device Enrollment Service)

Un rôle Windows Server de Microsoft qui agit en tant qu'autorité d'enregistrement (RA) entre les appareils compatibles SCEP et une autorité de certification. Il valide les mots de passe de défi et transmet les CSR à l'autorité de certification pour le compte des appareils qui ne disposent pas d'identifiants de domaine.

Infrastructure requise pour le déploiement de SCEP avec Microsoft Intune. Doit être publié via Azure AD Application Proxy plutôt que d'être exposé directement sur Internet.

PKI (Public Key Infrastructure)

La hiérarchie des autorités de certification, des politiques et des procédures utilisées pour émettre, gérer et révoquer des certificats numériques. Une PKI à deux niveaux se compose d'une autorité de certification racine hors ligne (l'ancre de confiance principale) et d'une autorité de certification émettrice en ligne (qui gère l'émission quotidienne des certificats).

Le prérequis non négociable pour le déploiement d'EAP-TLS et de SCEP. L'autorité de certification racine doit être maintenue hors ligne (air-gapped) ; sa clé privée est le fondement de toute votre chaîne de confiance de certificats.

CSR (Certificate Signing Request)

Un message généré par un appareil contenant sa clé publique et ses informations d'identité, envoyé à une autorité de certification pour demander un certificat numérique signé. Dans SCEP, la CSR est générée sur l'appareil et encapsulée dans une enveloppe PKCS avant transmission.

Généré automatiquement par l'appareil lors du flux d'enrôlement SCEP. La clé privée utilisée pour signer la CSR ne quitte jamais l'appareil.

CRL (Certificate Revocation List)

Une liste publiée par l'autorité de certification contenant les numéros de série des certificats qui ont été révoqués avant leur date d'expiration. Les serveurs RADIUS vérifient la CRL à chaque tentative d'authentification pour s'assurer que les certificats révoqués ne peuvent pas accéder au réseau.

La disponibilité du point de distribution de la CRL (CDP) est critique. Si le serveur RADIUS ne peut pas accéder à la CRL, il se bloque par sécurité et refuse toute authentification, provoquant une panne sur l'ensemble du réseau.

RADIUS (Remote Authentication Dial-In User Service)

Un protocole réseau qui fournit une authentification, une autorisation et une traçabilité (AAA) centralisées pour l'accès au réseau. Dans le WiFi 802.1X, le serveur RADIUS valide les certificats des clients, vérifie la CRL et renvoie un message Access-Accept ou Access-Reject au point d'accès.

Le serveur d'authentification dans le modèle client-authentificateur-serveur 802.1X. Les implémentations courantes incluent Windows NPS, FreeRADIUS et les services RADIUS cloud.

Dynamic VLAN assignment

Une fonctionnalité RADIUS qui place un appareil authentifié sur un VLAN spécifique en fonction des attributs du certificat ou de l'appartenance à un groupe d'annuaire, plutôt que de s'appuyer sur la sélection du SSID ou le filtrage d'adresses MAC. Renforce la segmentation du réseau par l'identité de l'appareil.

Permet à un seul SSID de desservir plusieurs types d'appareils avec différents niveaux d'accès au réseau. Un appareil du personnel obtient le VLAN 10 (accès interne) ; un appareil de prestataire obtient le VLAN 20 (Internet uniquement) ; un terminal de point de vente obtient le VLAN 30 (systèmes de paiement uniquement).

MDM (Mobile Device Management)

Logiciel utilisé par les équipes informatiques pour enrôler, configurer, sécuriser et gérer les smartphones, tablettes et ordinateurs portables. Les plateformes MDM comme Microsoft Intune et Jamf utilisent des profils SCEP pour envoyer des instructions d'enrôlement de certificats aux appareils gérés sans intervention de l'utilisateur.

Le prérequis pour le déploiement de certificats basé sur SCEP. Les appareils doivent être enrôlés dans le MDM avant de pouvoir recevoir les profils SCEP et WiFi. Les appareils personnels non gérés (BYOD) nécessitent une approche d'intégration distincte.

Exemples concrets

Un établissement Premier Inn de 200 chambres doit sécuriser son WiFi personnel pour les tablettes de point de vente et les smartphones du service d'étage. Ils utilisent actuellement une clé pré-partagée qui a été divulguée à des prestataires externes. Ils gèrent les appareils via Microsoft Intune et disposent d'un parc mixte d'appareils iOS et Android. L'établissement utilise des points d'accès HPE Aruba.

Déployer une PKI interne Microsoft AD CS à deux niveaux. Configurer NDES sur un serveur Windows Server dédié et le publier via Azure AD Application Proxy.
Dans Intune, créer un profil de certificat racine approuvé contenant les certificats de l'autorité de certification racine et de l'autorité de certification émettrice. Déployer sur un groupe Azure AD "Property Staff Devices".
Créer un profil de certificat SCEP dans Intune pointant vers l'URL externe NDES. Définir le format du nom de l'objet sur CN={{AAD_Device_ID}} car il s'agit d'appareils partagés. Définir l'utilisation de la clé sur Signature numérique et Chiffrement de la clé, et l'utilisation étendue de la clé sur Authentification client. Déployer sur "Property Staff Devices".
Créer un profil Wi-Fi pour l'SSID du personnel, en configurant WPA2-Enterprise et EAP-TLS. Sélectionner le profil SCEP pour l'authentification client et l'autorité de certification racine pour la validation du serveur. Déployer sur "Property Staff Devices".
Configurer les paramètres RADIUS de HPE Aruba pour pointer vers Windows NPS. Sur NPS, configurer une stratégie réseau exigeant EAP-TLS et attribuant le VLAN 10 pour les appareils du personnel.
Une fois que les appareils reçoivent les profils et se connectent avec succès, renouveler la clé PSK sur l'ancien SSID et planifier sa mise hors service.

Commentaire de l'examinateur : Cette approche identifie correctement que les appareils partagés (points de vente, service d'étage) nécessitent une authentification basée sur l'appareil (CN={{AAD_Device_ID}}) plutôt que sur l'utilisateur, car plusieurs membres du personnel utilisent le même appareil. Elle respecte la séquence de déploiement obligatoire des profils et garantit que les trois profils ciblent le même groupe Azure AD. La publication de NDES via App Proxy plutôt qu'une exposition directe sur Internet constitue la posture de sécurité appropriée pour un environnement hôtelier.

Une chaîne de vente au détail comptant 50 points de vente souhaite déployer le protocole 802.1X pour les ordinateurs portables de l'entreprise sur l'ensemble de ses sites. Ils utilisent des points d'accès Cisco Meraki et Microsoft Intune. Ils ne souhaitent pas déployer et maintenir de serveurs NDES sur site ni d'infrastructure AD CS dans chaque point de vente ou dans leur centre de données.

Implémenter un service de passerelle SCEP et PKI basé sur le cloud qui s'intègre à Intune via le protocole SCEP. L'autorité de certification cloud émet les certificats ; la passerelle SCEP cloud gère la validation des demandes de signature de certificat (CSR).
Configurer le service RADIUS cloud (fourni par le fournisseur PKI) dans le tableau de bord Cisco Meraki sous Wireless > Access Control pour l'SSID de l'entreprise. Définir la sécurité sur WPA2-Enterprise et faire pointer RADIUS vers le service cloud.
Dans Intune, créer un profil de certificat racine approuvé contenant le certificat racine de l'autorité de certification cloud. Déployer sur le groupe d'appareils "Corporate Laptops".
Créer un profil de certificat SCEP pointant vers l'URL de la passerelle SCEP cloud. Définir le nom de l'objet sur CN={{UserPrincipalName}} pour une authentification basée sur l'utilisateur. Déployer sur "Corporate Laptops".
Créer un profil Wi-Fi pour l'SSID de l'entreprise avec EAP-TLS, en référençant le profil SCEP et la racine de l'autorité de certification cloud. Déployer sur "Corporate Laptops".
Lorsque les ordinateurs portables s'enregistrent dans Intune, ils demandent automatiquement des certificats à l'autorité de certification cloud via la passerelle SCEP cloud. Aucune infrastructure sur site n'est requise dans l'un des 50 points de vente.

Commentaire de l'examinateur : Il s'agit de l'architecture moderne optimale pour les environnements de vente au détail distribués. En s'appuyant sur une PKI cloud et un service RADIUS cloud, l'entreprise élimine le besoin de maintenir une infrastructure sur site complexe (NDES, AD CS, NPS) sur chaque site. La passerelle SCEP cloud évolue horizontalement et est intrinsèquement hautement disponible, éliminant le point de défaillance unique qu'introduit un serveur NDES sur site. L'architecture gérée par le cloud de Cisco Meraki s'aligne parfaitement avec cette approche.

Questions d'entraînement

Q1. Votre organisation migre de PEAP-MSCHAPv2 vers EAP-TLS. Vous avez déployé avec succès les profils Trusted Root et SCEP sur votre groupe Azure AD « Corporate Users » dans Intune. Vous déployez le profil WiFi sur « All Corporate Devices ». Les utilisateurs signalent qu'ils ne peuvent pas se connecter et le profil WiFi s'affiche comme Non applicable.

Conseil : Vérifiez les dépendances de profil et les règles de ciblage de groupe. Intune résout les dépendances de profil en fonction du groupe attribué.

Voir la réponse type

Le problème est un décalage de ciblage de groupe. Le profil WiFi dépend du profil SCEP, qui ciblait un groupe d'utilisateurs (« Corporate Users »). Le profil WiFi ciblait un groupe d'appareils (« All Corporate Devices »). Intune ne peut pas résoudre la dépendance entre différents types de groupes. La solution consiste à modifier les trois attributions de profil - Trusted Root, SCEP et WiFi - pour cibler le même groupe. Décidez d'utiliser un groupe d'utilisateurs ou un groupe d'appareils en fonction de votre modèle d'authentification (basé sur l'utilisateur ou sur l'appareil), et appliquez-le de manière cohérente sur les trois profils.

Q2. Un audit de sécurité révèle que lorsqu'un employé est licencié et que son compte Microsoft Entra ID est désactivé, son smartphone d'entreprise peut toujours se connecter au réseau WiFi du personnel jusqu'à une semaine après son départ.

Conseil : Considérez comment le serveur RADIUS détermine si un certificat est toujours valide après la désactivation du compte. Quel est le mécanisme de communication du statut de révocation ?

Voir la réponse type

Le serveur RADIUS n'effectue pas de vérification stricte de la liste de révocation de certificats (CRL), ou la CRL est publiée trop rarement. Lorsqu'un employé est licencié, le MDM doit désinscrire l'appareil et l'AC doit révoquer le certificat. Cependant, si le serveur RADIUS ne vérifie pas la CRL à chaque tentative d'authentification - ou si la CRL n'est publiée que de manière hebdomadaire - le certificat révoqué continue d'être accepté. La solution comprend trois étapes : configurer le serveur RADIUS pour imposer une vérification stricte de la CRL à chaque authentification ; configurer l'AC pour publier la CRL à un intervalle plus court (quotidien ou plus fréquent) ; et s'assurer que le MDM est configuré pour déclencher la révocation du certificat lorsqu'un appareil est désinscrit.

Q3. Vous devez fournir un accès WiFi sécurisé pour des appareils IoT sans écran (thermostats intelligents, lecteurs d'affichage dynamique) qui ne peuvent pas exécuter d'agent MDM et ne peuvent pas afficher de Captive Portal. Pouvez-vous utiliser SCEP pour ces appareils, et si non, quelle est l'alternative recommandée ?

Conseil : Considérez les prérequis pour l'inscription SCEP et quelles alternatives existent pour les appareils qui ne peuvent pas être inscrits au MDM ou interagir avec un navigateur.

Voir la réponse type

SCEP ne peut pas être utilisé pour ces appareils. SCEP nécessite un agent MDM pour recevoir l'URL d'inscription et le mot de passe de défi, générer la paire de clés et installer le certificat résultant. Les appareils IoT sans écran qui ne peuvent pas exécuter d'agent MDM ne peuvent pas participer au flux d'inscription SCEP. Les alternatives recommandées sont : (1) le contournement de l'authentification MAC (MAB) combiné à une segmentation VLAN stricte - le serveur RADIUS autorise l'appareil en fonction de son adresse MAC et le place sur un VLAN IoT isolé sans accès aux systèmes de l'entreprise ; (2) si l'appareil le prend en charge, EST (Enrollment over Secure Transport, RFC 7030) peut fournir des certificats aux appareils qui prennent en charge HTTPS mais pas le MDM ; (3) pour les appareils dotés d'une interface de gestion, certains fournisseurs prennent en charge l'inscription SCEP directement via le micrologiciel de l'appareil sans nécessiter d'agent MDM. Dans tous les cas, les appareils IoT doivent être isolés sur un VLAN dédié, quel que soit le mode d'authentification utilisé.

Continuer la lecture de cette série

Comprendre Cisco SUDI : L'identité ancrée dans le matériel pour le contrôle d'accès réseau sécurisé

Ce guide explique comment Cisco SUDI fournit une identité sécurisée par cryptographie et ancrée dans le matériel pour l'infrastructure réseau d'entreprise. Découvrez comment remplacer les adresses MAC falsifiables par des certificats 802.1AR immuables afin de sécuriser le contrôle d'accès réseau de votre site.

Comment implémenter SCEP pour l'enrôlement automatisé de certificats WiFi

Ce guide explique comment implémenter SCEP (Simple Certificate Enrollment Protocol) pour l'enrôlement automatisé de certificats WiFi dans les établissements d'entreprise. Il couvre l'ensemble du schéma architectural - de la conception de la PKI et l'intégration MDM à la séquence de déploiement obligatoire en trois étapes - et montre aux responsables informatiques et architectes réseau comment éliminer les identifiants partagés, automatiser la gestion du cycle de vie des certificats et respecter les exigences PCI DSS et GDPR à grande échelle.

Comprendre Cisco SUDI : l'identité matérielle des périphériques dans le contrôle d'accès au réseau

Ce guide détaille l'architecture technique de Cisco SUDI, en expliquant comment l'identité ancrée au niveau matériel sécurise le contrôle d'accès au réseau. Il fournit des étapes de mise en œuvre concrètes pour les responsables informatiques afin de déployer l'authentification 802.1X EAP-TLS et d'automatiser le Zero Touch Provisioning sur les sites de l'entreprise.