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,282 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.

Résumé exécutif

Pour les entreprises — qu'il s'agisse d'un hôtel de 200 chambres, d'une chaîne de vente au détail de 50 sites ou d'un grand centre de conférence — s'appuyer sur des clés pré-partagées pour le WiFi du personnel constitue une faille de sécurité et un goulot d'étranglement opérationnel. Un seul mot de passe divulgué expose l'ensemble du réseau. L'authentification par certificat via IEEE 802.1X et EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) élimine entièrement ce risque. Chaque appareil prouve son identité de manière cryptographique avant que le point d'accès ne lui accorde l'accès au réseau.

Le défi réside dans la distribution. Déployer manuellement des certificats clients uniques sur des milliers d'appareils Windows, iOS et Android n'est pas viable. Le protocole SCEP (Simple Certificate Enrollment Protocol), formalisé sous le nom de RFC 8894 par l'IETF en 2020, résout ce problème. Il automatise le processus de demande, d'émission et d'installation de certificats numériques sur les appareils gérés via votre plateforme MDM, sans aucune interaction de l'utilisateur.

Ce guide couvre l'intégralité de l'architecture : le rôle de SCEP, son intégration avec Microsoft Intune, Jamf et d'autres plateformes MDM, la séquence de déploiement exacte que la plupart des équipes configurent mal, ainsi que les pièges opérationnels qui provoquent des pannes. Nous abordons également deux scénarios de mise en œuvre réels dans l'hôtellerie et le commerce de détail, et expliquons comment la plateforme Guest WiFi de Purple s'intègre aux côtés de votre réseau pour le personnel authentifié par certificat.

Écoutez le podcast d'accompagnement :

Analyse technique approfondie : SCEP, PKI et 802.1X

Ce que fait réellement SCEP

SCEP ne remplace pas votre infrastructure à clés publiques (PKI). Il s'agit de la couche d'enregistrement automatisée qui se superpose à celle-ci. Votre PKI — généralement une hiérarchie à deux niveaux avec une autorité de certification (CA) racine hors ligne et une CA d'émission en ligne — reste l'ancre de confiance. SCEP automatise l'étape au cours de laquelle un appareil demande un certificat à cette CA, éliminant ainsi le besoin de générer manuellement des CSR et d'installer des certificats.

Dans le cadre de l'authentification WiFi, le protocole cible est EAP-TLS. Il s'agit de la méthode d'authentification 802.1X qui exige que l'appareil client et le serveur RADIUS présentent tous deux des certificats X.509 valides. Aucune des deux parties ne fait confiance à l'autre sans preuve cryptographique. Ce modèle d'authentification mutuelle élimine le vol d'identifiants et protège contre les attaques de type "evil twin", où un attaquant déploie un point d'accès malveillant pour intercepter les noms d'utilisateur et les mots de passe.

Pour une analyse détaillée de la liaison EAP-TLS, consultez notre guide sur WiFi Certificate Authentication: Secure Network Access .

Le flux d'enrôlement SCEP, étape par étape

La chaîne d'enrôlement complète fonctionne comme suit. Votre plateforme MDM - Microsoft Intune, Jamf ou un autre MDM - pousse une charge utile SCEP vers un appareil géré. Cette charge utile contient deux éléments : l'URL SCEP pointant vers votre serveur NDES (Network Device Enrollment Service) 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 la propriété de sécurité essentielle de SCEP : la clé privée est générée sur l'appareil, stockée dans l'enclave sécurisée ou la puce TPM, et n'est jamais transmise sur le réseau. L'appareil crée ensuite une demande de signature de certificat (CSR) et l'envoie à la passerelle SCEP. La passerelle valide le mot de passe de défi, transmet la CSR à votre autorité de certification (CA), et la CA la 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 de certificats (CRL) pour confirmer que le certificat n'a pas été révoqué, et si tout est correct, envoie un message Access-Accept au point d'accès. L'appareil est sur le réseau. L'ensemble du processus est invisible pour l'utilisateur.

SCEP vs PKCS : lequel utiliser pour le WiFi

Les plateformes MDM comme Intune prennent en charge deux mécanismes de distribution de certificats : SCEP et PKCS (Public Key Cryptography Standards). La différence architecturale est significative.

