Déploiement de certificats WiFi Microsoft Intune via SCEP et PKCS
Ce guide constitue une référence technique étape par étape pour le déploiement de certificats d'authentification WiFi via Microsoft Intune à l'aide de SCEP et PKCS. Il est conçu pour les responsables informatiques et les architectes réseau mettant en œuvre le WiFi 802.1X sans mot de passe afin de garantir une connectivité fluide et sécurisée dans les environnements d'entreprise.
Résumé analytique
Pour les sites d'entreprise — qu'il s'agisse d'un environnement Hôtellerie dynamique, d'une exploitation Retail multi-sites ou d'un campus d'entreprise moderne — s'appuyer sur des clés pré-partagées ou des Captive Portal basiques pour le WiFi du personnel constitue une vulnérabilité de sécurité et un goulot d'étranglement opérationnel. L'architecture réseau moderne exige une authentification 802.1X utilisant EAP-TLS, garantissant que chaque appareil est vérifié par cryptographie avant d'accéder au réseau.
Cependant, le défi réside dans la distribution : comment déployer des certificats clients uniques sur des milliers d'appareils Windows, iOS et Android sans submerger votre support technique de tickets ? Microsoft Intune résout ce problème grâce à la gestion automatisée du cycle de vie des certificats. En exploitant les profils de certificat SCEP (Simple Certificate Enrollment Protocol) ou PKCS (Public Key Cryptography Standards), les équipes informatiques peuvent pousser silencieusement des certificats racines et clients de confiance vers les terminaux gérés.
Ce guide fournit un modèle architectural définitif et une stratégie de mise en œuvre étape par étape pour le déploiement de certificats WiFi Intune. Nous explorerons les différences critiques entre SCEP et PKCS, détaillerons la séquence de déploiement exacte requise pour réussir et présenterons des stratégies de réduction des risques en conditions réelles pour garantir que votre Guest WiFi et vos réseaux d'entreprise restent sécurisés et performants.
Écoutez le briefing podcast d'accompagnement :
Analyse technique approfondie : SCEP vs PKCS
Lors de la conception de votre stratégie de déploiement de certificats WiFi Intune, la première décision architecturale est de sélectionner le mécanisme de distribution des certificats. Intune prend en charge SCEP et PKCS, mais ils fonctionnent de manière fondamentalement différente.
SCEP (Simple Certificate Enrollment Protocol)
SCEP est la norme de l'industrie pour l'enrôlement des appareils en entreprise. Dans un flux de travail SCEP, le service Intune demande au terminal de générer sa propre paire de clés privée/publique. L'appareil crée ensuite une demande de signature de certificat (CSR) et l'envoie via un serveur NDES (Network Device Enrollment Service) à votre autorité de certification (CA). La CA signe la demande et renvoie le certificat public à l'appareil.
L'avantage de sécurité critique de SCEP est que la clé privée ne quitte jamais l'appareil. Elle est générée localement, stockée dans l'enclave sécurisée de l'appareil (comme le TPM sur Windows ou la Secure Enclave sur iOS), et n'est jamais transmise sur le réseau. Cela fait de SCEP l'approche fortement recommandée pour l'authentification 802.1X.
PKCS (Public Key Cryptography Standards)
À l'inverse, avec PKCS, l'autorité de certification génère les clés publique et privée de manière centralisée. Le Microsoft Intune Certificate Connector exporte ensuite cette paire de clés de manière sécurisée et la pousse vers l'appareil cible.
Bien que PKCS élimine la nécessité de déployer et de maintenir un serveur NDES — simplifiant ainsi l'empreinte de l'infrastructure — il introduit un risque de sécurité théorique car la clé privée est transmise sur le réseau. PKCS est généralement mieux adapté aux cas d'utilisation où le séquestre de clés est requis, comme le chiffrement d'e-mails S/MIME, plutôt qu'à l'authentification réseau.
Guide de mise en œuvre : La séquence de déploiement
La configuration réussie d'un profil WiFi Intune pour le 802.1X nécessite le respect strict d'une séquence de déploiement spécifique. Les dépendances des profils Intune dictent que la confiance doit être établie avant que l'authentification puisse être configurée.
Étape 1 : Déployer le profil de certificat racine de confiance
Avant qu'un appareil puisse demander un certificat client ou faire confiance à votre serveur RADIUS, il doit faire confiance à l'autorité de certification émettrice.
- Exportez votre certificat CA racine (et tout certificat CA intermédiaire) sous forme de fichiers
.cer. - Dans le centre d'administration Microsoft Endpoint Manager, accédez à Appareils > Profils de configuration > Créer un profil.
- Sélectionnez la plateforme cible (par exemple, Windows 10 et versions ultérieures) et choisissez le type de profil Certificat de confiance.
- Téléchargez le fichier
.ceret déployez ce profil sur vos groupes d'appareils cibles.
Règle d'or : ciblez toujours les mêmes groupes (utilisateurs ou appareils) sur tous les profils associés afin d'éviter les erreurs de déploiement.
É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 Certificat SCEP.
- Configurez le Format du nom de l'objet. Pour l'authentification basée sur l'utilisateur,
CN={{UserPrincipalName}}est la norme. Pour l'authentification de l'appareil, utilisezCN={{AAD_Device_ID}}. - Définissez l'Utilisation de la clé sur
Signature numériqueetChiffrement de la clé. - Sous Utilisation étendue de la clé, spécifiez
Authentification client(OID : 1.3.6.1.5.5.7.3.2). - Liez ce profil au profil de certificat racine de confiance créé à l'étape 1.
- Fournissez l'URL externe de votre serveur NDES.
É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 sans fil .
- 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 de racine de confiance (Trusted Root) pour la validation du serveur afin de garantir que l'appareil se connecte uniquement à votre serveur RADIUS légitime.
Meilleures pratiques et standards de l'industrie
Lors de la mise en œuvre du déploiement de certificats WiFi Intune, respectez les meilleures pratiques neutres vis-à-vis des fournisseurs suivantes pour garantir la conformité et la fiabilité.
Emplacement et sécurité du serveur NDES
Le serveur NDES doit être accessible depuis Internet pour permettre aux appareils distants de provisionner des certificats avant d'arriver sur site. Cependant, l'exposition directe d'un serveur interne à Internet constitue un risque de sécurité important.
Recommandation : Publiez l'URL NDES à l'aide d'Azure AD Application Proxy. Cela offre 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'enrôlement.
Vérification RADIUS et CRL
Le déploiement de certificats n'est que la moitié de l'équation de sécurité ; la révocation est tout aussi critique. Si un employé est licencié, la désactivation de son compte Active Directory peut ne pas révoquer immédiatement son accès WiFi si son certificat client reste valide et que le serveur RADIUS ne vérifie pas strictement la liste de révocation de certificats (CRL).
Recommandation : Configurez votre serveur de stratégie réseau (NPS) ou votre serveur RADIUS pour imposer une vérification stricte de la CRL. Assurez-vous que vos points de distribution CRL (CDP) sont hautement disponibles ; si le serveur RADIUS ne peut pas atteindre la CRL, l'authentification échouera, provoquant une panne généralisée.
Pour en savoir plus sur la conception de réseaux sécurisés, consultez Les principaux avantages du SD-WAN pour les entreprises modernes .
Dépannage et atténuation des risques
Même avec une planification méticuleuse, le déploiement de certificats peut rencontrer des problèmes. Voici les modes de défaillance courants et les stratégies d'atténuation.
Problème : É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 Intune.
Cause racine : Cela est presque toujours dû à une discordance dans le ciblage des groupes. Si le profil SCEP est affecté à un groupe d'utilisateurs, mais que le profil WiFi est affecté à un groupe d'appareils, Intune ne peut pas résoudre la dépendance.
Atténuation : Auditez vos affectations. Assurez-vous que les profils Trusted Root, SCEP et WiFi sont tous déployés sur le même groupe Azure AD.
Problème : Erreurs NDES 403 Forbidden
Symptôme : Les appareils ne parviennent pas à récupérer le certificat SCEP et les journaux IIS de NDES affichent des erreurs HTTP 403.
Cause racine : Le compte de service Intune Certificate Connector ne dispose pas des autorisations nécessaires sur le modèle de certificat, ou le filtrage d'URL sur votre pare-feu bloque les paramètres de chaîne de requête spécifiques utilisés par SCEP.
Atténuation : Vérifiez que le compte du connecteur dispose des autorisations « Lecture » et « 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.
ROI et impact commercial
La transition vers le déploiement de certificats Microsoft Intune 802.1X offre des retours mesurables en termes de sécurité et d'opérations.
- Réduction des tickets d'assistance : Le WiFi basé sur mot de passe génère un volume important de tickets de support (expirations de mots de passe, verrouillages, fautes de frappe). L'authentification par certificat est invisible pour l'utilisateur, réduisant généralement le volume de tickets d'assistance liés au WiFi de 70 à 80 %.
- Amélioration de la posture de sécurité : EAP-TLS élimine le risque de vol d'identifiants et d'attaques de type Man-in-the-Middle (MitM). C'est crucial pour la conformité avec des cadres tels que PCI DSS et GDPR, particulièrement dans les secteurs de la Santé et de la vente au détail.
- Intégration fluide : Pour les organisations gérant de grandes flottes d'appareils Apple aux côtés de Windows, l'intégration d'Intune aux flux de travail MDM existants (voir notre guide sur Jamf et RADIUS : Authentification WiFi par certificat pour les flottes d'appareils Apple ) garantit une expérience de provisionnement unifiée et sans contact dès le premier jour.
Termes clés et définitions
SCEP (Simple Certificate Enrollment Protocol)
A protocol that allows devices to request digital certificates from a Certificate Authority, where the private key is generated and stored securely on the device itself.
The recommended method for deploying WiFi authentication certificates due to its high security and scalability.
PKCS (Public Key Cryptography Standards)
A set of standards where both the public and private keys are generated by the Certificate Authority and then securely delivered to the endpoint.
Often used for S/MIME email encryption, but less ideal for WiFi due to the network transmission of the private key.
NDES (Network Device Enrollment Service)
A Microsoft Windows Server role that acts as a bridge, allowing devices without domain credentials to obtain certificates via SCEP.
A required infrastructure component when implementing SCEP certificate deployment with Microsoft Intune.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
The most secure 802.1X authentication method, requiring both the server and the client to present valid digital certificates.
The target authentication protocol that the Intune WiFi and certificate profiles are designed to enable.
CRL (Certificate Revocation List)
A list published by the Certificate Authority containing the serial numbers of certificates that have been revoked before their expiration date.
Critical for security; RADIUS servers must check the CRL to ensure terminated employees cannot access the WiFi using an otherwise valid certificate.
Intune Certificate Connector
A software agent installed on an on-premises Windows Server that brokers requests between Microsoft Intune and the internal Certificate Authority.
Required for both SCEP (to validate requests) and PKCS (to export keys) deployments.
Subject Alternative Name (SAN)
An extension to a digital certificate that allows multiple values (like UPN, email, or MAC address) to be associated with the certificate.
Configured in the Intune SCEP profile to ensure the RADIUS server can accurately identify the user or device.
Azure AD Application Proxy
A feature that provides secure remote access to on-premises web applications without requiring a VPN or opening inbound firewall ports.
The best practice method for securely publishing the internal NDES server URL to the internet for remote device enrollment.
Études de cas
A national retail chain with 500 locations is migrating from WPA2-Personal (Pre-Shared Key) to WPA3-Enterprise for their store associate tablets (Android Enterprise Dedicated Devices). They use Intune for MDM. How should they architect the certificate deployment?
- Deploy an NDES server published via Azure AD App Proxy.
- Create a Device-based SCEP certificate profile in Intune, as these are dedicated (kiosk) devices not tied to a specific user. Use
CN={{AAD_Device_ID}}for the Subject Name. - Deploy the Root CA profile to the 'All Store Tablets' Azure AD Device Group.
- Deploy the SCEP profile to the same 'All Store Tablets' group.
- Create a Wi-Fi profile configured for WPA3-Enterprise, EAP-TLS, referencing the SCEP profile, and deploy it to the same group.
- Configure the central RADIUS servers to authenticate the device certificates against the Active Directory computer objects.
A large conference centre uses Purple for their [WiFi Analytics](/products/wifi-analytics) and Guest WiFi, but needs to secure their internal staff network. Staff use a mix of corporate-owned Windows laptops and BYOD iOS devices. How do they handle the Intune deployment for the BYOD devices?
- Require BYOD users to enroll their iOS devices via Intune User Enrollment (creating a secure work partition).
- Create a User-based SCEP certificate profile using
CN={{UserPrincipalName}}. - Deploy the Root CA, SCEP, and Wi-Fi profiles to an Azure AD User Group (e.g., 'All Staff').
- When the user enrolls their personal device, Intune pushes the profiles specifically to the managed work partition.
- The device connects to the staff SSID using the user's identity, allowing the RADIUS server to apply role-based access control (VLAN assignment) based on their AD group membership.
Analyse de scénario
Q1. You have deployed the Root CA, SCEP, and Wi-Fi profiles to your Windows 10 devices. The certificates install successfully, but the Wi-Fi profile fails to apply, showing 'Error' in the Intune console. What is the most likely cause?
💡 Astuce :Check how the profiles are assigned to Azure AD groups.
Afficher l'approche recommandée
The most likely cause is a mismatch in group targeting. If the SCEP profile was assigned to a User Group, but the Wi-Fi profile was assigned to a Device Group, Intune cannot resolve the dependency between them. All three profiles (Root, SCEP, Wi-Fi) must be targeted to the exact same group type.
Q2. Your security team mandates that private keys must never be transmitted across the network, even if encrypted. Which certificate deployment method must you use in Intune, and what additional infrastructure server is required?
💡 Astuce :Think about where the key pair is generated.
Afficher l'approche recommandée
You must use SCEP (Simple Certificate Enrollment Protocol). Because SCEP instructs the endpoint device to generate the private key locally, it never traverses the network. This deployment requires a Network Device Enrollment Service (NDES) server to act as a bridge to the Certificate Authority.
Q3. A remote employee provisions a new laptop at home via Windows Autopilot. The Intune profiles deploy successfully, but the device fails to obtain the SCEP certificate. What infrastructure configuration is likely missing?
💡 Astuce :How does the device reach the internal CA from the internet?
Afficher l'approche recommandée
The NDES server has likely not been published to the internet. For remote devices to request certificates before arriving at the corporate office, the NDES URL must be externally accessible, ideally published securely via Azure AD Application Proxy.
Points clés à retenir
- ✓802.1X EAP-TLS is the standard for secure enterprise WiFi, requiring client certificates on all devices.
- ✓Microsoft Intune automates certificate deployment at scale using SCEP or PKCS profiles.
- ✓SCEP is highly recommended for WiFi as the private key is generated locally and never leaves the device.
- ✓Deployment requires a strict sequence: 1) Trusted Root, 2) SCEP Profile, 3) Wi-Fi Profile.
- ✓Group targeting (User vs. Device) must be identical across all three profiles to prevent dependency failures.
- ✓NDES servers should be published via Azure AD App Proxy to allow secure, remote certificate provisioning.
- ✓Strict CRL checking on the RADIUS server is mandatory to ensure revoked certificates cannot access the network.
