Bâtir la racine comme il faut, signer sa sous-CA, récupérer un an.

Toutes les composantes de la PKI Web publique se font raccourcir. Le programme de racines de Chrome indique maintenant que les CA subordonnées devraient plafonner à trois ans, et le CA/Browser Forum a une feuille de route qui fait passer les certificats feuilles TLS de 398 jours à 47. Rien de tout ça ne contraint votre ADCS interne. Votre hiérarchie privée répond à votre propre magasin de confiance, pas au programme de racines d'un navigateur. Mais ça indique d'où vient le vent, et ça concorde avec une chose que je tiens déjà pour acquise : rien de ce qu'on émet aujourd'hui ne survit au passage aux algorithmes post-quantiques. Chaque certificat de votre parc finira par être réémis sur des gabarits compatibles PQC. Plus on touche souvent à tout ça, moins ça fait mal le jour venu. Alors je bâtis court dès maintenant. Un an pour les certificats feuilles, point final. Traitez le cycle de renouvellement comme une répétition de la migration que vous savez inévitable.

Cette position change le calcul de l'échelonnement, alors commençons par là, parce que ça mène directement à un piège que le processus de construction recommandé vous offre gratuitement.

L'échelle est une convention, pas un calcul

L'ancienne recommandation de Microsoft était de dimensionner chaque CA selon le certificat feuille le plus long qu'elle dessert et de doubler grosso modo en remontant l'arbre. Feuille de deux ans, CA émettrice de quatre ans, racine de huit ans. Renouveler à mi-vie. C'est une règle propre et elle fonctionne.

C'est aussi entièrement une convention de conception. ADCS ne calcule « la moitié du parent » nulle part. Quand une CA émet un certificat, la validité qu'elle y inscrit est tout simplement la plus courte de trois valeurs :

• la validité demandée par le gabarit ou par la requête,
• le plafond d'émission de la CA elle-même, défini dans le registre,
• la durée de vie qu'il reste à la CA émettrice sur son propre certificat.

La plus courte l'emporte. Aucun doublage, aucune division par deux, aucune conscience de la position de cette CA dans la chaîne. Gardez ça en tête, parce que le piège vit dans l'écart entre deux paramètres qui ont l'air d'un seul.

Le piège, et il vient de la construction recommandée

Montez une racine hors ligne de la façon dont tout le monde vous le dit. Vous voulez une racine de longue durée, alors vous déposez un CAPolicy.inf dans C:\Windows pour fixer sa vie. Le mien ressemblait à ceci :

[Version]
Signature = "$Windows NT$"

[certsrv_server]
RenewalKeyLength = 4096
RenewalValidityPeriodUnits = 8
RenewalValidityPeriod = years

Lancez l'assistant de configuration, tapez 8 ans pour faire concorder, installez. Le certificat racine sort à huit ans, exactement comme prévu. Ensuite vous montez la CA émettrice, générez sa requête, l'apportez à la racine, la signez. Le certificat subordonné revient valide pour un an. Pas huit. Pas quatre. Un.

Rien de ce que vous avez tapé ne disait un an. Le CAPolicy.inf disait huit. L'assistant disait huit. La sous-CA a quand même atterri à un.

Deux paramètres, pas un seul

RenewalValidityPeriod et RenewalValidityPeriodUnits dans CAPolicy.inf définissent combien de temps la racine se fait confiance à elle-même. C'est le propre certificat de la racine, et rien d'autre. Ils ne touchent pas à ce que la racine distribue.

Ce que la racine va émettre est régi par une paire de valeurs de registre complètement distincte, sous HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<NomCA> :

• ValidityPeriod (chaîne, par exemple « Years »)
• ValidityPeriodUnits (DWORD)

C'est le plafond d'émission. Il plafonne tout ce que la CA signe, y compris un certificat de CA subordonnée. Et voici la partie qui mord : quand un CAPolicy.inf est présent, l'installeur lit vos paramètres de renouvellement pour le certificat auto-signé et laisse cette paire d'émission assise à sa valeur par défaut d'un an. Il ne recopie pas votre huit, et il ignore le chiffre que vous avez donné à l'assistant. Je l'ai vu atterrir à un sur plus d'une construction. La racine vit huit ans et n'émettra jamais que des certificats d'un an tant que vous ne dites pas le contraire.

Donc le chemin qui produit une racine convenable, celui avec l'OID de politique, la longueur de clé de renouvellement, les paramètres de CRL et l'énoncé de pratiques que vous voulez vraiment, est le même chemin qui épingle discrètement votre plafond d'émission à un an. La construction recommandée est celle qui arme le piège.

À quoi ça ressemble

C'est Truvald qui lit le registre sur la CA émettrice, où ValidityPeriodUnits affiche 2. La racine, dans la même construction, est arrivée à 1. La même valeur, deux CA, deux chiffres très différents, et un seul des deux est le chiffre que quelqu'un a réglé volontairement. Truvald précise ce que fait la valeur et la commande exacte pour la modifier, ce qui est la prochaine partie.

Le correctif

Sur la racine, réglez le plafond d'émission à ce que vous voulez vraiment que la sous-CA soit, puis redémarrez le service :

certutil -setreg CA\ValidityPeriod "Years"
certutil -setreg CA\ValidityPeriodUnits 4
net stop certsvc && net start certsvc

Resoumettez la requête de la CA émettrice, signez-la de nouveau, et le certificat subordonné sort à quatre ans au lieu d'un. Le quatre n'est qu'un exemple. Réglez-le selon votre conception. La même manoeuvre s'applique partout dans la chaîne. Si une CA distribue des certificats plus courts que prévu, le plafond d'émission est le premier endroit à regarder, pas le gabarit.

Pourquoi ça compte plus maintenant

Quand les durées de vie des feuilles se mesuraient en années, un plafond d'émission mal lu était un agacement qu'on attrapait une fois et qu'on oubliait. À mesure que les durées raccourcissent et qu'on se met à toucher aux renouvellements volontairement, chaque CA du chemin a besoin que son plafond soit réglé délibérément, pas laissé à ce que l'installeur a mis par défaut dans votre dos. Réglez-le consciemment. Notez-le. Vous allez revenir ici plus tôt que la vieille racine de huit ans vous laissait le croire.

Une à tester de votre côté

Cette valeur par défaut d'un an, c'est le chemin avec CAPolicy.inf, que j'ai bâti et confirmé plus d'une fois. Il y a un cas voisin que je n'ai pas appuyé par une capture : montez la racine sans aucun CAPolicy.inf, et dites simplement quatre ans à l'assistant. Où atterrit ValidityPeriodUnits à ce moment-là ? Sans paramètre de renouvellement en jeu, le certificat auto-signé n'a que la valeur de l'assistant à lire, alors on peut argumenter que le registre doit porter votre quatre. Mais le seul chiffre auquel je me fie est celui qui revient de certutil -getreg CA\ValidityPeriodUnits. Si vous avez déjà bâti une racine comme ça, lancez la commande et dites-moi ce que vous avez obtenu. Je veux fermer l'écart avant de considérer la chose réglée.