Avec SCEP, la clé privée est générée sur l'appareil et ne le quitte jamais. Avec PKCS, l'autorité de certification 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 via le réseau. Cela signifie que la clé privée est transmise, ce qui introduit une surface d'attaque théorique.

Le PKCS est approprié pour les cas d'usage où le séquestre de clés est requis, comme le chiffrement d'e-mails S/MIME. Pour l'authentification WiFi, SCEP est le choix correct. La clé privée reste sur l'appareil.

Propriété	SCEP	PKCS
Génération de la clé privée	Sur l'appareil (TPM/Enclave sécurisée)	Centralisée (CA)
Transmission de la clé privée	Jamais	Via le réseau
Serveur NDES requis	Oui (ou passerelle cloud)	Non
Recommandé pour le WiFi	Oui	Non
Recommandé pour S/MIME	Non	Oui

Compatibilité matérielle

SCEP et EAP-TLS sont des standards universels, indépendants des constructeurs. Ils 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 l'attribution dynamique de VLAN.

L'attribution dynamique de VLAN vous permet de segmenter le réseau en fonction de l'identité de l'appareil. Un appareil du personnel obtient le VLAN 10 avec accès aux systèmes internes. Un appareil de prestataire obtient le VLAN 20 avec un accès Internet uniquement. Un terminal de point de vente obtient le VLAN 30 avec un accès exclusif aux systèmes de traitement des paiements. Tout cela est géré par les attributs de certificat et la politique RADIUS, sans aucune intervention manuelle par appareil.

Pour en savoir plus sur la manière dont WiFi Analytics s'intègre à la segmentation réseau basée sur l'identité, consultez notre présentation de la plateforme d'analyse.

Guide de mise en œuvre : la séquence de déploiement

La configuration réussie de SCEP pour le WiFi d'entreprise exige le respect strict d'une séquence de déploiement spécifique. Les plateformes MDM imposent des dépendances de profil : un profil WiFi qui fait référence à un certificat SCEP ne peut pas s'appliquer tant que ce certificat n'existe pas sur l'appareil. Le non-respect de cette séquence est la cause la plus fréquente d'échec de déploiement.

La séquence est la suivante : d'abord la racine de confiance (Trusted Root), puis le profil SCEP, et enfin le profil WiFi. Cet ordre est non négociable.

Étape 1 : déployer le profil de certificat de racine de confiance (Trusted Root)

Avant qu'un appareil ne puisse demander un certificat client ou faire confiance à votre serveur RADIUS, il doit faire confiance à l'autorité de certification émettrice. Exportez votre certificat de CA racine - et tous les certificats de CA intermédiaires - sous forme de fichiers .cer. Dans votre centre d'administration MDM, créez un profil de certificat de confiance, téléchargez le fichier .cer et déployez-le sur votre groupe d'appareils cible.

Si vous disposez d'une hiérarchie PKI à deux niveaux (recommandé), vous devez déployer à la fois les certificats de la CA racine et de la CA émettrice sous forme de profils de certificats de confiance distincts, ou sous forme de chaîne dans un profil unique, selon votre plateforme MDM.

Étape 2 : configurer le profil de certificat SCEP

Une fois la confiance établie, configurez le profil SCEP pour indiquer aux appareils comment obtenir leur certificat client.

Créez un nouveau profil de configuration et sélectionnez le type de profil de certificat SCEP. Configurez le format du nom de l'objet (Subject name). Pour l'authentification basée sur l'utilisateur, CN={{UserPrincipalName}} est la norme. Pour l'authentification d'appareil (appareils partagés, IoT, terminaux de point de vente), utilisez CN={{AAD_Device_ID}}. Définissez l'utilisation de la clé (Key usage) sur Signature numérique et Chiffrement de clé. Définissez l'utilisation étendue de la clé (Extended Key Usage) sur Authentification client (OID : 1.3.6.1.5.5.7.3.2). Associez ce profil au profil de certificat de racine de confiance créé à l'étape 1. Renseignez l'URL externe de votre serveur NDES.Pour Microsoft Intune spécifiquement, le serveur NDES doit être publié via Azure AD Application Proxy pour permettre aux appareils distants de s'enregistrer avant d'arriver sur site. N'exposez pas le NDES directement sur Internet.

Étape 3 : déployer le profil WiFi 802.1X

