Comment configurer le WiFi d'entreprise sur les appareils Android avec EAP-TLS

Comment configurer le WiFi d'entreprise sur les appareils Android avec EAP-TLS Un briefing technique Purple — Environ 10 minutes --- INTRODUCTION ET CONTEXTE — environ 1 minute Bienvenue dans la série des briefings techniques Purple. Je suis votre hôte, et aujourd'hui nous entrons dans les détails du déploiement de l'authentification 802.1X EAP-TLS sur les appareils Android — que vous gériez un parc hôtelier, une chaîne de magasins, un stade ou un campus du secteur public. Si vous êtes responsable d'un réseau qui doit authentifier des appareils Android d'entreprise ou BYOD sans dépendre de mots de passe partagés, cet épisode est pour vous. EAP-TLS est la référence absolue en matière de sécurité WiFi d'entreprise — il utilise une authentification mutuelle basée sur des certificats, ce qui signifie qu'il n'y a pas d'identifiants à pirater par phishing, pas de mots de passe à renouveler et une posture de conformité qui satisfait aux exigences PCI DSS, ISO 27001 et à la plupart des cadres de sécurité du secteur public. À la fin de ce briefing, vous comprendrez exactement comment fonctionne EAP-TLS sur Android, quelles sont vos options de déploiement et les trois erreurs les plus courantes qui provoquent l'échec des déploiements. C'est parti. --- ANALYSE TECHNIQUE APPROFONDIE — environ 5 minutes Commençons par l'architecture. Le 802.1X est la norme IEEE qui régit le contrôle d'accès réseau basé sur les ports. Lorsqu'un appareil Android se connecte à un réseau WiFi d'entreprise — configuré en WPA2-Enterprise ou WPA3-Enterprise —, le point d'accès agit comme ce que l'on appelle un authentificateur. Il ne prend pas la décision d'authentification lui-même ; il transmet la conversation entre l'appareil et un serveur RADIUS, qui est le véritable serveur d'authentification. EAP-TLS — c'est-à-dire Extensible Authentication Protocol avec Transport Layer Security — est la méthode d'authentification exécutée au sein de ce framework 802.1X. Ce qui la différencie d'EAP-PEAP ou d'EAP-TTLS, qui utilisent un nom d'utilisateur et un mot de passe à l'intérieur d'un tunnel TLS, c'est qu'EAP-TLS utilise des certificats X.509 des deux côtés. Le serveur RADIUS présente un certificat de serveur à l'appareil, et l'appareil présente en retour un certificat de client au serveur RADIUS. Les deux parties se valident mutuellement. C'est l'authentification mutuelle, et c'est ce qui fait d'EAP-TLS l'option la plus sécurisée disponible. Maintenant, sur Android spécifiquement, il y a quelques éléments que vous devez comprendre. Android 11 et les versions ultérieures ont introduit des exigences de validation de certificat plus strictes. Si vous déployez sur Android 11 ou supérieur — ce qui représente aujourd'hui la grande majorité de votre parc —, l'appareil refusera de se connecter à moins que le certificat du serveur RADIUS ne soit explicitement approuvé. Vous ne pouvez pas vous fier uniquement au magasin de confiance du système ; vous devez soit pousser le certificat de l'autorité de certification (CA) racine vers l'appareil, soit configurer le profil WiFi pour y faire explicitement référence.Parlons de la chaîne de certification. Vous devez mettre en place trois composants avant qu'un seul appareil Android puisse s'authentifier via EAP-TLS. Premièrement, une autorité de certification (CA) — soit votre PKI interne, soit Microsoft Active Directory Certificate Services, soit une PKI cloud comme SCEP via Intune. Deuxièmement, un certificat de serveur délivré à votre serveur RADIUS, signé par cette CA. Troisièmement, un certificat client unique délivré à chaque appareil ou utilisateur, également signé par la même CA. L'appareil présente son certificat client lors de la liaison TLS, et le serveur RADIUS le valide par rapport à la liste de révocation de certificats (CRL) de la CA, ou via OCSP (Online Certificate Status Protocol). Pour Android, le certificat client et la clé privée sont généralement regroupés dans un fichier PKCS12 — c'est-à-dire un fichier .P12 ou .PFX — qui contient à la fois le certificat et la clé privée chiffrée. Sur un appareil configuré manuellement, l'utilisateur importe ce fichier via Paramètres, puis Sécurité, puis Installer un certificat. Sur un appareil géré par un MDM, le certificat est poussé silencieusement vers le keystore géré de l'appareil — aucune interaction de l'utilisateur n'est requise. Parlons maintenant du profil WiFi lui-même. Lors de la configuration d'une connexion WiFi d'entreprise sur Android, vous devez spécifier : l'SSID, le type de sécurité — WPA2-Enterprise ou WPA3-Enterprise — la méthode EAP — qui est TLS — le certificat de la CA pour la validation du serveur, le certificat client pour l'authentification de l'appareil, et la chaîne d'identité, qui est généralement le Common Name de l'appareil ou l'UPN de l'utilisateur. Sur Android 11 et versions supérieures, vous devez également spécifier la correspondance du suffixe de domaine ou le sujet du certificat du serveur pour empêcher les attaques de type man-in-the-middle. Pour les déploiements MDM — et c'est là que réside le véritable gain d'échelle — vous poussez tout cela sous forme de profil de configuration structuré. Dans Microsoft Intune, vous créez un profil de certificat SCEP qui demande et installe automatiquement un certificat client unique sur chaque appareil Android enregistré. Vous créez ensuite un profil de configuration WiFi qui fait référence à ce profil de certificat. Lorsque l'appareil se connecte, il reçoit à la fois le certificat et le profil WiFi, et se connecte automatiquement à votre réseau 802.1X. Aucune interaction de l'utilisateur, aucun appel au support. Si vous utilisez Intune pour cela, notre guide d'accompagnement sur la façon d'utiliser Microsoft Intune pour pousser des certificats WiFi vers les appareils détaille les étapes de configuration exactes — je vous recommande de le lire en parallèle de ce briefing. Pour VMware Workspace ONE et Jamf Connect, le processus est identique sur le plan architectural — profil de certificat SCEP ou PKCS, suivi d'un profil WiFi qui y fait référence. L'interface utilisateur spécifique diffère, mais la chaîne de certification et les exigences de configuration RADIUS restent les mêmes. Un point important à signaler concernant RADIUS : si vous utilisez FreeRADIUS, Microsoft NPS ou Cisco ISE, assurez-vous que le certificat de votre serveur inclut les attributs d'utilisation étendue de la clé (EKU) corrects — plus précisément, l'authentification du serveur (Server Authentication), OID 1.3.6.1.5.5.7.3.1. Android est très strict à ce sujet. Un certificat qui fonctionne parfaitement avec des clients Windows peut échouer sur Android si l'EKU est manquant ou mal configuré. --- RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER — environ 2 minutes Abordons maintenant les problèmes concrets rencontrés sur le terrain, car c'est là que la plupart des déploiements rencontrent des difficultés. Le premier échec, et le plus courant, concerne la confiance accordée aux certificats. Android 11 et les versions supérieures ne se connecteront pas si la chaîne de certificats du serveur RADIUS ne peut pas être validée. La solution est simple : déployez le certificat de votre autorité de certification (CA) racine dans le magasin de certificats utilisateur de l'appareil via un MDM, et référencez-le explicitement dans le champ du certificat CA du profil WiFi. Ne laissez pas ce champ sur "Ne pas valider" — c'est une faille de sécurité et cela échouera de toute façon sur certaines versions d'Android. Le deuxième piège est l'expiration des certificats. Les certificats clients ont généralement une durée de validité de un à deux ans. Si vous ne disposez pas d'un renouvellement automatisé via SCEP ou NDES, vous risquez de vous réveiller un matin et de constater que la moitié de votre parc d'appareils a perdu son accès WiFi simultanément. Intégrez l'automatisation du renouvellement des certificats dans votre flux de travail MDM dès le premier jour, et non après coup. Le troisième problème concerne la capacité du serveur RADIUS. Les liaisons EAP-TLS sont plus gourmandes en ressources de calcul que les liaisons PEAP en raison de l'échange mutuel complet de certificats. Dans un stade ou un centre de conférence accueillant des milliers d'authentifications simultanées, un serveur RADIUS sous-dimensionné deviendra un goulot d'étranglement. Dimensionnez votre infrastructure RADIUS pour les pics d'authentification simultanés, et non pour la charge moyenne. Enfin, du côté d'Android, sachez que les différents fabricants — Samsung, Google, Xiaomi — ont des implémentations légèrement différentes de l'API de configuration WiFi. Testez vos profils déployés par MDM sur des appareils représentatifs de chaque fabricant de votre parc avant de procéder à un déploiement à grande échelle. Les appareils Samsung, en particulier, ont historiquement nécessité que le champ d'identité soit explicitement défini, même lorsqu'il peut être déduit du certificat. --- QUESTIONS-RÉPONSES RAPIDES — environ 1 minute Voici quelques questions rapides que l'on me pose régulièrement. Puis-je utiliser EAP-TLS pour les appareils BYOD ? Oui, mais cela nécessite que l'utilisateur installe un certificat client sur son appareil personnel. Pour le BYOD à grande échelle, déterminez si EAP-TTLS avec PAP ou PEAP-MSCHAPv2 constitue un compromis plus pratique, en réservant EAP-TLS aux appareils appartenant à l'entreprise. Est-ce que EAP-TLS fonctionne avec WPA3-Enterprise ? Oui, et le WPA3-Enterprise en mode 192 bits impose d'ailleurs l'utilisation d'EAP-TLS. Si vous déployez le WPA3-Enterprise dans des environnements hautement sécurisés, EAP-TLS est votre seule option conforme. Quelle est la version minimale d'Android que je devrais cibler ? Android 8 et versions ultérieures prennent en charge EAP-TLS de manière native. Pour Android 11 et versions ultérieures, imposez une validation explicite du certificat CA. Pour Android 13 et versions ultérieures, vous pouvez exploiter les API de gestion des certificats améliorées pour un contrôle plus granulaire. La plateforme de Purple peut-elle s'intégrer aux réseaux EAP-TLS ? La plateforme de WiFi invité et d'analyse de Purple fonctionne sur un SSID distinct de votre réseau d'entreprise 802.1X. Vos appareils d'entreprise s'authentifient via EAP-TLS sur le SSID sécurisé, tandis que les appareils invités utilisent le Captive Portal de Purple sur le SSID invité. Les deux coexistent sur la même infrastructure de points d'accès, la séparation VLAN assurant la frontière de sécurité. --- RÉSUMÉ ET PROCHAINES ÉTAPES — environ 1 minute Pour résumer : EAP-TLS sur Android est la méthode d'authentification WiFi d'entreprise la plus sécurisée disponible, et avec les outils MDM modernes, son déploiement à grande échelle est tout à fait réalisable. Les trois éléments à maîtriser sont : une PKI correctement configurée avec renouvellement automatique des certificats, une confiance explicite dans le certificat CA sur Android 11 et versions ultérieures, et une infrastructure RADIUS dimensionnée pour la charge de pointe. Si vous effectuez un déploiement dans un lieu accueillant un trafic mixte d'entreprise et d'invités, la plateforme de Purple vous offre la couche d'analyse et d'engagement sur le réseau invité, tandis que votre infrastructure EAP-TLS sécurise le côté entreprise. Les deux se complètent parfaitement. Pour vos prochaines étapes : consultez notre schéma d'architecture dans le guide complet, suivez le guide de déploiement Intune et menez un projet pilote sur un sous-ensemble d'appareils avant de le déployer sur l'ensemble de votre parc. Commencez par un groupe contrôlé de cinquante appareils, validez la distribution des certificats et la connectivité WiFi, puis passez à l'échelle en toute confiance. Merci d'avoir écouté le briefing technique de Purple. Vous trouverez le guide écrit complet, les schémas et les références de configuration sur purple.ai. À la prochaine.