Un ordinateur portable d'entreprise est volé dans le train. Le centre d'assistance désactive le compte Active Directory de l'employé, l'appareil disparaît du registre des actifs et tout le monde suppose que le risque a été écarté. Deux jours plus tard, l'ordinateur portable apparaît toujours sur le SSID de l'entreprise car son suppliant 802.1X détient un certificat client qui n'a pas expiré et que personne n'a révoqué.
C'est précisément l'écart qu'un processus de liste de révocation de certificats est conçu de combler. L'expiration du certificat fixe la limite externe de la confiance, tandis que la révocation coupe cette confiance plus tôt lorsqu'une clé est compromise, qu'un appareil est perdu ou qu'un utilisateur s'en va. Pour un administrateur réseau d'entreprise, la question importante n'est pas de savoir si les certificats existent. C'est de savoir si le RADIUS et les contrôles réseau associés prennent connaissance rapidement d'un certificat révoqué et s'ils basculent en mode de sécurité positive (fail-safe).
L'accès WiFi qui ne voulait pas disparaître
Un déploiement de WiFi basé sur des certificats semble souvent sécurisé de l'extérieur. Le client utilise EAP-TLS, le service RADIUS valide la chaîne de certificats et les mots de passe partagés ne circulent pas entre les collaborateurs. Mais cette conception dépend toujours d'un cycle de vie fonctionnel. L'émission d'un certificat n'est que le début. Vous devez également savoir à qui il appartient, quand il expire et ce qui se passe si l'appareil ou la clé privée ne sont plus fiables.
Dans l'exemple de l'ordinateur portable volé, la suppression du compte dans Active Directory peut bloquer la future authentification d'annuaire, mais elle n'invalide pas nécessairement un certificat déjà installé sur l'appareil. Si le service WiFi fait confiance au certificat uniquement sur la base de sa chaîne et de ses dates de validité, l'ordinateur portable peut continuer à présenter des identifiants apparemment valides. La date notAfter du certificat indique qu'il reste dans sa durée de vie prévue. Elle n'indique pas que l'organisation émettrice souhaite toujours lui faire confiance.
Règle pratique : Traitez l'expiration du certificat et la révocation du certificat comme des contrôles distincts. L'expiration relève de la gestion planifiée du cycle de vie. La révocation est le frein d'urgence.
Le modèle de PKI du secteur public britannique rend cette distinction explicite. Une liste de révocation de certificats, ou CRL, est une liste signée de numéros de série de certificats révoqués avant leur expiration, qui indique aux parties de confiance que ces certificats ne doivent plus être considérés comme fiables. Les directives de l'infrastructure à clés publiques du Royaume-Uni identifient également les CRL comme l'une des méthodes de révocation courantes et attendent des clients qu'ils vérifient si un certificat présenté figure sur la liste de l'autorité de certification émettrice.
Cela est important pour le WiFi car les décisions d'authentification se prennent à la périphérie du réseau, souvent à travers de nombreux contrôleurs, points d'accès, serveurs RADIUS et magasins de validation mis en cache. Une mise à jour manuelle de la CRL peut laisser une faille de sécurité, tandis qu'une politique d'échec bloquant mal conçue peut provoquer une panne si le point de distribution de la CRL devient indisponible.
Le modèle mental de fonctionnement est simple : l'AC émet et signe les informations d'état, la partie utilisatrice les vérifie, et le réseau refuse un certificat qui a été révoqué. Le reste de ce guide examine comment ce processus fonctionne, en quoi la CRL et l'OCSP diffèrent, et comment les contrôles d'accès basés sur l'annuaire peuvent éliminer une grande partie du goulot d'étranglement de la révocation manuelle.
Ce qu'est réellement un certificat de liste de révocation
En termes simples, une liste de révocation de certificats est un avis officiel d'une autorité de certification indiquant de "ne plus faire confiance à ces certificats". Elle identifie les certificats par leur numéro de série, et non par un nom d'appareil convivial ou l'adresse e-mail d'un employé. Un client qui trouve le numéro de série du certificat présenté sur la liste concernée doit le rejeter, même si la date d'expiration du certificat est encore à venir.
La définition britannique est formelle. Elle décrit une CRL comme une liste signée de numéros de série de certificats révoqués avant leur expiration, de sorte que les parties de confiance ne doivent plus faire confiance à ces certificats. La signature est importante car un serveur RADIUS ou un autre validateur doit confirmer que la liste provient de l'émetteur attendu et n'a pas été modifiée en cours de route. Une liste de blocage en texte brut gérée par un administrateur ne fournit pas cette assurance cryptographique.
Trois parties rendent le processus utile :
- L'autorité de certification : La CA, ou un émetteur de CRL autorisé, crée la liste et la signe à l'aide d'une clé privée associée à la hiérarchie de confiance émettrice.
- La partie de confiance : Un serveur RADIUS, un suppliant, un contrôleur, un système d'exploitation ou un outil d'administration télécharge la liste, valide sa signature et ses informations de validité, puis recherche le numéro de série du certificat.
- Le titulaire du certificat : La personne, l'appareil ou le service dont le certificat a été révoqué. Son numéro de série reste sur la liste afin que les validateurs puissent l'identifier comme non fiable.
Une CRL n'est pas normalement un certificat au même titre qu'un certificat d'utilisateur ou d'appareil. Il s'agit d'un artefact PKI signé qui contient des informations sur l'émetteur, la validité et la publication. On utilise parfois le terme de "certificat de liste de révocation" comme raccourci pour désigner le mécanisme de révocation de certificat, mais l'objet opérationnel vérifié est bien la CRL signée.
La partie de confiance ne demande généralement pas à l'AC d'expliquer pourquoi un utilisateur doit être refusé. Elle suit les informations de révocation du certificat, récupère la CRL actuelle de l'émetteur, vérifie la CRL et contrôle le numéro de série. S'il y a une correspondance, le certificat est révoqué. Dans le cas contraire, le résultat reste limité par la fraîcheur de la CRL et le propre cache de la partie de confiance.
Ce dernier point est à l'origine de nombreux incidents. Un certificat peut être absent d'une ancienne liste mise en cache et présent sur une plus récente. La décision du réseau dépend donc à la fois de ce que l'AC a publié et de la date à laquelle l'authentificateur l'a récupéré pour la dernière fois.
Comment fonctionne une CRL en coulisses
Le cycle de vie d'une CRL suit une chaîne d'événements prévisible. Tout d'abord, l'autorité de certification génère une liste de base conformément à sa politique de certification. Elle signe la liste, ajoute des champs de publication et de validité, et la rend disponible via un point de distribution. Les certificats émis font généralement référence à ces emplacements via l'extension CRL Distribution Points, ce qui permet à un validateur de découvrir où se trouvent les informations de statut.
Lorsqu'un administrateur révoque un certificat d'appareil, l'AC enregistre son numéro de série et le motif de la révocation. Le certificat n'apparaîtra pas nécessairement tout de suite dans le cache de chaque partie de confiance. La prochaine CRL publiée doit contenir l'entrée, et chaque serveur RADIUS ou contrôleur doit en récupérer une copie à jour avant de pouvoir prendre la bonne décision.
Certains environnements PKI utilisent également des CRL delta. Une delta contient les modifications depuis une CRL de base, ce qui permet de réduire le transfert et le traitement lorsque la liste complète est volumineuse. Cette efficacité n'élimine pas la nécessité de gérer la liste de base, de valider les signatures, de suivre la fraîcheur ou de s'assurer que chaque composant réseau comprend le modèle de publication choisi.
La fenêtre de fraîcheur
Les politiques du Royaume-Uni fournissent des points de référence utiles pour réfléchir à la propagation. La déclaration de pratique CVCA du gouvernement britannique exige que les CRL soient émises au maximum tous les 90 jours, et exige qu'un certificat révoqué apparaisse dans la CRL concernée dans les 72 heures suivant la révocation. Ces limites sont décrites dans la politique nationale de certification du Royaume-Uni.
D'autres politiques britanniques utilisent des attentes de service différentes. Le HM Land Registry stipule que sa liste de révocation pour les certificats révoqués et suspendus doit être mise à jour au moins une fois par jour, tandis que la déclaration des pratiques de certification de l'Université de York indique une latence maximale de 10 jours entre la révocation et l'émission de la CRL. Ces exemples, y compris le point de publication de l'autorité de certification de signature de pays de l'HMPO, montrent pourquoi un administrateur doit lire la politique réelle de la CA émettrice plutôt que de supposer que chaque CRL se comporte de manière identique.
Au moment de l'authentification, le serveur RADIUS vérifie le numéro de série du certificat par rapport à sa CRL disponible localement. Il vérifie également si la CRL se trouve dans sa période de validité, si la signature remonte à l'émetteur attendu et si le point de distribution peut être atteint lorsqu'un rafraîchissement est dû. Le serveur met ensuite le résultat en cache conformément à son implémentation et à la valeur nextUpdate de la CRL.
Cela produit une équation de risque pratique sans avoir besoin de mathématiques complexes : la latence de révocation comprend le temps de publication de l'AC, le délai de distribution, la durée du cache et la fréquence d'authentification. Une politique peut publier rapidement, mais un cache RADIUS déconnecté ou obsolète peut tout de même retarder l'application.
CRL vs OCSP et pourquoi cela compte pour le WiFi
La CRL et OCSP résolvent le même problème de base de manières différentes. Une CRL fournit au validateur un lot signé de numéros de série révoqués. OCSP interroge un répondeur autorisé sur le statut d'un certificat unique au moment précis de sa vérification.
Pour un administrateur WiFi d'entreprise, ce choix affecte bien plus que l'élégance de la PKI. Il modifie le comportement d'un contrôleur sur un WAN encombré, ce que l'infrastructure de CA doit gérer et si une tentative d'authentification peut aboutir lorsqu'un répondeur ou un point de distribution est injoignable.
| Critère | CRL | OCSP |
|---|---|---|
| Fraîcheur | Périodique. Un certificat nouvellement révoqué attend sa publication et le rafraîchissement du client. | La requête par certificat peut fournir un statut plus récent lorsque le répondeur est accessible. |
| Charge d'infrastructure | Les clients téléchargent et traitent une liste, ce qui peut être efficace pour des vérifications répétées sur un parc géré, mais peut générer du trafic de distribution. | Le répondeur gère les demandes de statut individuelles, ce qui évite le téléchargement d'une liste complète mais augmente le volume des requêtes. |
| Confidentialité | La partie de confiance obtient une liste et n'a pas besoin de révéler chaque vérification de certificat à la CA. | Une requête directe peut révéler au répondeur quel certificat est en cours de vérification. |
| Mode de défaillance | Une CRL inaccessible ou expirée peut empêcher une validation de statut fiable. Les caches locaux peuvent continuer à fonctionner jusqu'à leur limite de fraîcheur. | Un répondeur inaccessible affecte la requête de statut individuelle, et le comportement configuré (soft-fail ou hard-fail) détermine le résultat pour le WiFi. |
Un contrôleur desservant un grand campus préférera sans doute une CRL mise en cache localement, car il peut ainsi vérifier de nombreux numéros de série de certificats sans envoyer de requête distincte pour chaque authentification. Ce modèle fonctionne bien lorsque les points de distribution sont accessibles, que les mises à jour sont surveillées et que la politique RADIUS gère délibérément une liste expirée.
L'OCSP peut convenir à une architecture où l'opérateur a besoin d'une réponse par certificat et accepte la dépendance vis-à-vis d'un répondeur. Il peut réduire la nécessité de transférer une liste complète, mais il introduit une dépendance réseau en direct pendant l'authentification. L'agrafage (stapling) peut déplacer l'interaction avec le répondeur ailleurs dans certains protocoles, mais la conception du réseau WiFi doit toujours apporter une réponse claire en cas de données de statut indisponibles ou obsolètes.
Les directives du Royaume-Uni sont utiles ici car elles ne présentent pas la CRL comme l'unique méthode. La politique britannique décrit les CRL comme l'un des mécanismes de révocation courants, tandis que les directives du secteur de la justice les traitent comme un mécanisme hors ligne principal et soulignent les exigences de disponibilité pour les services de révocation dans la déclaration de divulgation de l'infrastructure PKI.
Pour les appareils gérés via 802.1X, la CRL est généralement pratique pour une validation périodique par lots, en particulier lorsque le parc dispose d'une distribution interne fiable. L'OCSP est préférable lorsqu'une plus grande fraîcheur du statut est essentielle et que la disponibilité du répondeur est planifiée en conséquence. Les réseaux à haute assurance peuvent exécuter les deux, mais seulement si le comportement de repli est documenté et testé plutôt que supposé.
La révocation en pratique sur un réseau Purple WiFi
La différence opérationnelle apparaît lorsque l'accès WiFi est lié à un annuaire d'identités en direct plutôt qu'à une liste de certificats gérée manuellement. Une intégration d'annuaire permet d'intégrer l'état actuel du compte de l'utilisateur dans la décision d'authentification - ainsi, la désactivation d'un compte devient un événement de contrôle d'accès plutôt qu'un ticket qu'un administrateur doit ultérieurement traduire en révocation auprès de l'AC.
Un flux typique se présente ainsi :
- L'annuaire enregistre l'état de l'identité. Un compte est créé, modifié, suspendu ou désactivé dans Active Directory, Microsoft Entra ID ou Google Workspace.
- Le service d'identité WiFi reçoit la modification. Le service associe l'état de l'annuaire à la politique d'authentification de l'organisation.
- La prochaine authentification est évaluée par rapport à cet état. Une identité désactivée ne satisfait plus à la règle d'accès, même si un identifiant précédemment délivré reste dans sa période de validité de certificat.
- Le réseau refuse l'accès. La décision RADIUS empêche une nouvelle session 802.1X d'être autorisée sous l'identité inactive.
Ce modèle répond à une faiblesse des opérations basées uniquement sur les CRL. Une CRL dépend de la publication de l'AC, des points de distribution, des rafraîchissements de cache et des vérifications des parties de confiance. L'application basée sur l'annuaire fait du système d'identité la source unique de vérité opérationnelle pour le statut du compte, réduisant ainsi la nécessité pour un administrateur de rechercher chaque numéro de série de certificat associé à un utilisateur sortant.
Distinction opérationnelle : Une CRL indique si un certificat est révoqué. L'authentification basée sur l'annuaire peut indiquer si l'identité est actuellement autorisée à utiliser le réseau.
Purple fournit un service RADIUS géré et des contrôles WiFi d'entreprise basés sur des certificats avec des intégrations d'annuaires telles que Microsoft Entra ID et Google Workspace. Son offre RADIUS-as-a-Service est pertinente lorsqu'une organisation souhaite connecter l'état de l'identité à l'authentification 802.1X sans avoir à maintenir elle-même chaque composant RADIUS et de révocation sur site.
Cela ne fait pas disparaître le travail lié au cycle de vie de la PKI. Les certificats doivent toujours faire l'objet d'une émission, d'un renouvellement, d'une gestion de la chaîne de confiance et de vérifications de révocation là où l'architecture l'exige. Cependant, cela élimine un goulot d'étranglement manuel du parcours de départ des collaborateurs. Le centre de services peut désactiver l'identité via le flux de travail d'annuaire établi, tandis que la couche d'authentification réseau applique cet état lors de la prochaine décision d'accès.
Bonnes pratiques opérationnelles pour le WiFi d'entreprise
Une conception de révocation fiable associe des contrôles cryptographiques à une discipline opérationnelle ordinaire. Commencez par la durée de vie du certificat. Pour les appareils WiFi gérés, une durée de vie de certificat de 12 à 24 mois est une référence opérationnelle courante dans les guides de déploiement fournis, mais le bon choix dépend de la propriété de l'appareil, de la capacité de renouvellement et des dommages qu'une clé privée exposée pourrait causer. Les certificats de parrainage invités doivent généralement avoir des durées de vie plus courtes, car leur contexte d'accès change plus souvent.
Intégrer le renouvellement dans le cycle de vie des appareils
Utilisez SCEP, une plateforme MDM ou un autre chemin d'enrôlement automatisé pour renouveler les certificats avant leur expiration. Le renouvellement manuel fonctionne lors d'un projet pilote mais devient fragile sur un parc distribué. Testez le renouvellement sur les ordinateurs portables en veille, les appareils distants, les appareils réinstallés et les appareils qui ne se sont pas connectés récemment au réseau de l'entreprise.
Surveillez les points de distribution des CRL à partir des mêmes chemins réseau que ceux utilisés par le RADIUS et les contrôleurs. Vérifiez l'accessibilité, la validité de la signature, l'identité de l'émetteur et nextUpdate, et pas seulement si une requête Web renvoie du contenu. Une CRL accessible mais expirée reste un contrôle de révocation défaillant.
Gardez le côté RADIUS propre
Les certificats du serveur RADIUS ont besoin d'une validité à jour, d'une chaîne d'émission de confiance et d'un processus de renouvellement qui ne dépend pas d'une fenêtre de maintenance de dernière minute. Examinez les magasins de confiance sur les serveurs, les contrôleurs et les clients gérés afin qu'un ancien certificat d'AC ne crée pas de décisions incohérentes d'un site à l'autre.
Documentez le guide de procédure de révocation dans un langage qu'un ingénieur d'astreinte peut suivre :
- Identifier l'identifiant : Enregistrez l'utilisateur, l'appareil, le numéro de série du certificat et la CA émettrice.
- Désactiver l'identité : Appliquez l'action de départ approuvée dans l'annuaire ou les RH.
- Révoquer si nécessaire : Mettez à jour le statut de la CA et confirmez la publication.
- Actualiser les parties de confiance : Forcez ou planifiez la récupération de la CRL là où elle est prise en charge.
- Tester le refus : Tentez une authentification avec l'identifiant concerné et conservez le résultat.
Alignez les déclencheurs RH avec les modifications de l'annuaire. Si le centre de services doit attendre un ticket PKI distinct, le réseau peut continuer à faire confiance à une identité que l'organisation a déjà marquée comme inactive. L'approvisionnement et le renouvellement automatisés réduisent ce décalage, tandis qu'un processus manuel documenté reste important pour les appareils volés et les suspicions de compromission de clés.
Pour un accès collaborateur sans mot de passe, examinez comment ces contrôles s'intègrent à un déploiement WPA-Enterprise, y compris l'enrôlement des certificats, la validation RADIUS et la gestion des départs.
Dépannage des problèmes de révocation courants
La plupart des incidents liés aux CRL se divisent en trois catégories : le validateur dispose d'informations obsolètes, il ne trouve pas le bon point de publication, ou le magasin de révocation est devenu difficile à exploiter. Diagnostiquez le chemin de décision plutôt que de commencer par réémettre des certificats.
Un cache local obsolète
Un serveur RADIUS ou un contrôleur peut toujours détenir une CRL antérieure à la révocation. Confirmez les champs thisUpdate et nextUpdate de la CRL, validez sa signature par rapport à l'AC émettrice, et inspectez la copie mise en cache sur l'authentificateur. Comparez le numéro de série présenté par le client avec les entrées de la CRL nouvellement publiée.
La solution immédiate consiste à forcer un rafraîchissement de la CRL si la plateforme le prend en charge, puis à répéter un test d'authentification avec le certificat concerné. Si le cache continue de renvoyer d'anciennes données, inspectez le comportement du proxy, la mise en cache des points de distribution et la politique de rafraîchissement du validateur.
Un point de distribution manquant
Lisez les extensions CDP et AIA du certificat émis. Le CDP indique à la partie de confiance où trouver les informations de révocation, tandis que l'AIA peut l'aider à identifier les informations de l'émetteur nécessaires à la validation de la chaîne. Confirmez que l'URL est correcte, accessible depuis le réseau RADIUS et qu'elle fournit une CRL signée par l'émetteur attendu.
Si le modèle de CA contient le mauvais emplacement, corrigez le modèle et émettez des certificats de remplacement. La simple mise à jour de l'appareil ne réparera pas les certificats qui contiennent déjà un point de distribution inutilisable.
Un magasin de révocation encombrant
Les anciennes entrées peuvent compliquer l'administration et augmenter le travail de traitement. Ne supprimez les entrées que dans le cadre de la politique de conservation de l'AC et seulement après avoir pris en compte la durée de vie du certificat concerné et les exigences d'audit. Ne supprimez jamais un numéro de série simplement parce que le ticket d'incident est clôturé.
Les exemples de politiques britanniques montrent pourquoi la « fraîcheur » doit être définie localement. Certaines autorités britanniques exigent des mises à jour quotidiennes, tandis que la politique nationale de la CVCA exige une publication dans les 72 heures pour un certificat révoqué et fixe une période d'émission maximale de 90 jours. Considérez cela comme des bases politiques, et non comme une autorisation d'accepter des données d'entreprise obsolètes.
Un outil d'analyse de certificat peut vous aider à inspecter l'émetteur, la validité, le CDP et les détails de la chaîne. L'outil de vérification de certificat SSL de Purple est une option pour examiner la santé d'un certificat, tandis que l'application basée sur l'annuaire permet d'éviter de dépendre uniquement d'un rafraîchissement différé de la CRL pour le départ des utilisateurs.
Mise en pratique dès cette semaine
Faites de la révocation une tâche assignée plutôt qu'un simple paragraphe de politique de sécurité. Intégrez ces actions dans la prochaine fenêtre de modification et attribuez à chacune un responsable désigné.
- Équipe PKI, auditez les chemins de certification : Inventoriez chaque modèle de certificat client WiFi, CA émettrice, CDP et relation de confiance RADIUS. Confirmez que chaque point de distribution est accessible depuis chaque site d'authentification.
- Équipes PKI et terminaux, définissez une durée de vie défendable : Réduisez la durée de vie des certificats clients WiFi à 12 mois ou moins lorsque le processus de renouvellement des appareils le permet. Une durée de vie plus courte réduit la dépendance à l'égard de la révocation d'urgence, mais seulement si le renouvellement est automatisé et testé.
- Équipe terminaux, automatisez le renouvellement : Utilisez le MDM ou SCEP pour inscrire et renouveler les certificats sans intervention de l'utilisateur. Testez le processus après la réinitialisation d'un appareil, une longue période hors ligne et un changement d'utilisateur.
- Service desk et équipe identité, associez le départ de l'employé au refus d'accès : Faites en sorte que le statut inactif des RH ou du service desk soit directement pris en compte par le contrôle d'annuaire utilisé par l'authentification WiFi. Vérifiez qu'une identité désactivée ne peut pas établir de nouvelle session 802.1X.
- Équipe réseau, surveillez les dépendances de révocation : Créez des alertes pour les points de distribution indisponibles, les CRL expirées, les signatures invalides et les échecs de vérification de statut. Abonnez-vous aux notifications de modification de la CA afin qu'un changement de publication ne dégrade pas l'authentification sans que vous le sachiez.
Mesurez deux résultats au cours de la période d'examen suivante. Tout d'abord, enregistrez la latence entre un événement de désactivation d'annuaire et la résiliation ou le refus d'une nouvelle session WiFi. Deuxièmement, mesurez combien d'authentifications RADIUS ont effectué une vérification CRL réussie plutôt que de continuer via un chemin d'échec logiciel. Ces mesures vous indiquent si la conception fonctionne sous pression, et pas seulement si les certificats semblent corrects dans un tableur.
Si votre équipe souhaite réduire l'administration manuelle de la PKI tout en conservant un WiFi d'entreprise basé sur l'identité, Purple peut fournir une authentification gérée par certificat, des décisions d'accès connectées à l'annuaire et des services RADIUS prenant en charge la vérification de la révocation. Visitez Purple pour évaluer comment son approche pourrait s'intégrer dans votre flux de travail de désactivation WiFi et de cycle de vie des certificats.