La dernière étape consiste à pousser la configuration WiFi qui lie les certificats au SSID du réseau. Créez un profil de configuration Wi-Fi. Saisissez le nom du réseau (SSID) exactement tel qu'il est diffusé par vos points d'accès. Sélectionnez WPA2-Enterprise ou WPA3-Enterprise comme type de sécurité. Définissez le type EAP sur EAP-TLS. Dans les paramètres d'authentification, sélectionnez le profil de certificat SCEP créé à l'Étape 2 comme certificat d'authentification client. Spécifiez le certificat racine de confiance pour la validation du serveur - cela garantit que l'appareil se connecte uniquement à votre serveur RADIUS légitime et non à un point d'accès pirate.

Intégration du fournisseur d'identité

Les attributs du certificat SCEP - en particulier le Subject Alternative Name (SAN) - peuvent porter le nom principal de l'utilisateur provenant de Microsoft Entra ID, Okta ou Google Workspace. Cela lie le certificat à une identité spécifique. 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. Cette révocation automatisée est l'argument de sécurité que les clés pré-partagées ne peuvent pas égaler.

Pour en savoir plus sur EAP Method WiFi: A Guide to Secure Network Access , y compris les chemins de migration PEAP-MSCHAPv2, consultez notre guide dédié.

Bonnes pratiques et normes de l'industrie

Emplacement du serveur NDES

Le serveur NDES doit être accessible depuis Internet afin que les appareils puissent s'enregistrer avant d'arriver sur site. Publiez l'URL NDES via Azure AD Application Proxy. Cela fournit un accès distant sécurisé sans ouvrir de ports de pare-feu entrants et vous permet d'appliquer des politiques d'accès conditionnel au flux d'enregistrement. N'exposez jamais le NDES directement sur Internet.

Pour les réseaux comptant plus de 500 appareils gérés, 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.

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 de CRL (CDP) est indisponible - parce qu'un serveur est en panne ou que l'URL a changé - l'authentification échoue pour tous les appareils du réseau simultanément. Configurez votre serveur NPS ou RADIUS pour imposer une vérification stricte de la CRL, et rendez vos points de terminaison de CRL hautement disponibles. Testez la révocation avant la mise en production.

La spécification PCI DSS 4.0 Exigence 8.6 impose une authentification multifacteur au niveau de la couche réseau pour les environnements de données de titulaires de cartes. L'EAP-TLS avec des certificats provisionnés par SCEP répond à cette exigence pour les réseaux sans fil dans les environnements de Retail et de Hospitality .

Compatibilité WPA3

EAP-TLS est entièrement compatible avec WPA3-Enterprise. WPA3-Enterprise avec la suite de sécurité 192 bits (Suite B) impose EAP-TLS et constitue la combinaison recommandée par la Wi-Fi Alliance pour les réseaux gouvernementaux, financiers et de santé. Si vous effectuez un déploiement dans des environnements de Santé ou de Transport avec des exigences de conformité strictes, WPA3-Enterprise avec EAP-TLS est l'architecture cible appropriée.

BYOD et WiFi invités

SCEP nécessite un enregistrement MDM pour pousser la charge utile du certificat. Il ne couvre pas les appareils BYOD non gérés ou les invités. Pour ces cas d'usage, vous avez besoin d'un SSID distinct avec un Captive Portal et une vérification d'identité. La plateforme de Purple gère cette couche proprement, en parallèle de votre réseau d'employés authentifié par certificat. Notre plateforme de Guest WiFi prend en charge les opt-ins de choix conscient, la capture de données de première partie et l'intégration avec Microsoft Entra ID, Okta et Google Workspace pour la vérification d'identité.

Dépannage et atténuation des risques

Échec de l'application du profil WiFi

Symptôme : L'appareil reçoit les certificats Trusted Root et SCEP, mais le profil WiFi s'affiche comme Erreur ou Non applicable dans le MDM.

Cause racine : Incohérence dans le ciblage des groupes. Si le profil SCEP cible un groupe d'utilisateurs et que le profil WiFi cible un groupe d'appareils, le MDM ne peut pas résoudre la dépendance.

Solution : Auditez vos affectations. Assurez-vous que les profils Trusted Root, SCEP et WiFi ciblent tous exactement le même groupe d'annuaire.

Erreurs NDES 403 Forbidden

Symptôme : Les appareils ne parviennent pas à récupérer le certificat SCEP. Les journaux IIS de NDES affichent des erreurs HTTP 403.

