Gestion des certificats numériques pour l'authentification WiFi EAP-TLS

Speak in British English with a confident, authoritative, and conversational tone - like a senior consultant briefing a client. Measured pace, clear diction, warm but direct. Occasional natural pauses for emphasis: Bienvenue dans la série de briefings techniques Purple. Aujourd'hui, nous parlons de la gestion des certificats EAP-TLS - plus précisément, comment gérer un programme d'authentification WiFi basé sur des certificats à grande échelle sans que cela ne devienne une charge opérationnelle à plein temps. [medium pause] Si vous êtes responsable du WiFi d'entreprise ou du personnel sur plusieurs sites - qu'il s'agisse d'un groupe hôtelier, d'un parc de magasins, d'un campus universitaire ou de bâtiments du secteur public - ce briefing est pour vous. Nous allons couvrir l'ensemble du cycle de vie des certificats : de la configuration de votre hiérarchie d'AC, en passant par le déploiement automatisé via SCEP et MDM, jusqu'au renouvellement et à la révocation. Et nous parlerons de ce qui peut mal tourner, parce que cela arrive, et de la façon d'éviter les pièges les plus courants. [medium pause] Commençons par les principes fondamentaux. EAP-TLS - c'est-à-dire Extensible Authentication Protocol avec Transport Layer Security - est la référence absolue pour l'authentification WiFi 802.1X. Contrairement à PEAP, qui repose sur un nom d'utilisateur et un mot de passe, EAP-TLS utilise une authentification mutuelle basée sur des certificats. L'appareil prouve son identité avec un certificat client. Le serveur RADIUS prouve son identité avec un certificat serveur. Les deux parties vérifient l'autre. Pas de mot de passe à hameçonner. Pas d'identifiant à voler. C'est pourquoi la norme PCI-DSS 4.0 et les directives zero-trust du NCSC orientent toutes deux vers une authentification basée sur des certificats pour les réseaux du personnel. [medium pause] Maintenant, l'architecture. Vous avez besoin de trois éléments pour faire fonctionner EAP-TLS. Premièrement, une infrastructure à clés publiques - votre hiérarchie d'AC. Deuxièmement, un mécanisme pour installer les certificats sur les appareils - c'est-à-dire SCEP ou votre plateforme MDM. Troisièmement, un serveur RADIUS qui fait confiance à votre AC et peut valider les certificats clients en temps réel. [medium pause] La hiérarchie d'AC est le domaine où la plupart des organisations rencontrent des difficultés dès le départ. Le modèle correct est un modèle à trois niveaux. Vous avez une AC racine au sommet - celle-ci doit être hors ligne, déconnectée physiquement (air-gapped), et mise en ligne uniquement pour signer le certificat de votre AC intermédiaire. L'AC intermédiaire - parfois appelée AC d'émission - est celle qui signe réellement les certificats au quotidien. Elle est en ligne, mais sa clé privée est bien protégée. En dessous, vous émettez deux types de certificats : les certificats serveurs pour votre infrastructure RADIUS, et les certificats clients pour vos appareils et utilisateurs. [medium pause] Pourquoi est-ce important ? Parce que si votre AC racine est compromise, vous devez reconstruire l'ensemble de votre infrastructure à clés publiques à partir de zéro et réinscrire chaque appareil. La maintenir hors ligne élimine ce risque. L'AC intermédiaire peut être remplacée sans toucher à la racine. C'est l'argument de la résilience opérationnelle en faveur du modèle à trois niveaux. [medium pause] Parlons des périodes de validité des certificats. Il y a eu un changement significatif au sein de l'industrie. Apple, Google et Mozilla ont tous pris des mesures pour imposer des durées de vie maximales plus courtes pour les certificats. Pour les certificats de serveur TLS, le maximum est désormais de 398 jours. Pour les certificats clients dans le cadre du WiFi d'entreprise, vous disposez de plus de flexibilité - un à deux ans est une durée courante - mais la tendance est aux durées de vie plus courtes et au renouvellement automatisé plutôt qu'aux certificats à longue durée de vie gérés manuellement. La raison est simple : une durée de vie plus courte limite la fenêtre d'exposition en cas de compromission d'un certificat. [medium pause] Cela nous amène à l'automatisation. La gestion manuelle des certificats n'est pas évolutive. Si vous avez 500 appareils, vous pouvez tout juste gérer les renouvellements à la main. Si vous avez 5 000 appareils répartis sur 50 sites, c'est impossible. Vous avez besoin de SCEP - le Simple Certificate Enrolment Protocol - ou de son successeur moderne, EST. SCEP s'intègre directement aux plateformes MDM, notamment Microsoft Intune, Jamf Pro et VMware Workspace ONE. Le MDM pousse un profil de configuration SCEP vers l'appareil. L'appareil génère une paire de clés, envoie une demande de signature de certificat à votre serveur SCEP, et reçoit en retour un certificat signé - le tout sans aucune interaction de l'utilisateur. [medium pause] Pour les appareils Windows dans un environnement Active Directory, vous disposez d'une alternative : l'auto-enrôlement piloté par stratégie de groupe (Group Policy) via Active Directory Certificate Services. L'appareil s'authentifie auprès du domaine, l'autorité de certification (CA) délivre automatiquement un certificat, et le certificat est renouvelé avant son expiration sans aucune intervention manuelle. C'est la voie la plus transparente pour les parcs informatiques majoritairement composés de Windows. [medium pause] Maintenant, parlons de la révocation. C'est l'aspect dans lequel les organisations sous-investissent le plus souvent, et c'est pourtant celui qui importe le plus lorsque les choses tournent mal. Si un appareil est perdu, volé, ou qu'un employé s'en va, vous devez révoquer son certificat immédiatement. Il existe deux mécanismes : la CRL - Certificate Revocation Lists - et l'OCSP - Online Certificate Status Protocol. [medium pause] La CRL est le mécanisme le plus ancien. Votre CA publie une liste de numéros de série de certificats révoqués à une URL connue. Le serveur RADIUS télécharge périodiquement cette liste et effectue des vérifications par rapport à celle-ci. Le problème de la CRL est la latence - si votre CRL a une période de validité de 24 heures, un certificat révoqué peut encore s'authentifier jusqu'à 24 heures après sa révocation. [medium pause] L'OCSP est l'alternative en temps réel. Le serveur RADIUS envoie une requête au répondeur OCSP pour chaque tentative d'authentification et obtient une réponse en direct indiquant si le certificat est valide ou révoqué. Le compromis est que votre répondeur OCSP devient une dépendance critique - s'il est indisponible, vous devez décider s'il faut autoriser ou bloquer l'accès. Pour les environnements hautement sécurisés, le blocage est la bonne réponse. Pour les environnements opérationnels où la disponibilité est primordiale, vous pouvez configurer une courte période de grâce OCSP. [medium pause] Laissez-moi vous présenter deux scénarios concrets pour illustrer cela. [medium pause] Premier cas : un groupe hôtelier de 150 établissements. Ils utilisaient PEAP avec un mot de passe partagé pour le WiFi du personnel. La rotation des mots de passe était trimestrielle, ce qui entraînait une période de deux semaines chaque trimestre durant laquelle le personnel était bloqué ou utilisait l'ancien mot de passe. Ils sont passés à EAP-TLS en utilisant Microsoft Intune pour le déploiement des certificats. Des profils SCEP ont été poussés sur tous les appareils Windows et iOS. Active Directory Certificate Services servait d'autorité de certification (CA). Résultat : aucun événement de rotation de mot de passe, renouvellement de certificat géré automatiquement 30 jours avant l'expiration, et lorsqu'un membre du personnel partait, son certificat était révoqué dans le MDM quelques minutes seulement après la désactivation de son compte dans Microsoft Entra ID. L'équipe informatique a estimé avoir économisé environ 40 heures par trimestre en réinitialisations de mots de passe et tickets d'assistance. [medium pause] Second cas : une chaîne de vente au détail multi-sites comptant 3 000 appareils pour le personnel répartis dans 200 magasins. Le défi résidait dans la diversité des appareils - un mélange d'ordinateurs portables Windows, de terminaux mobiles Android et d'appareils iOS. Ils ont utilisé Jamf Pro pour les appareils Apple et Microsoft Intune pour Windows et Android, tous deux pointant vers le même serveur SCEP adossé à une CA intermédiaire Microsoft ADCS. L'infrastructure WiFi était basée sur Cisco Meraki, avec une authentification RADIUS gérée par un service RADIUS hébergé dans le cloud et intégré à Purple. La décision de conception clé a été de délivrer des certificats d'une validité de 12 mois et de configurer le renouvellement automatique à 60 jours avant l'expiration. Cela a permis de bénéficier d'une fenêtre de renouvellement confortable sans générer de surcharge opérationnelle. [medium pause] Voyons maintenant les pièges. J'en observe régulièrement quatre. [medium pause] Premier piège : ne pas tester la révocation. Les entreprises configurent leur PKI, déploient des certificats et ne testent jamais si la révocation fonctionne de bout en bout. Testez-la. Révoquez un certificat de test, confirmez que le serveur RADIUS détecte la révocation dans le délai prévu et vérifiez que l'accès de l'appareil est bien refusé. [medium pause] Deuxième piège : l'effet falaise des expirations. Si vous délivrez tous vos certificats en même temps avec la même période de validité, ils expireront tous en même temps. Échelonnez votre délivrance ou, au minimum, échelonnez vos déclencheurs de renouvellement. Un taux d'échec de renouvellement de 10 % sur 5 000 appareils simultanés constitue un incident majeur. [medium pause] Troisième piège : ne pas distribuer le certificat de la CA racine à tous les appareils avant de déployer EAP-TLS. Si l'appareil ne fait pas confiance à votre CA racine, il rejettera le certificat du serveur RADIUS et l'authentification échouera. Cela semble évident, mais cela surprend les entreprises lorsqu'elles ont des appareils BYOD ou des ordinateurs portables de prestataires qui ne sont pas enregistrés dans le MDM. [medium pause] Quatrième piège : la disponibilité du répondeur OCSP. Si votre répondeur OCSP tombe en panne et que votre serveur RADIUS est configuré pour bloquer l'accès en cas d'erreur OCSP, l'ensemble de votre réseau WiFi cesse de fonctionner. Intégrez de la redondance dans votre infrastructure OCSP ou configurez une courte période de grâce avec une surveillance appropriée. [medium pause] Passons maintenant aux questions rapides. [medium pause] Puis-je utiliser une autorité de certification (CA) publique pour les certificats clients EAP-TLS ? Techniquement oui, mais en pratique non. Les CA publiques ne délivreront pas de certificats clients pour des appareils arbitraires. Vous avez besoin de votre propre CA pour les certificats clients. Pour le certificat du serveur RADIUS, une CA publique convient parfaitement et simplifie la distribution de la confiance. [medium pause] Qu'en est-il du BYOD ? Le BYOD est le cas le plus complexe. Vous ne pouvez pas déployer de certificats sur des appareils non gérés via un MDM. Les options incluent un portail de contrôle d'accès réseau qui délivre des certificats à courte durée de vie après l'authentification de l'utilisateur, ou simplement le maintien du BYOD sur un SSID distinct avec une méthode d'authentification différente. [medium pause] Comment cela interagit-il avec le WPA3 ? Le WPA3-Enterprise impose un mode de sécurité 192 bits pour les environnements sensibles, ce qui nécessite des suites de chiffrement spécifiques. EAP-TLS est entièrement compatible avec le WPA3-Enterprise et constitue en fait la méthode d'authentification recommandée. [medium pause] En résumé. La gestion des certificats EAP-TLS n'est pas simple, mais elle est gérable si vous adoptez la bonne architecture dès le départ. Une hiérarchie de CA à trois niveaux. Un enrôlement automatisé via SCEP ou MDM. Des durées de vie de certificat courtes avec renouvellement automatique. Une révocation en temps réel via OCSP. Testez tout, en particulier la révocation. Et intégrez le cycle de vie de vos certificats à votre fournisseur d'identité - Microsoft Entra ID, Okta ou Google Workspace - afin que la révocation des certificats soit déclenchée automatiquement lorsqu'un compte est déprovisionné. [medium pause] Si vous utilisez des serveurs RADIUS liés à Purple, les points d'intégration sont l'URL de votre serveur SCEP, le certificat de votre serveur RADIUS et votre point de terminaison CRL ou OCSP. L'architecture de Purple, indépendante du matériel, permet de faire fonctionner l'ensemble sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist et le reste de la liste de matériel standard - vous n'êtes pas bloqué dans les outils PKI d'un seul fournisseur. [medium pause] Prochaines étapes : auditez votre inventaire de certificats actuel. Si vous ne savez pas combien de certificats vous possédez, quand ils expirent et qui les a délivrés, c'est la première chose à corriger. À partir de là, la voie vers une automatisation complète est bien définie. Merci pour votre écoute.