Autorité de certification souveraine pour l'émission et la gestion de certificats à l'échelle de l'entreprise
Gestion du cycle de vie des certificats : découverte, gouvernance et automatisation
Domain Control Validation agnostique des DNS, prêt pour les certificats TLS de 47 jours
Une autorité de certification racine est une ancre de confiance auto-signée présente dans le magasin de confiance de chaque navigateur et système d'exploitation. Les autorités intermédiaires se situent un ou plusieurs niveaux en dessous, prennent en charge l'émission quotidienne, et permettent de garder la racine hors-ligne. Ce guide couvre les hiérarchies à deux et trois niveaux, BasicConstraints et les contraintes de nom, les cérémonies de clés, et les contrôles opérationnels attendus par RFC 5280 et le CA/Browser Forum.
Une autorité de certification racine est une ancre de confiance auto-signée : le magasin de confiance du système d'exploitation, du navigateur ou du périphérique la reconnaît directement, et aucune autorité supérieure n'a besoin de la cautionner. Tous les autres certificats émis dans une hiérarchie tirent finalement leur crédibilité de cette unique clé racine, raison pour laquelle les opérateurs de racine la traitent presque comme du matériel nucléaire — générée une seule fois, conservée hors-ligne, utilisée seulement une poignée de fois sur l'ensemble de sa durée de vie.
Les autorités de certification intermédiaires existent parce qu'utiliser directement la racine est une mauvaise idée. En signant une ou plusieurs CA subordonnées puis en mettant la racine sous clé, un opérateur peut faire tourner l'émission quotidienne sur les intermédiaires tout en préservant une ancre de confiance hors-ligne et récupérable. La même structure rend également possible la segmentation : un intermédiaire pour le TLS public, un autre pour le mTLS interne, un autre pour la signature de code, chacun avec sa propre politique, son profil de certificat, et sa portée de révocation. Si un intermédiaire est compromis, vous pouvez le révoquer et le remplacer sans avoir à désinstaller des racines sur des millions d'appareils.
Le parcours inverse de cette chaîne — du certificat d'entité finale, à travers les intermédiaires, jusqu'à la racine présente dans le magasin de confiance — c'est ce que fait la validation de chemin X.509 à chaque handshake TLS. La mécanique de ce parcours est couverte par chaînes de certificats et confiance et la structure des champs par X.509. Ce guide aborde l'autre face du même problème : comment concevoir la hiérarchie qui produit, en amont, une chaîne propre et validable. Tout ce qui suit s'appuie sur la RFC 5280, le profil IETF de X.509 qui définit ce qu'est réellement un certificat de CA.
Une PKI opérationnelle n'est pas une liste plate d'émetteurs : c'est un petit arbre avec des règles très précises sur quel nœud a le droit de signer quoi. La RFC 5280 inscrit ces règles dans deux extensions présentes sur chaque certificat de CA : `basicConstraints` indique si le certificat peut, ou non, émettre d'autres certificats, et `pathLenConstraint` plafonne le nombre d'intermédiaires qui peuvent apparaître en dessous. Presque chaque décision d'architecture que vous prenez — deux ou trois niveaux, un seul intermédiaire ou plusieurs, segmentation régionale ou par cas d'usage — revient à la manière dont ces deux extensions sont renseignées à chaque étage.
Avant de débattre des hiérarchies, mieux vaut être précis sur ce que sont ces trois niveaux et sur ce qui les distingue au niveau du certificat.
La propriété intéressante de cette structure est que le rayon d'impact d'une compromission est confiné à chaque niveau. Une clé d'entité finale fuitée brûle un service. Un intermédiaire compromis brûle tout ce qu'il a émis, mais la racine reste intacte et un intermédiaire de remplacement peut être signé lors d'une seule cérémonie de clés. Une racine compromise brûle la PKI entière et déclenche une mise à jour de magasin de confiance sur chaque appareil de la planète — ce qui explique pourquoi la racine est précisément la chose qui ne va jamais en ligne.
La racine est un certificat auto-signé dont les champs Subject et Issuer sont identiques. Elle porte `basicConstraints: CA:TRUE` avec un `pathLenConstraint` généralement fixé à 1 (pour une PKI à deux niveaux) ou 2 (pour une PKI à trois niveaux), et un `keyUsage: keyCertSign, cRLSign`. La confiance accordée à une racine ne vient jamais d'une signature — elle vient du fait qu'un système d'exploitation, un navigateur ou un périphérique a été livré avec ce certificat exact (ou sa clé publique) déjà installé. Les racines sont générées une fois, conservées hors-ligne, utilisées pour signer un petit nombre de certificats subordonnés et de CRL, et laissées intactes le reste du temps. Les racines TLS publiques ont typiquement des durées de validité de 20 à 25 ans ; certaines racines privées d'entreprise vivent plus longtemps encore.
Un intermédiaire porte `basicConstraints: CA:TRUE` et est signé par la racine (ou, dans une PKI à trois niveaux, par une CA de politique située au-dessus). Son `pathLenConstraint` est habituellement 0, ce qui veut dire qu'il peut émettre des certificats d'entité finale mais ne peut lui-même signer aucune autre CA. Les intermédiaires font le vrai travail : ils sont en ligne, intégrés à l'autorité d'enregistrement, automatisés via ACME, SCEP, EST ou CMP, et ils signent des certificats par milliers. C'est aussi le niveau que vous révoquez quand quelque chose tourne mal, parce que révoquer un intermédiaire échoue de manière sûre pour tout ce qu'il a émis sans toucher à la racine.
La feuille de l'arbre. `basicConstraints: CA:FALSE` (ou l'extension peut être omise, avec le même effet selon RFC 5280). Il ne peut jamais signer un autre certificat — uniquement les données pour lesquelles il a été émis : un handshake TLS, un message S/MIME, une signature de code, une authentification mTLS. La validité d'une entité finale est courte par conception : le CA/Browser Forum prévoit, dans ses Baseline Requirements, de plafonner les feuilles TLS publiques à 47 jours d'ici 2029, et la plupart des déploiements mTLS internes tournent déjà bien plus court que cela. Des durées de vie de feuille courtes sont ce qui permet à un opérateur de tolérer un chemin de révocation lent.
Si une racine pouvait signer en toute sécurité directement des certificats d'entité finale, personne ne s'embarrasserait d'intermédiaires. Ils existent pour trois raisons cumulatives, et toute conception de PKI qui les ignore finit par les reconstruire plus tard, sous la pression.
Une formulation utile : la racine est une clé à long terme, basse fréquence, fort impact, et l'intermédiaire est une clé à moyen terme, haute fréquence, récupérable. Les deux ne sont pas interchangeables, et les confondre — en signant des feuilles directement depuis une « racine » ou en traitant un intermédiaire comme s'il était l'ancre de confiance — est le péché originel derrière la plupart des migrations de PKI laborieuses.
L'intermédiaire est l'unité de révocation. Si une CA émettrice est compromise — son HSM mal manipulé, un opérateur de signature hameçonné, un bug logiciel qui expose la clé — vous révoquez le certificat de cet intermédiaire, publiez la révocation via CRL et OCSP, et signez un remplaçant depuis la même racine hors-ligne. Tous les certificats d'entité finale dont la chaîne passait par l'intermédiaire brûlé échouent automatiquement de manière sûre, sans que personne ait à toucher à la racine ni à pousser de mise à jour de magasin de confiance. Révoquer une racine, à l'inverse, demande à chaque éditeur de navigateur et d'OS de livrer une mise à jour logicielle, et la longue traîne d'appareils non patchés peut ne jamais la recevoir.
Différentes populations de certificats ont des politiques, des fenêtres de validité et des exigences d'audit différentes. Le TLS public est régi par les Baseline Requirements du CA/Browser Forum ; la signature de documents est régie par eIDAS ; les certificats internes d'appareils peuvent n'être régis que par votre politique interne. Placer chaque population derrière son propre intermédiaire — et rédiger une politique de certificat et un CPS distincts pour chacune — vous permet d'auditer et de renouveler chacune indépendamment. Cela permet aussi à la clé d'émission de vivre dans la bonne partition HSM pour cette population, avec les bons opérateurs autorisés à l'utiliser.
La propriété la plus coûteuse d'une racine est le coût de son remplacement. Les racines TLS publiques mettent des années à se propager dans les magasins de confiance, et les vieux appareils peuvent rester épinglés à l'ancienne racine pour le reste de leur durée de service. Les intermédiaires n'ont pas cette contrainte — ils vivent et meurent à l'intérieur de la durée de vie de la racine au-dessus. C'est cette asymétrie qui vous permet de renouveler les intermédiaires sur une cadence régulière (tous les 5 à 10 ans, ou après une compromission) sans jamais demander aux programmes de magasins de confiance de faire quoi que ce soit.
Une fois qu'un opérateur a accepté que la racine et l'étage d'émission doivent être des clés différentes, la question suivante est d'insérer, ou non, un troisième niveau — une CA de politique — entre les deux. La réponse est presque toujours « non, sauf que » — adaptée à la plupart des entreprises, nécessaire à certaines.
Le bon défaut pour la plupart des organisations, c'est deux niveaux. Il offre un confinement complet du rayon d'impact, prend en charge la segmentation par cas d'usage via plusieurs CA émettrices, et garde le nombre de cérémonies hors-ligne raisonnable. Trois niveaux ne se justifie que lorsque la frontière de politique est réelle — quand différentes parties de l'organisation doivent opérer, de manière démontrable, sous des politiques différentes, avec des auditeurs différents, des partitions HSM différentes et des officiers de signature différents — et quand le coût d'un étage hors-ligne supplémentaire est justifié par cette séparation. La plupart des équipes qui se tournent vers trois niveaux parce que « plus de couches ça paraît plus sûr » finissent avec la même posture de confiance et deux fois plus de procédures.
Le CA/Browser Forum et la plupart des programmes racines publics partent du principe d'un modèle à deux niveaux pour les nouvelles hiérarchies TLS publiques. Les audits WebTrust, eux, sont agnostiques sur la profondeur mais très précis sur les contrôles à chaque étage.
| Deux niveaux (Racine → Émettrice) | Trois niveaux (Racine → Politique → Émettrice) | |
|---|---|---|
| Couches | Racine hors-ligne signe directement une ou plusieurs CA émettrices en ligne | Racine hors-ligne signe des CA de politique hors-ligne, qui signent les CA émettrices en ligne |
| Complexité opérationnelle | Faible : une cérémonie de racine hors-ligne, CA émettrices sous HSM | Élevée : cérémonies de clés distinctes pour la racine et chaque CA de politique, davantage de procédures à maintenir |
| Segmentation | Par intermédiaire (TLS public / mTLS / signature de code sur des CA émettrices distinctes sous la même racine) | Par CA de politique (unités organisationnelles, régimes réglementaires ou filiales distincts, avec plusieurs CA émettrices sous chacune) |
| Utilisateur type | PME et la plupart des entreprises, PKI internes d'appareils, CA publiques de taille intermédiaire | Gouvernements, grands groupes financiers, multinationales régulées, prestataires de services de confiance qualifiés eIDAS, programmes racines qui certifient de manière croisée d'autres CA |
| Coût de validation de chemin | 2 vérifications de signature + 1 lookup d'ancre de confiance | 3 vérifications de signature + 1 lookup d'ancre de confiance ; handshake légèrement plus volumineux ; mauvaise configuration plus fréquente (plus de chaîne à oublier de servir) |
| `pathLenConstraint` sur la racine | 0 ou 1 | 1 ou 2 |
Le caractère « CA » d'un certificat n'est pas une étiquette — c'est la combinaison de `basicConstraints`, `keyUsage` et `pathLenConstraint` qu'un vérificateur RFC 5280 contrôle sur chaque maillon de la chaîne. La vérification la moins coûteuse sur une PKI consiste à imprimer ces extensions et à confirmer qu'une feuille est bien une feuille, qu'un intermédiaire est bien un intermédiaire, et que la racine est bien la racine.
Le second bloc ci-dessous est ce qu'un opérateur exécute lors d'une cérémonie de clés contrôlée pour émettre un intermédiaire depuis une racine hors-ligne. Les commandes paraissent banales ; ce sont les procédures qui les entourent — machine air-gappée, cérémonie filmée, quorum M-sur-N sur le token HSM — qui rendent le certificat résultant digne de confiance.
Les contraintes de nom (`nameConstraints`) dans ce fichier d'extensions font un vrai travail : elles disent à tout vérificateur RFC 5280 conforme de rejeter toute feuille que cet intermédiaire viendrait à signer et qui ne tomberait pas sous `.corp.example.com` ou `.internal.example`. C'est une application au niveau cryptographique, pas au niveau de la politique, et c'est le contrôle le plus sous-utilisé en PKI privée.
# Inspect a root or intermediate certificate and confirm its CA extensions
openssl x509 -in intermediate.pem -noout -text \
| grep -A2 -E 'Basic Constraints|Key Usage|Subject:|Issuer:|Not Before|Not After'
# Expected on an intermediate:
# Issuer: CN=Example Root CA
# Subject: CN=Example Issuing CA 1
# X509v3 Basic Constraints: critical
# CA:TRUE, pathlen:0
# X509v3 Key Usage: critical
# Certificate Sign, CRL Sign
# Not Before / Not After spanning roughly 5 to 10 years
# Walk the chain from a server leaf back to the root and confirm path validation
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null \
| sed -n '/-----BEGIN CERT/,/-----END CERT/p' > served-chain.pem
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt \
-untrusted served-chain.pem served-chain.pem
# A clean output reads "OK" and implicitly confirms that:
# 1. each certificate is signed by the next one up,
# 2. each issuer carries CA:TRUE,
# 3. the pathLenConstraint is not exceeded,
# 4. the chain terminates at a root in the trust store.# On the offline root machine (HSM attached, no network), sign an issuing CA CSR.
# The extensions file pins pathLen=0, keyUsage, and optionally nameConstraints.
cat > issuing-ca.ext <<'EOF'
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
# Optional but recommended for private PKI: restrict what this CA can issue under.
nameConstraints = critical, permitted;DNS:.corp.example.com, permitted;DNS:.internal.example
crlDistributionPoints = URI:http://crl.example.com/root.crl
authorityInfoAccess = OCSP;URI:http://ocsp.example.com/
EOF
openssl ca -config root-ca.cnf \
-extfile issuing-ca.ext \
-in issuing-ca.csr \
-out issuing-ca.pem \
-days 3650 \
-notext -batch
# The root's private key, held in the HSM, never touches disk. After issuance,
# the root machine is shut down and re-sealed until the next ceremony.Les contrôles ci-dessous ne sont pas une liste de souhaits. Ce sont les exigences de base que les auditeurs WebTrust, les membres du CA/Browser Forum, l'ANSSI pour les services de confiance qualifiés eIDAS, et la plupart des équipes sécurité d'entreprise cherchent à voir lors d'une évaluation de PKI. Aucun n'est exotique, mais l'absence d'un seul suffit habituellement à faire échouer un audit ou, pire, à laisser ouverte une voie d'attaque réelle.
Une PKI qui respecte ces cinq contrôles tend à satisfaire, presque gratuitement, les exigences des Baseline Requirements du CA/Browser Forum, de WebTrust for CAs, d'ETSI EN 319 411 (sous eIDAS), et les contrôles ISO 27001 pertinents. Il ne s'agit pas de cinq programmes différents — ce sont les mêmes contrôles, écrits par des organismes différents.
La clé privée de la racine doit être générée à l'intérieur, et ne jamais quitter, un module matériel de sécurité (HSM) certifié au minimum FIPS 140-2 niveau 3 — de préférence FIPS 140-3 niveau 3 pour les nouveaux déploiements, avec Critères Communs EAL4+ lorsque le régime réglementaire l'impose. La machine qui héberge le logiciel de CA racine est physiquement air-gappée : aucune interface réseau, supports amovibles manipulés sous contrôle binôme, sous tension uniquement lors des cérémonies planifiées. Les CA émettrices en ligne signent elles aussi à travers un HSM, mais leur machine peut être en ligne — la frontière qui compte est celle du HSM, pas celle du système d'exploitation. Consultez le guide HSM pour la hiérarchie des niveaux FIPS et les schémas d'intégration.
Les contraintes de nom sont le seul mécanisme qui permet à une partie de confiance d'imposer, de manière cryptographique, qu'un intermédiaire privé ne puisse pas émettre un certificat pour `google.com`. Chaque intermédiaire privé doit porter une extension `nameConstraints` marquée critique, avec des sous-arbres `permitted` cantonnés aux suffixes DNS, plages d'IP, domaines RFC822 et Directory Names sous lesquels la CA est autorisée à émettre. C'est aussi cette extension qui rend la certification croisée sûre — quand la racine d'une organisation signe l'intermédiaire d'une autre organisation, les contraintes de nom bornent le transfert de confiance à un espace de noms spécifique, plutôt que de tendre la main à l'internet entier. Ce contrôle est obligatoire dans plusieurs politiques de Federal PKI et de plus en plus attendu dans les PKI privées matures.
`pathLenConstraint` plafonne le nombre de certificats de CA supplémentaires qui peuvent apparaître entre une CA donnée et n'importe quel certificat d'entité finale. Sur une CA émettrice, cette valeur doit être 0 : la CA peut signer des feuilles, rien d'autre. Sur une CA de politique dans un modèle à trois niveaux, elle doit être 1. Sur une racine dans un modèle à deux niveaux, 0 ou 1 selon que vous souhaitez ou non pouvoir ajouter un étage plus tard. Régler correctement `pathLenConstraint` empêche un intermédiaire compromis, mal émis ou signé de manière croisée par erreur d'être utilisé comme rampe de lancement vers de nouvelles sous-CA. Cela représente deux octets dans le certificat ; c'est la défense en profondeur la moins chère de tout le profil.
Faites correspondre la validité de chaque niveau à sa réalité opérationnelle. Les racines TLS publiques durent 20 à 25 ans et ne sont remplacées que lorsque l'algorithme ou la taille de clé elle-même est dépréciée. Les intermédiaires durent 5 à 10 ans et sont renouvelés sur une cadence planifiée — typiquement avec des CA émettrices qui se chevauchent, de sorte que les nouvelles feuilles proviennent du nouvel intermédiaire pendant que les anciennes feuilles continuent de valider. Les certificats d'entité finale pour le TLS public seront limités à 47 jours à partir de 2029 dans le calendrier adopté par le CA/Browser Forum, ce qui ne fonctionne que si le chemin d'émission est entièrement automatisé — consultez gestion automatisée des certificats et durées de vie de certificat plus courtes pour les conséquences opérationnelles.
Chaque opération sur la racine hors-ligne — génération initiale, signature d'un nouvel intermédiaire, signature d'une CRL, mise au rebut — doit suivre un script de cérémonie écrit, être effectuée en présence d'au moins deux opérateurs et d'un auditeur interne, et exiger un quorum M-sur-N sur les jetons d'authentification du HSM (une configuration typique est 3 cartes à puce parmi 5 détenteurs requises pour autoriser une opération de signature). La cérémonie est filmée, tous les artefacts (CSR, certificat signé, journal d'audit, journal d'activité du HSM) sont hachés et archivés, et l'enregistrement est conservé pour la durée de vie des certificats qui dérivent de l'opération. C'est précisément ce que les audits WebTrust et eIDAS vérifient, et c'est ce qui permet à une organisation de prouver, des années plus tard, qu'un intermédiaire donné a été signé par les bonnes personnes sous la bonne politique.
Hiérarchies multi-niveaux avec contrôle complet des politiques — Evertrust PKI est conçu pour exploiter les hiérarchies à deux et trois niveaux comme un concept de premier ordre, avec des profils de certificat par niveau, des contraintes de nom, le path length, le key usage, et les points de distribution CRL/OCSP tous exprimés sous forme de politique, et non en fichiers de configuration éparpillés sur plusieurs machines. Les CA émettrices sont segmentées par cas d'usage (TLS public, mTLS interne, appareils, signature de code) sous la même racine gouvernée, chacune auditable et révocable indépendamment.
Intégration HSM native à chaque niveau — Les clés des CA racine et émettrices sont générées à l'intérieur d'un HSM certifié FIPS 140-2/140-3 niveau 3 et n'en sortent jamais. Intégration native avec les HSM FIPS 140-2/3 Level 3 des principaux fournisseurs utilisés dans les PKI d'entreprise, ainsi qu'aux KMS cloud lorsque le régime réglementaire le permet, de sorte que la frontière cryptographique se trouve exactement là où l'audit l'attend.
Cérémonies de clés et opérations auditables — Chaque action sur une CA racine ou intermédiaire est journalisée, signée et liée à un opérateur identifié sous contrôles M-sur-N. Les artefacts de cérémonie, les CRL et les événements de révocation sont immuables et exportables, de sorte que les évaluateurs WebTrust, eIDAS, NIS2 et DORA voient un historique complet et inviolable, sans que personne n'ait à reconstituer les preuves à la main au moment de l'audit.