Cause racine : Le compte de service du connecteur de certificat MDM ne dispose pas des autorisations de lecture et d'inscription (Read and Enroll) sur le modèle de certificat, ou le filtrage d'URL du pare-feu bloque les paramètres de chaîne de requête SCEP.

Solution : Vérifiez que le compte du connecteur dispose des autorisations de lecture et d'inscription sur le modèle de l'autorité de certification (CA). Vérifiez les journaux du pare-feu pour vous assurer que les URL contenant ?operation=GetCACaps ne sont pas bloquées.

Échec d'authentification de masse après l'expiration de la CRL

Symptôme : Tous les appareils du réseau échouent à s'authentifier simultanément.

Cause racine : La CRL a expiré ou l'URL du CDP est inaccessible. Le serveur RADIUS ne peut pas confirmer la validité des certificats et refuse l'accès par sécurité.

Solution : Configurez la surveillance et les alertes de la CRL. Publiez les CRL avec une période de validité nettement supérieure à l'intervalle de publication. Testez l'accessibilité du CDP depuis le serveur RADIUS avant la mise en production.

L'expiration des certificats provoque des pannes silencieuses

Symptôme : Des appareils individuels ne parviennent pas à se connecter par intermittence, sans motif clair.

Cause racine : Les certificats clients ont expiré et le MDM n'a pas réussi à les renouveler.

Solution : Configurez le renouvellement des certificats pour qu'il se déclenche à 80 % de la durée de vie du certificat. Surveillez les rapports d'état d'enregistrement MDM pour les appareils présentant des erreurs de certificat. Définissez des périodes de validité de certificat adaptées au cycle de renouvellement de vos appareils - généralement un à deux ans pour les terminaux gérés.

ROI et impact commercial

La transition vers l'authentification par certificat 802.1X basée sur SCEP offre des rendements mesurables en matière de sécurité, d'opérations et de conformité.

Réduction des tickets de support : Le WiFi basé sur mot de passe génère un volume important de tickets de support : expirations de mots de passe, verrouillages et fautes de frappe. L'authentification par certificat est invisible pour l'utilisateur. Les organisations constatent généralement une réduction de 70 à 80 % du volume de support lié au WiFi après la migration.

Posture de sécurité : EAP-TLS élimine la collecte d'identifiants et les attaques de type Man-in-the-Middle. Cela soutient directement la conformité PCI DSS 4.0 pour les réseaux de vente au détail et d'hôtellerie, ainsi que les exigences de l'article 32 du GDPR concernant les mesures de sécurité techniques appropriées.

Révocation automatisée : Lorsqu'un employé s'en va, la désactivation de son compte dans Microsoft Entra ID déclenche la révocation automatique du certificat et le désenrôlement du MDM. L'accès WiFi est coupé sans aucune intervention manuelle de l'équipe réseau.

Segmentation du réseau : L'attribution dynamique de VLAN via les attributs de certificat RADIUS vous offre une segmentation de réseau renforcée par cryptographie. Les appareils se connectent au bon segment de réseau en fonction des propriétés du certificat, et non de la sélection du SSID ou du filtrage d'adresses MAC — deux méthodes qui peuvent être facilement contournées.

Purple opère sur plus de 80 000 sites actifs avec une disponibilité de 99,999 %, et notre plateforme est certifiée ISO 27001, GDPR, CCPA et Cyber Essentials. Notre superposition cloud indépendante du matériel s'intègre avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet — ainsi, votre réseau d'entreprise authentifié par certificat et notre couche Captive Portal pour invités fonctionnent à partir de la même infrastructure.

Pour en savoir plus sur la façon dont l'analyse comportementale Behavioral Analytics: Insights for WiFi Networks peut compléter votre déploiement réseau sécurisé, consultez notre guide d'analyse.

Références

[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

Le guide de l'entreprise pour SCEP : Déployer le protocole SCEP (Simple Certificate Enrollment Protocol) pour la sécurité automatisée du WiFi sur les campus

Ce guide de référence technique fournit un schéma d'architecture définitif et une stratégie d'implémentation étape par étape pour le déploiement de certificats WiFi d'entreprise à l'aide de SCEP. Il présente les différences cruciales entre SCEP et PKCS, la séquence de déploiement exacte requise pour réussir, ainsi que des stratégies concrètes de mitigation des risques pour les responsables informatiques.

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.