Chapitre 17. PKI : les certificats industrialisés
Objectifs pédagogiques¶
Justifier une PKI interne et son architecture à deux niveaux. Construire une chaîne en évitant le piège des plafonds. Écrire un rôle d'émission contraint. Émettre par génération ou par demande de signature. Révoquer, publier une liste de révocation, et énoncer pourquoi les durées courtes sont la vraie réponse. Exploiter le moteur dans la durée. Situer le multi-issuer et ACME.
Prérequis¶
Chapitre 7 (le certificat de laboratoire, que ce chapitre remplace), chapitre 14 (les plafonds de montage, où le piège s'est préparé), chapitre 2 (durées courtes et révocation).
Cours¶
17.1 Pourquoi une PKI interne¶
Un certificat est un secret à cycle de vie complet : une clé privée qui authentifie, une durée, un renouvellement, une révocation. Tout le chapitre 1, au format X.509.
L'état des lieux d'Astrea en a montré la gestion par défaut : un wildcard acheté une fois, posé sur un partage réseau, copié sur neuf services. Un seul secret partagé par tout le parc, valable des années, dont la compromission d'un seul serveur compromet l'identité de tous. Et le certificat auto-signé du chapitre 7 ne passe pas l'échelle.
La PKI interne renverse le modèle comme Transit l'a fait pour les clés : une autorité que le parc connaît une fois pour toutes, des certificats émis à la demande, nominatifs, courts et tracés, une émission gouvernée par les policies et l'audit. Le moteur pki est un moteur de secrets dont le secret est un certificat : tout ce que le chapitre 14 a posé s'y applique, à commencer par les plafonds de durée.
17.2 L'architecture à deux niveaux¶
La forme canonique sépare deux autorités.
La racine signe une seule chose, l'intermédiaire. Elle est longue, dix ans, et sa clé privée est le trésor de la construction : c'est elle que tous les magasins de confiance du parc contiennent, et la faire changer, c'est toucher chaque client.
L'intermédiaire signe les certificats feuilles au quotidien. Elle est moyenne, cinq ans, et sacrifiable : compromise, la racine la révoque et en signe une autre, sans que les clients aient rien à redéployer.
Les feuilles sont courtes, soixante-douze heures dans le fil rouge, pour la raison qu'établira la section 17.6.
Cette hiérarchie est la défense en profondeur appliquée à la confiance : l'objet le plus exposé n'est pas l'objet le plus précieux, et la distance entre les deux est une révocation, pas une migration de parc.
Le choix d'implémentation se documente. Les organisations les plus exigeantes gardent la racine hors ligne, générée sur une machine isolée, sortie pour signer l'intermédiaire, remisée. Astrea fait le choix inverse et l'écrit : la racine vit dans Vault, sur un montage dédié dont les policies interdisent tout sauf la signature d'intermédiaire sous procédure. La protection est celle de Vault lui-même, et le critère de révision est consigné : croissance, ou exigence de conformité.
17.3 Construire la chaîne¶
[Laboratoire]. La racine d'abord, et la leçon du chapitre 14 avant elle.
vault secrets enable -path=pki-root pki
# LE geste qui evite le piege : sans lui, la racine "dix ans"
# serait ecretee en silence au plafond par defaut de 32 jours
vault secrets tune -max-lease-ttl=87600h pki-root
vault write -field=certificate pki-root/root/generate/internal \
common_name="Astrea Root CA" \
key_type=ec key_bits=384 \
ttl=87600h > astrea-root-ca.crt
vault write pki-root/config/urls \
issuing_certificates="https://vault.astrea.lab:8200/v1/pki-root/ca" \
crl_distribution_points="https://vault.astrea.lab:8200/v1/pki-root/crl"
Trois choix commentés. Le mode internal : la clé privée est générée et jamais renvoyée, donc non exportable par construction ; le mode exported existe pour l'interopérabilité et relève du régime d'exception de la section 16.7. Le fichier récupéré est le certificat de la racine, public, seul objet à distribuer, une fois. Et les URL s'inscrivent dans chaque certificat émis : elles doivent être stables à l'échelle de la durée des certificats, d'où le nom de service et non celui du mono-nœud d'aujourd'hui.
L'intermédiaire ensuite, en trois temps puisqu'elle est signée par la racine.
vault secrets enable -path=pki-int pki
vault secrets tune -max-lease-ttl=43800h pki-int
# 1. pki-int genere sa cle (interne) et une demande de signature
vault write -format=json pki-int/intermediate/generate/internal \
common_name="Astrea Intermediate CA" key_type=ec key_bits=256 \
| jq -r '.data.csr' > pki-int.csr
# 2. la racine signe la demande -- le seul acte de sa vie courante
vault write -format=json pki-root/root/sign-intermediate \
csr=@pki-int.csr format=pem_bundle ttl=43800h \
| jq -r '.data.certificate' > pki-int.crt
# 3. pki-int recoit son certificat signe
vault write pki-int/intermediate/set-signed certificate=@pki-int.crt
vault write pki-int/config/urls \
issuing_certificates="https://vault.astrea.lab:8200/v1/pki-int/ca" \
crl_distribution_points="https://vault.astrea.lab:8200/v1/pki-int/crl"
Le détail qui compte : la clé privée de l'intermédiaire n'a jamais quitté son montage. Seule la demande de signature, publique, a voyagé, et le certificat signé, public, en est revenu.
17.4 Le rôle : la politique d'émission¶
Le rôle traduit une population en contrat : ici, ce que les certificats d'un usage ont le droit d'être.
vault write pki-int/roles/astrea-services \
allowed_domains="astrea.lab" \
allow_subdomains=true \
allow_bare_domains=false \
allow_wildcard_certificates=false \
allow_ip_sans=true \
key_type=ec key_bits=256 \
ttl=72h max_ttl=720h
Chaque ligne est une décision. Les domaines autorisés et les sous-domaines bornent l'émission à astrea.lab : une demande pour un domaine extérieur est refusée par construction, quels que soient les droits du demandeur. Le domaine nu est interdit, aucun service ne le portant. Le wildcard est interdit : c'est la ligne qui solde le constat 5, et le contrôle n'est pas une consigne d'équipe mais une propriété du système. Les durées, trois jours par défaut et un mois au plafond, s'inscrivent dans l'encadrement du montage.
La conséquence de policies est celle du chapitre 10 : un rôle par usage, et le droit d'émettre s'écrit chemin par rôle.
17.5 Émettre : deux voies, une différence d'exposition¶
La voie issue, où Vault génère tout.
vault write pki-int/issue/astrea-services \
common_name="billing.astrea.lab" \
alt_names="app-billing-01.astrea.lab" \
ttl=72h
La réponse contient le certificat, la chaîne, le numéro de série, et la clé privée, générée pour l'occasion et renvoyée une seule fois. Vault ne la stocke pas : il conserve le certificat, jamais les clés privées émises. Le demandeur la range immédiatement, permissions strictes, et tout le chapitre 1 s'applique à elle dès cette seconde. La voie est simple et outillable, au prix d'un transit de la clé par la réponse.
La voie sign, où le demandeur génère sa clé et n'envoie qu'une demande de signature. La clé privée n'a jamais existé hors du service demandeur. C'est le motif de l'intermédiaire, disponible pour toute feuille, préférable dès que l'outillage du demandeur sait produire une demande.
Le choix est un choix d'exposition, et il se fait par population : la génération pour les services provisionnés par un déploiement de confiance, la demande de signature pour tout ce qui sait la produire.
17.6 Révoquer, et la vérité sur la révocation¶
La révocation existe et se pratique.
vault write pki-int/revoke serial_number="39:dd:2e..."
curl -s "https://vault.astrea.lab:8200/v1/pki-int/crl/pem"
Le certificat rejoint la liste de révocation, signée par l'intermédiaire et publiée à l'URL inscrite dans chaque certificat. Les versions récentes ajoutent un répondeur OCSP intégré, pour la vérification unitaire en ligne.
Voici maintenant la vérité que tout architecte doit savoir énoncer : la révocation X.509 est le maillon faible historique du modèle. Une liste ne protège que les clients qui la téléchargent, et beaucoup ne le font pas ou la mettent en cache au-delà du raisonnable. OCSP ne protège que les clients qui interrogent, et la plupart, face à un répondeur injoignable, choisissent la disponibilité et acceptent. Révoquer, c'est publier une information que le monde est libre d'ignorer.
La conséquence n'est pas d'abandonner la révocation, qui reste nécessaire pour les clients rigoureux et les exigences de conformité. C'est de ne pas lui confier le rôle principal : la vraie défense est la durée courte. Un certificat de soixante-douze heures compromis meurt seul en trois jours, pour tous les clients, y compris ceux qui ne vérifient rien. C'est le principe 2.4 dans sa forme la plus pure, et la justification définitive du rôle. Les durées courtes coûtent un renouvellement industrialisé, que la section 17.8 et le chapitre 40 fournissent.
17.7 Exploiter dans la durée¶
Deux réalités d'exploitation, à installer dès le premier jour.
Le stockage grossit. Le moteur conserve chaque certificat émis, ce qui rend la révocation et l'inventaire possibles, et des feuilles de trois jours renouvelées sans fin s'accumulent.
[Production]
L'opération purge les certificats expirés au-delà de la marge. Les versions récentes savent la programmer, ce qui vaut mieux que de la retenir. Pour les très hauts volumes, un paramètre de rôle renonce au stockage des feuilles, et donc à leur révocation et à leur inventaire : arbitrage explicite, cohérent seulement avec des durées très courtes.
Le renouvellement n'existe pas. Un certificat ne se prolonge pas, il se réémet : même rôle, même nom, nouvelle clé de préférence. À soixante-douze heures, la réémission est un processus automatique ou n'est pas.
17.8 Multi-issuer et ACME¶
Deux capacités récentes ferment le chapitre.
Note de version : depuis la version 1.11, un montage PKI héberge plusieurs émetteurs, avec un émetteur par défaut et des références explicites. La conséquence pratique est la rotation sans interruption des autorités : la nouvelle intermédiaire s'installe à côté de l'ancienne, les émissions basculent, l'ancienne continue de servir sa liste de révocation jusqu'à extinction des feuilles qu'elle a signées. Le problème « comment changer d'autorité sans jour J » a une réponse native pour les intermédiaires. Pour la racine, la technique s'appelle le cross-signing : la nouvelle racine se fait signer par l'ancienne, de sorte que les parcs qui ne connaissent encore que celle-ci valident déjà les certificats de celle-là. C'est le seul moyen de changer d'ancre de confiance sans redéployer simultanément tous les magasins, et c'est ce qui rend une racine remplaçable au lieu d'éternelle.
Note de version : depuis la version 1.14, un montage PKI sait parler ACME, le protocole standard d'obtention automatique de certificats. Les clients de l'écosystème peuvent demander et renouveler leurs certificats auprès de Vault sans rien connaître de Vault, ni token ni CLI : la validation de contrôle du nom tient lieu de preuve, dans le périmètre du rôle. C'est l'industrialisation naturelle des durées courtes, et un déplacement de confiance à noter au modèle : la preuve devient la maîtrise du nom, avec la rigueur DNS que cela suppose.
Exemple : la mort du wildcard¶
Le chantier qui solde le constat 5, tel que consigné.
L'inventaire. Neuf services derrière le wildcard, et la clé présente sur onze machines, deux de plus que prévu, dont un poste de développeur. Le constat vaut leçon.
La bascule, service par service. Émission d'un certificat nominatif de soixante-douze heures, par génération pour les services déployés par la CI, par demande de signature pour les deux qui savent en produire. Installation du certificat racine dans les magasins de confiance du parc, une fois. Minuteur de réémission à quarante-huit heures en attendant l'agent du chapitre 40. Billing passe en premier, et son certificat de laboratoire part avec le wildcard.
La clôture. Le wildcard est révoqué chez son émetteur public, ses copies effacées des onze machines. Et le geste qui change la nature du contrôle : le rôle interdit les wildcards, donc en demander un échoue, pour tout le monde, y compris les administrateurs pressés d'un futur incident. L'audit ferme la boucle : chaque émission est une ligne nominative, et la question du chapitre 1, « qui a ce certificat », a désormais une réponse qui se recherche.
Reste une dette assumée et datée : vault-core-01 sert encore son certificat de laboratoire. Il basculera au chapitre 28, quand l'architecture cible mettra le répartiteur en place.
Architecture : la chaîne d'Astrea¶
[ magasins de confiance du parc : astrea-root-ca.crt ]
|
pki-root (montage dedie, plafond 10 ans)
"Astrea Root CA" -- cle interne, jamais sortie
| signe une seule chose :
v
pki-int (montage dedie, plafond 5 ans)
"Astrea Intermediate CA" -- cle interne
| role astrea-services : sous-domaines de astrea.lab,
| wildcard INTERDIT, feuilles 72 h
v
billing.astrea.lab vault.astrea.lab monitor.astrea.lab ...
(issue ou sign/CSR -- cles privees chez les services, jamais dans Vault)
CRL : /v1/pki-root/crl et /v1/pki-int/crl (URLs inscrites dans les certificats)
Sécurité : l'autorité comme actif suprême¶
La racine ne fait qu'une chose. Aucun rôle d'émission sur son montage, aucune feuille jamais. La signature d'intermédiaire est un acte rare, sous procédure, alarmé dans l'audit. Une racine qui émet au quotidien est exposée au quotidien, et sa compromission se paie en redéploiement de tout le parc.
Les rôles sont le périmètre. Domaines autorisés, interdictions de wildcard et de domaine nu, durées : tout ce qu'un rôle permet, un demandeur autorisé l'obtiendra. L'écriture des rôles rejoint les chemins de pouvoir du chapitre 11.
Les clés privées des feuilles vivent chez les services. Vault ne les stocke pas ; leur protection relève du chapitre 1 côté demandeur, et la voie par demande de signature évite même leur transit.
Les durées courtes sont la politique, la révocation le complément. Le modèle de menace ne repose jamais sur « les clients vérifieront la liste », mais sur « le certificat meurt dans trois jours ». Tout allongement de durée de rôle est une décision de sécurité, pas de confort.
Erreurs fréquentes¶
La racine écrêtée à trente-deux jours. Le grand classique, préparé au chapitre 14 : plafond oublié, génération dix ans, certificat servi pour 768 heures, en silence (section 17.3).
Émettre les feuilles depuis la racine. L'ancre de confiance exposée au trafic quotidien, sans autorité sacrifiable entre elle et le monde (section 17.2).
Des URL absentes ou instables. Chaînes incomplètes côté clients, listes de révocation introuvables, et des certificats à réémettre si l'URL change (section 17.3).
Rouvrir le wildcard pour dépanner. Une autorisation temporaire qui reste, et le constat 5 recréé avec la bénédiction de la PKI. On crée un rôle d'exception documenté, on ne détricote pas le rôle général (section 17.4).
Des durées de feuilles longues pour éviter le renouvellement. Un an de validité, c'est un an d'exposition que la révocation ne rattrapera pas. La réponse au coût du renouvellement est l'automatisation (sections 17.6 à 17.8).
Pas d'entretien du stockage. Des dizaines de milliers de feuilles expirées, des snapshots qui enflent, des listes qui rament (section 17.7).
Confondre révocation et disparition. Révoqué n'est inoffensif que chez les clients qui vérifient (section 17.6).
Mise en pratique : concevoir, tourner, diagnostiquer¶
Sur papier ; réponses commentées en fin de partie.
- L'équipe monitoring veut des certificats clients pour authentifier ses sondes en TLS mutuel. Rédigez le rôle
astrea-probescomplet et dites en quoi il diffère d'astrea-services. - L'intermédiaire approche de mi-vie. Déroulez dans l'ordre la rotation sans interruption permise par le multi-issuer, de la génération de la nouvelle autorité à l'extinction de l'ancienne.
- Un service refuse de démarrer : les clients signalent une autorité inconnue, alors que le certificat vient bien du bon rôle. Donnez les trois causes les plus probables, dans l'ordre où vous les vérifieriez, et le geste de diagnostic de chacune.
Questions de compréhension¶
- En quoi un certificat est-il un secret à cycle de vie complet, et qu'est-ce que le wildcard violait exactement ?
- Justifiez l'architecture à deux niveaux, et ce que « sacrifiable » veut dire pour l'intermédiaire.
- Pourquoi le réglage du plafond précède-t-il la génération de la racine, que se passe-t-il sinon, et pourquoi en silence ?
- Que garantit le mode
internal, et pourquoi les URL doivent-elles être stables ? - Détaillez le rôle
astrea-servicesligne à ligne : quelle décision chaque paramètre encode-t-il ? - Comparez les deux voies d'émission : ce qui transite, ce que Vault stocke, la règle de choix.
- Énoncez la vérité sur la révocation, les limites des deux mécanismes, et la conclusion d'architecture.
- Que fait l'entretien du stockage, pourquoi est-il nécessaire, et quel arbitrage représente le renoncement au stockage ?
- Que permettent le multi-issuer et ACME, avec leurs versions, et quel déplacement de confiance ce dernier introduit-il ?
Synthèse¶
La PKI de Vault fait des certificats ce que Transit a fait des clés : un service. Une chaîne à deux niveaux, la racine ne signant que l'intermédiaire et l'intermédiaire sacrifiable signant le quotidien, construite en évitant l'écrêtage silencieux des plafonds. Des rôles qui sont la politique d'émission : domaines bornés, wildcard interdit par construction, feuilles à soixante-douze heures. Deux voies d'émission, dont l'une ne fait jamais voyager la clé privée que Vault ne stocke de toute façon pas. Une révocation pratiquée sans être crue, listes et OCSP pour qui vérifie, durées courtes pour tout le monde. Et une exploitation qui assume ses réalités : entretien programmé, réémission automatisée, multi-issuer pour tourner les autorités sans jour J, ACME pour servir le parc en protocole standard. Astrea a enterré son wildcard, et le contrôle est structurel. Déclenche le TP 7 (énoncé en partie XV).