Déploiement de certificats WiFi Microsoft Intune via SCEP et PKCS

Synthèse

Pour les entreprises — qu'il s'agisse d'un secteur dynamique comme l' Hôtellerie , d'un réseau de points de vente Retail ou d'un campus d'entreprise moderne —, s'appuyer sur des clés pré-partagées ou des portails captifs basiques pour le WiFi du personnel constitue une faille de sécurité et un goulot d'étranglement opérationnel. L'architecture réseau moderne exige une authentification 802.1X via 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 d'assistance ? Microsoft Intune résout ce problème grâce à la gestion automatisée du cycle de vie des certificats. En s'appuyant sur des profils de certificats SCEP (Simple Certificate Enrollment Protocol) ou PKCS (Public Key Cryptography Standards), les équipes informatiques peuvent pousser silencieusement des certificats racines et clients approuvés vers les terminaux gérés.

Ce guide fournit un modèle d'architecture définitif et une stratégie de mise en œuvre étape par étape pour le déploiement de certificats WiFi via 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 concrètes de réduction des risques pour garantir que votre Guest WiFi et vos réseaux d'entreprise restent sécurisés et performants.

Écoutez le podcast d'accompagnement :

Analyse technique approfondie : SCEP vs. PKCS

Lors de la conception de votre stratégie de déploiement de certificats WiFi avec Intune, la première décision architecturale consiste à sélectionner le mécanisme de distribution des certificats. Intune prend en charge SCEP et PKCS, mais leur fonctionnement est fondamentalement différent.

SCEP (Simple Certificate Enrollment Protocol)

SCEP est la norme de l'industrie pour l'enregistrement 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 sous Windows ou la Secure Enclave sur iOS), et n'est jamais transmise sur le réseau. Cela fait de SCEP la méthode fortement recommandée pour l'authentification 802.1X.

PKCS (Public Key Cryptography Standards)

Inversement, avec PKCS, l'Autorité de Certification génère à la fois les clés publique et privée de manière centralisée. Le Microsoft Intune Certificate Connector exporte ensuite de manière sécurisée cette paire de clés et la pousse vers l'appareil cible.

Bien que PKCS élimine le besoin 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'usage 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 d'implémentation : 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 imposent que la confiance soit établie avant que l'authentification puisse être configurée.

Étape 1 : Déployer le profil de certificat racine de confiance

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.

1. Exportez votre certificat de CA racine (et tous les certificats de CA intermédiaires) sous forme de fichiers .cer.
2. Dans le centre d'administration Microsoft Endpoint Manager, accédez à Appareils > Profils de configuration > Créer un profil.
3. Sélectionnez la plateforme cible (par ex., Windows 10 et versions ultérieures) et choisissez le type de profil Certificat de confiance.
4. Téléversez le fichier .cer et déployez ce profil sur vos groupes d'appareils cibles.

Règle d'or : Ciblez toujours les mêmes groupes (soit Utilisateurs, soit Appareils) sur l'ensemble des profils associés afin d'éviter les incohérences 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.

1. Créez un nouveau profil de configuration et sélectionnez Certificat SCEP.
2. 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, utilisez CN={{AAD_Device_ID}}.
3. Définissez l'Utilisation de la clé sur Signature numérique et Chiffrement de la clé.
4. Sous Utilisation étendue de la clé, spécifiez Authentification client (OID : 1.3.6.1.5.5.7.3.2).
5. Liez ce profil au profil de certificat racine de confiance créé à l'Étape 1.
6. Renseignez 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 associe les certificats au SSID du réseau.

1. Créez un profil de configuration Wi-Fi.
2. Saisissez le Nom du réseau (SSID) exactement tel qu'il est diffusé par vos Points d'accès sans fil .
3. Sélectionnez WPA2-Enterprise ou WPA3-Enterprise comme type de sécurité.
4. Définissez le Type d'EAP sur EAP-TLS.
5. Dans les paramètres d'authentification, sélectionnez le profil de certificat SCEP créé à l'étape 2 comme certificat d'authentification client.
6. Spécifiez le certificat racine de confiance pour la validation du serveur afin de garantir que l'appareil se connecte uniquement à votre serveur RADIUS légitime.

Bonnes pratiques et standards de l'industrie

Lors de la mise en œuvre du déploiement de certificats WiFi avec Intune, respectez les bonnes pratiques neutres 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, exposer directement un serveur interne à Internet présente un risque de sécurité majeur.

Recommandation : Publiez l'URL NDES à l'aide du proxy d'application Azure AD. 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'inscription.

RADIUS et vérification de la CRL

Le déploiement de certificats ne représente que la moitié de l'équation de sécurité ; la révocation est tout aussi essentielle. 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 NPS (Network Policy Server) ou votre serveur RADIUS pour imposer une vérification stricte de la CRL. Assurez-vous que vos points de distribution de CRL (CDP) sont hautement disponibles ; si le serveur RADIUS ne peut pas accéder à 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, vous pouvez consulter The Core SD WAN Benefits for Modern Businesses .

Dépannage et atténuation des risques

Même avec une planification minutieuse, 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 racine de confiance et SCEP, mais le profil WiFi s'affiche comme « Erreur » ou « Non applicable » dans Intune.

Cause racine : Cela est presque toujours dû à une mauvaise correspondance dans le ciblage des groupes. Si le profil SCEP est attribué à un groupe d'utilisateurs, mais que le profil WiFi est attribué à un groupe d'appareils, Intune ne peut pas résoudre la dépendance.

Atténuation : Auditez vos attributions. Assurez-vous que les profils de certificat racine de confiance, 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. Mitigation : Vérifiez que le compte du connecteur dispose des autorisations « Lecture » et « Inscrire » sur le modèle de 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 rendements mesurables en matière de sécurité et d'opérations.

1. 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, fautes de frappe). L'authentification par certificat est invisible pour l'utilisateur, ce qui réduit généralement le volume de tickets d'assistance liés au WiFi de 70 à 80 %.
2. Posture de sécurité renforcée : L'EAP-TLS élimine le risque de vol d'identifiants et d'attaques de type Man-in-the-Middle (MitM). Cela est essentiel pour la conformité avec des cadres tels que PCI DSS et le GDPR, en particulier dans les secteurs de la santé et du commerce de détail.
3. 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.