Mettre en place une CA racine hors ligne : le guide complet

Chaque certificat auquel votre organisation fait confiance remonte à un objet unique : la clé de la CA racine. Si cette clé fuit, un attaquant peut fabriquer des identifiants valides pour n'importe quel serveur, utilisateur ou équipement de votre périmètre, et la remise en état suppose de reconstruire la confiance à zéro sur chaque poste, chaque équipement et chaque charge de travail.

C'est la raison pour laquelle les programmes PKI matures maintiennent la racine hors ligne : éteinte, déconnectée de tout réseau, et réveillée uniquement pour de rares cérémonies scriptées. Ce guide déroule l'installation complète en cinq étapes, puis aborde le piège opérationnel qui casse silencieusement plus de PKI que n'importe quel attaquant.

Pourquoi hors ligne, en résumé

La racine existe pour une seule mission : signer les certificats d'un petit nombre de CA émettrices subordonnées, publier une liste de révocation de temps à autre, et rester éteinte le reste du temps pendant que l'émission quotidienne s'effectue sur les CA émettrices en ligne.

La surface d'attaque s'effondre. 

Une racine qui ne touche jamais un réseau ne peut être attaquée que par un accès physique et par la procédure de cérémonie, deux éléments que vous maîtrisez entièrement.

Le périmètre d'impact se réduit. 

Une CA émettrice compromise, c'est une mauvaise semaine : vous la révoquez au niveau de la racine, vous en montez une nouvelle, vous réémettez. Une racine compromise, c'est un événement existentiel.

Les auditeurs l'attendent. 

Les agences nationales de cybersécurité, dont l'ANSSI et le NCSC britannique, convergent vers la même conception : une hiérarchie à deux niveaux avec une racine hors ligne et des CA émettrices en ligne, aussi simple que l'organisation le permet.

Étape 1 : concevoir la hiérarchie sur le papier

Résistez à l'envie de démarrer quoi que ce soit avant d'avoir écrit l'architecture.
Créez une structure où une racine hors ligne signe un petit nombre de CA émettrices, réparties par fonction plutôt qu'au gré des circonstances : une pour le TLS, une pour l'authentification des utilisateurs et des équipements, éventuellement une pour la signature de code.

• Durées de vie : un schéma interne courant donne dix à vingt ans à la racine, cinq à dix ans aux CA émettrices, et un an ou moins aux certificats d'entité finale, avec une préférence pour des durées de vie plus courtes partout où l'automatisation existe.

• Algorithmes : RSA 3072 ou une courbe elliptique aujourd'hui, avec une trajectoire claire vers les signatures hybrides et post-quantiques, parce qu'une racine créée en 2026 ancrera encore la confiance en 2040.

• Politique : rédigez la politique de certification et la déclaration des pratiques de certification, même courtes. Les auditeurs les demandent, et leur rédaction révèle les angles morts très tôt.

Étape 2 : protéger la clé dans du matériel

Une clé racine générée de façon logicielle sur un portable est une clé racine qui a séjourné, aussi brièvement soit-il, dans la mémoire d'une machine polyvalente. Les déploiements sérieux font mieux.

• Générez et conservez la clé dans un HSM certifié FIPS 140 niveau 3 ou selon un schéma équivalent, afin que la clé privée ne quitte jamais le matériel sous une forme exploitable.

• Imposez un contrôle par quorum, par exemple trois cartes à puce sur cinq, avec des porteurs issus d'équipes différentes.

• Séparez les sauvegardes : enveloppes à témoin d'effraction, coffres distincts, idéalement bâtiments distincts.

• Avec un budget serré, il existe des formats matériels plus modestes, mais le principe du quorum reste non négociable.

Étape 3 : publier les CDP et AIA avant la première signature

Voici l'étape que les débutants découvrent trop tard. Chaque certificat signé par la racine embarque deux ensembles d'URL : le point de distribution de CRL (CDP), où les parties utilisatrices récupèrent la liste de révocation de la racine, et le champ d'accès aux informations de l'autorité (AIA), où elles récupèrent le certificat racine lui-même. Ces valeurs sont gravées pour toujours dans les certificats subordonnés : elles doivent donc être correctes dès le départ.

• Montez d'abord le point de publication HTTP, sur des noms d'hôte stables et neutres, indépendants du sort d'un serveur en particulier.

• Sur Microsoft AD CS, modifiez les paramètres CDP et AIA par défaut avant d'émettre le certificat subordonné.

