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

S'exprimer en français avec un ton confiant, faisant autorité et conversationnel - comme un consultant senior briefant un client. Un rythme mesuré, une diction claire, chaleureux mais direct. Des pauses naturelles occasionnelles pour mettre l'accent : Bienvenue dans la série de briefings techniques de Purple. Aujourd'hui, nous allons parler de la gestion des certificats EAP-TLS - plus précisément, de la manière de 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 réseau de points de vente, d'un campus universitaire ou d'un parc immobilier du secteur public - ce briefing est pour vous. Nous allons aborder l'ensemble du cycle de vie des certificats : de la configuration de votre hiérarchie d'AC au renouvellement et à la révocation, en passant par le déploiement automatisé via SCEP et MDM. Et nous verrons là où les choses tournent mal, car cela arrive, et comment éviter les pièges les plus courants. [medium pause] Commençons par les fondamentaux. L'EAP-TLS - à savoir Extensible Authentication Protocol avec Transport Layer Security - est la référence absolue pour l'authentification WiFi 802.1X. Contrairement au PEAP, qui repose sur un nom d'utilisateur et un mot de passe, l'EAP-TLS utilise une authentification mutuelle basée sur des certificats. L'appareil prouve son identité à l'aide d'un certificat client. Le serveur RADIUS prouve son identité avec un certificat serveur. Les deux parties se vérifient mutuellement. Aucun mot de passe à hameçonner. Aucun identifiant à voler. C'est pourquoi la norme PCI DSS 4.0 et les directives de confiance zéro du NCSC orientent toutes deux vers une authentification basée sur des certificats pour les réseaux du personnel. [medium pause] À présent, l'architecture. Vous avez besoin de trois éléments pour faire fonctionner l'EAP-TLS. Tout d'abord, une infrastructure à clés publiques (PKI) - votre hiérarchie d'AC. Deuxièmement, un mécanisme pour installer les certificats sur les appareils - c'est-à-dire le 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 rapidement des difficultés. Le modèle correct est un modèle à trois niveaux. Vous avez une AC racine au sommet - celle-ci doit être hors ligne, isolé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 émettrice - 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 : des certificats serveurs pour votre infrastructure RADIUS, et des 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'intégralité de votre PKI à partir de zéro et réenregistrer 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 important dans le secteur à ce sujet. 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 WiFi d'entreprise, vous disposez de plus de flexibilité (un à deux ans est courant), mais la tendance est aux durées de vie plus courtes et au renouvellement automatisé, plutôt qu'à des 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 du protocole SCEP (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-inscription pilotée 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 fluide pour les parcs informatiques principalement sous Windows. [medium pause] Voyons maintenant la révocation. C'est le domaine dans lequel les organisations sous-investissent le plus souvent, et c'est pourtant celui qui importe le plus en cas de problème. 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 toujours 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 si vous autorisez l'accès par défaut (fail open) ou si vous le bloquez (fail closed). Pour les environnements de haute sécurité, le blocage par défaut (fail closed) est la bonne solution. Pour les environnements opérationnels où la disponibilité est essentielle, 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 signifiait une fenêtre de deux semaines chaque trimestre durant laquelle le personnel était bloqué ou utilisait l'ancien mot de passe. Ils ont migré vers 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, un 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 avec 3 000 appareils du personnel répartis sur 200 magasins. Le défi résidait dans la diversité des appareils : un mélange d'ordinateurs portables Windows, de terminaux portables 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 du 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 créer de surcharge opérationnelle. [medium pause] Voyons maintenant les pièges. Il y en a quatre que je constate régulièrement. [medium pause] Premier piège : ne pas tester la révocation. Les organisations 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 confirmez que l'accès est refusé à l'appareil. [medium pause] Deuxième piège : l'effet de 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 vos émissions ou, au minimum, échelonnez vos déclencheurs de renouvellement. Un taux d'échec de renouvellement de 10 % sur 5 000 appareils simultanément 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 organisations 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 (fail closed), l'ensemble de votre parc 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] Bien, passons aux questions rapides. [medium pause] Puis-je utiliser une 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 difficile. 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. L'EAP-TLS est entièrement compatible avec le WPA3-Enterprise et constitue en fait la méthode d'authentification recommandée. [medium pause] Pour résumer. La gestion des certificats EAP-TLS n'est pas simple, mais elle est gérable si vous définissez correctement l'architecture dès le départ. Hiérarchie de CA à trois niveaux. Enrôlement automatisé via SCEP ou MDM. Durée de vie des certificats courte avec renouvellement automatisé. 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, votre certificat de serveur RADIUS et votre point de terminaison CRL ou OCSP. L'architecture indépendante du matériel de Purple signifie que cela fonctionne avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist et le reste de la liste de matériel canonique - vous n'êtes pas enfermé 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. De là, la voie vers une automatisation complète est bien définie. Merci pour votre écoute.