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

Parlez en anglais britannique avec un ton confiant, autoritaire et conversationnel - comme un consultant senior briefant un client. Un rythme mesuré, une diction claire, chaleureuse mais directe. Des pauses naturelles occasionnelles pour mettre l'accent : Bienvenue dans la série de briefings techniques Purple. Aujourd'hui, nous allons parler de la gestion des certificats EAP-TLS - plus précisément, de la manière de mener à bien un programme d'authentification WiFi basé sur des certificats à grande échelle sans que cela ne devienne une charge opérationnelle à plein temps. [pause moyenne] 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 commerces de détail, d'un campus universitaire ou d'un patrimoine 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 au déploiement automatisé via SCEP et MDM, en passant par le renouvellement et la révocation. Et nous parlerons des points de friction, car les choses tournent parfois mal, et de la façon d'éviter les pièges les plus courants. [pause moyenne] Commençons par les fondamentaux. EAP-TLS - c'est-à-dire l'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é à l'aide d'un certificat client. Le serveur RADIUS prouve son identité à l'aide d'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 de sécurité zero-trust préconisent toutes deux l'authentification basée sur des certificats pour les réseaux du personnel. [pause moyenne] 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. [pause moyenne] La hiérarchie d'AC est l'endroit 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, isolée physiquement du réseau, 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 de serveur pour votre infrastructure RADIUS, et des certificats clients pour vos appareils et utilisateurs. [pause moyenne] 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. [pause moyenne] Parlons des périodes de validité des certificats. Il y a eu un changement majeur 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 domaine du WiFi d'entreprise, vous disposez de plus de flexibilité - un à deux ans est une pratique 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 si un certificat est compromis. [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 intervention 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 via Active Directory Certificate Services. L'appareil s'authentifie auprès du domaine, l'autorité de certification délivre un certificat automatiquement, et le certificat est renouvelé avant son expiration sans aucune intervention manuelle. C'est la voie la plus fluide pour les parcs majoritairement sous Windows. [medium pause] Maintenant, la révocation. C'est l'élément dans lequel les organisations sous-investissent le plus souvent, et c'est 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 : CRL - les listes de révocation de certificats - et OCSP - Online Certificate Status Protocol. [medium pause] La CRL est le mécanisme le plus ancien. Votre autorité de certification 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] OCSP est l'alternative en temps réel. Le serveur RADIUS envoie une requête au répondeur OCSP à 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 l'accès par défaut ou bloquer l'accès par défaut. Pour les environnements de haute sécurité, bloquer l'accès par défaut 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] Permettez-moi de 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é déployés sur tous les appareils Windows et iOS. Active Directory Certificate Services servait d'autorité de certification. Résultat : aucune opération de rotation de mots de passe, renouvellement des certificats 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 en tickets d'assistance. [medium pause] Deuxième cas : une chaîne de vente au détail multi-sites comptant 3 000 appareils professionnels répartis sur 200 magasins. Le défi résidait ici dans la diversité des équipements - un mélange d'ordinateurs portables Windows, de terminaux portables Android et d'appareils iOS. Ils utilisaient Jamf Pro pour les appareils Apple et Microsoft Intune pour Windows et Android, tous deux pointant vers le même serveur SCEP adossé à une autorité de certification 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 un renouvellement automatique à 60 jours avant l'expiration. Cela offrait une marge de renouvellement confortable sans générer de surcharge opérationnelle. [medium pause] Passons maintenant aux pièges. J'en observe régulièrement quatre. [medium pause] Premier piège : ne pas tester la révocation. Les organisations configurent leur PKI, déploient des certificats, mais 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 prend en compte la révocation dans le délai prévu et vérifiez que l'accès est bien 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 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 l'autorité de certification racine (Root CA) à tous les appareils avant de déployer EAP-TLS. Si l'appareil ne fait pas confiance à votre Root CA, 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, l'ensemble de votre réseau WiFi cesse de fonctionner. Intégrez de la redondance dans votre infrastructure OCSP, ou configurez un court délai de grâce avec une surveillance appropriée. [medium pause] Très 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 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 enregistrement automatisé via SCEP ou MDM. Des durées de vie de certificat courtes avec renouvellement automatisé. 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 avec votre fournisseur d'identité - Microsoft Entra ID, Okta ou Google Workspace - afin que la révocation du certificat soit déclenchée automatiquement lorsqu'un compte est supprimé. [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 matérielle agnostique de Purple signifie que cela fonctionne sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist et le reste de la liste de matériel prise en charge - 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.