• Validez ensuite la chaîne avec certutil et pkiview, ou l'équivalent sur votre environnement.

Étape 4 : mener la cérémonie avec le sérieux qu'elle mérite

Une cérémonie des clés est une mise en scène à portée juridique. Son résultat n'est pas seulement une clé : ce sont les preuves qui vous permettront de répondre à un auditeur ou à un tribunal avec des documents plutôt qu'avec des souvenirs.

• Scriptez tout : chaque commande, chaque sortie attendue, chaque point de décision.

• Réunissez les rôles : un opérateur, un lecteur de script distinct, les porteurs du quorum et au moins un témoin indépendant, caméras en marche si votre référentiel de conformité l'exige.

• Travaillez proprement : une salle sans prise réseau, une machine construite à partir de supports vérifiés.

• Exécutez et scellez : générez la clé dans le HSM, créez le certificat racine, signez les certificats des CA émettrices, générez la première CRL, exportez uniquement les artefacts publics, signez le journal, scellez les matériels, éteignez.

Étape 5 : inscrire la CRL de la racine au calendrier

Voici la partie contre-intuitive. Une racine hors ligne doit tout de même au monde un artefact récurrent : sa liste de révocation de certificats. Les parties utilisatrices la consultent pour confirmer qu'aucune CA émettrice n'a été révoquée, et elle porte une date d'expiration. Lorsqu'elle expire, la validation de chaîne échoue sur l'ensemble du parc, de manière déroutante, puisque rien n'a été révoqué et que rien n'a visiblement changé. Les CRL racine expirées comptent parmi les pannes PKI auto-infligées les plus fréquentes.

• Donnez à la CRL racine une validité longue, couramment de six à douze mois.
• Inscrivez la cérémonie de renouvellement au calendrier, avec des alertes adressées à plusieurs responsables.
• Surveillez la fraîcheur de la CRL publiée depuis l'extérieur, exactement comme vous surveillez l'expiration des certificats.

Entre deux cérémonies, la racine vit sous forme de matériel scellé dans un coffre, avec une chaîne de responsabilité documentée, et ne se réveille qu'une ou deux fois par an : pour renouveler la CRL, signer une nouvelle CA émettrice ou répéter la procédure de reprise avec le quorum présent. Une procédure de reprise que personne n'a jamais répétée est un espoir, pas un plan.

Comment Evertrust peut vous aider

Stream, notre plateforme PKI, exploite des hiérarchies multi-niveaux avec racines hors ligne, s'intègre à des HSM comme la gamme Thales Luna, y compris des firmwares avec prise en charge native de ML-KEM et ML-DSA, et maintient chaque clé sous le contrôle exclusif du client. Sa certification CSPN par l'ANSSI traduit la même philosophie que celle enseignée dans ce guide.

Horizon, notre plateforme de gestion du cycle de vie, surveille ce que les humains oublient : la fraîcheur des CRL, l'expiration des subordonnées et la santé des chaînes sur tout le parc, avec des alertes routées vers de vrais responsables.

Confrontez-la à votre propre parc : demandez une démonstration d'Horizon et de Stream sur evertrust.io.

Vos questions sur la racine hors ligne

Q : à quelle fréquence la racine est-elle remise en ligne ?
R : généralement une ou deux fois par an : renouvellement de la CRL, signature d'une nouvelle CA émettrice ou répétition d'une procédure de reprise. Une fréquence supérieure suggère des tâches qui relèvent d'une CA émettrice.

Q : une machine virtuelle éteinte peut-elle servir de racine ?
R : c'est préférable à une racine toujours allumée, mais une image de VM se copie d'une façon dont du matériel scellé ne se copie pas. Si vous acceptez ce compromis, compensez par une garde stricte de l'image et des clés protégées par HSM.

Q : et si la CRL de la racine a déjà expiré ?
R : convoquez la cérémonie, réémettez la CRL avec une nouvelle fenêtre de validité, republiez-la sur tous les emplacements CDP, puis corrigez le processus : calendrier, alertes et supervision externe de la fraîcheur.

Q : la certification croisée est-elle pertinente ici ?
R : oui, au moment des transitions. Lorsque la racine elle-même finit par changer, pour cause d'âge ou d'algorithme, la certification croisée permet à la nouvelle racine d'hériter progressivement de la confiance pendant que les clients se mettent à jour, ce qui évite une bascule brutale.