Certificats sur votre réseau : la PKI avec AD CS de bout en bout

Un certificat numérique est un acte de confiance avec papiers : quelqu'un qui se porte garant pour vous affirme que cette clé publique lui appartient. Une infrastructure de clé publique (PKI) est la combinaison de logiciel, de chiffrement, de processus et de services qui s'occupe de cet échange de certificats, et dans Windows Server cette PKI s'implémente avec le rôle AD CS. Ce post parcourt de bout en bout quels services elle distribue, comment s'articule la hiérarchie, ce qu'il y a dans un certificat, comment se fait l'inscription, comment se fait la révocation, et pourquoi une machine décide de faire confiance. Ce qui suit vient du module « Implement and administer Active Directory Certificate Services (AD CS) » de Microsoft Learn.

En pratique, chaque fois que deux systèmes doivent parler avec une identité vérifiée, quelqu'un doit répondre de chacun. La PKI organise ce « quelqu'un » à grande échelle : au lieu de s'accorder les confiances de pair à pair, une hiérarchie d'autorités émet des certificats que les autres acceptent tant qu'ils font confiance à qui les a signés. Le reste du post est cette chaîne, pièce par pièce.

Quels services distribue AD CS

Le rôle apporte trois services avec des métiers différents :

Autorité de certification (CA). Émet et révoque les certificats et publie les listes de révocation (CRL) et les emplacements d'information d'autorité (AIA).
Service web d'inscription de certificats (CES). Fait le mandataire entre une machine Windows et la CA : demande, renouvelle et installe les certificats, récupère la CRL et interroge l'état pour le compte de machines qui ne sont pas membres d'un domaine ou qui n'exécutent pas Windows.
Répondeur en ligne (OCSP). Permet aux clients Windows de vérifier l'état d'un certificat sans télécharger toute la CRL.

La répartition est pratique : la CA signe, le CES intervient pour ceux qui ne peuvent pas le faire seuls, et OCSP évite de télécharger la liste complète à chaque validation.

Un cas d'usage du CES : un machine de labo qui n'est pas membre d'un domaine a besoin d'un certificat. Sans le CES, la demande se ferait à la main contre la CA ; avec le CES, cette machine Windows demande par mandataire, renouvelle, installe et vérifie l'état sans appartenir au domaine et sans que la CA se mêle de ce qui ne la regarde pas.

La hiérarchie : deux nivegles et une règle

Le design habituel a deux niveaux : une CA racine qui reste hors réseau et une CA émettrice subordonnée qui émet les certificats aux utilisateurs et aux ordinateurs. Dans les petits environnements, une seule CA racine qui émet aussi peut suffire. Au-delà, la règle est de ne pas dépasser trois niveaux de hiérarchie.

flowchart TD
    R[CA racine : hors réseau] --> E[CA émettrice subordonnée : émet aux utilisateurs et ordinateurs]
    R --> PD[CA de politiques : n'émet qu'à d'autres CA]
    E --> U[Utilisateurs et ordinateurs en ligne]
    PD --> E2[Autres CA]

Il y a un type de plus : la CA de politiques, qui est subordonnée directe de la racine et n'émet des certificats qu'à d'autres CA, reflétant les politiques et procédures de l'organisation. Elle est obligatoire dans les organisations avec des divisions ou des secteurs qui suivent des procédures d'émission distinctes : chaque secteur signe avec les règles qui le concernent, sans négocier directement avec la racine.

Un détail d'opération : la première CA déployée devient la racine, et les subordonnées lui font implicitement confiance. Toute la chaîne pendant de cette confiance, protéger la racine, c'est protéger tout l'échafaudage : d'où son travail réduit après le premier jour et son privilège important.

Ce qu'il y a dans un certificat

Un certificat est un petit fichier avec les données du propriétaire (adresse e-mail, nom, type d'usage autorisé, période de validité et les URLs AIA et CDP) et sa clé publique embarquée.

Derrière se trouve la paire de clés : un algorithme génère deux clés mathématiquement liées, avec la propriété qui tient tout le système. Ce qui est chiffré avec la clé publique ne se déchiffre qu'avec la clé privée, et inversement ; de plus, la privée ne peut pas être dérivée de la publique dans un temps raisonnable. D'où le fait que le propriétaire garde sa privée comme de l'or et partage sa publique en toute tranquillité.

Inscription : comment on en obtient un

Le client génère la paire de clés et envoie la publique à la CA. La CA confirme les informations, signe le certificat avec sa clé privée et le rend au client, qui l'installe et l'utilise. C'est le même modèle que le permis de conduire : vous n'imprimez pas votre propre carte, un signataire se porte garant pour vous devant qui la regarde.

Révocation : désactiver avant l'heure

Les certificats expirent tout seuls ; le problème est celui qu'il faut invalider avant, quand la clé n'est plus là où elle devait être ou la personne à qui on l'a donnée ne devrait plus avoir accès. La révocation désactive un certificat avant sa date d'expiration, et la CA émettrise enregistre l'empreinte du certificat révoqué dans la CRL. Le processus a trois étapes :

flowchart LR
    A[1. Révoquer depuis la console : motif, date et heure] --> B[2. Publier la CRL : manuelle ou planifiée, vers AD DS, un dossier partagé ou un site web]
    B --> C[3. Le client interroge l'état à la CDP publiée]

D'abord on révoque depuis la console de la CA, en laissant motif, date et heure. Ensuite la CRL est publiée, manuellement ou selon un plan, vers AD DS, un dossier partagé ou un site web. Et enfin, le client Windows interroge le point de distribution de révocations (CDP) publié dans le certificat et vérifie l'état automatiquement, avec CryptoAPI.

L'étape à regarder quand quelque chose échoue est la seconde : révoquer sans publier laisse les clients lire une liste périmée. Et celui qui économise du trafic est OCSP, qui vérifie l'état sans télécharger toute la CRL.

La confiance : l'ingrédient qui paraît évident

Un certificat n'est efficace que si la machine fait confiance à la CA qui l'a émis. Selon qui le signe, les certificats sont internes (CA d'organisation propre), externes (CA publique, à coût) ou auto-signés.

Toute la discussion se résume à une question : la CA racine est-elle dans le magasin de certificats de la machine qui valide ? Si elle n'y est pas, aucun certificat interne ne servira, si bien signé soit-il. D'où le fait que le magasin Autorités de certification racines de confiance est la première étape du diagnostic.

Les cas limites consomment plus de temps que le reste. Les machines en groupe de travail n'acceptent pas les certificats d'une CA d'entreprise ; pour elles il y a deux chemins : obtenir des certificats de CA publiques, ou configurer chaque machine de groupe de travail pour qu'elle fasse confiance à la CA racine. En même temps, les modèles de certificat ne sont disponibles qu'avec une CA d'entreprise.

D'où l'utilité de distinguer la CA autonome de la CA d'entreprise. Avec une CA autonome, chaque demande de certificat se crée manuellement et inclut toutes les informations nécessaires, ou passe par l'inscription web ; l'approbation automatique des demandes n'est pas disponible. Une CA d'entreprise dispose de modèles de certificat et du service d'inscription automatique, elle accepte donc l'inscription manuelle, web ou automatique. Le modèle est le contrat qui décide ce que chaque machine peut demander et avec quels paramètres.

Avec quoi on l'administre

Quatre outils couvrent le quotidien : Windows Admin Center, le module de certificats de MMC, PowerShell et certutil. Et les magasins de certificats regroupent ce qu'il y a dans des dossiers comme Personnel et Autorités de certification racines de confiance, où le client regarde quand il faut répondre s'il a confiance en quelque chose.

Ce qui se décide en premier

L'ordre de conception ressemble à celui du reste du répertoire : d'abord ce qui se signe et pour qui (et qui reste dehors : groupe de travail, secteurs avec procédures propres), ensuite la forme de la hiérarchie (racine hors réseau, émettrice subordonnée, une CA de politiques si la taille l'exige), et seulement ensuite inscription, révocation et outils. Monter la hiérarchie à l'envers produit une racine en ligne que personne n'ose toucher et des émissions qui ne reconnaissent personne.

Limite de cette source : elle décrit la conception, les services et les procédures, et n'apporte ni modèles par usage, ni cadences de renouvellement, ni tailles de CRL mesurées ; l'opération concrète d'une PKI en production a donc encore besoin de ses propres mesures.

*Source : le module « Implement and administer Active Directory Certificate Services (AD CS) » de Microsoft Learn.*