History

Daniel Allaire 1bd211d62b resolution_interne : entre machines du site, chaque nom mene a son service L edge expose les interfaces web aux personnes ; les VM du site vont directement au service. Declare par domaine (service \| edge, defaut edge) ; plancher, zone et certificat du service suivent. Pose au site : 35 planchers sur 35 conformes ; locataires inchanges. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>		2026-09-29 13:25:37 -04:00
..
defaults	resolution_interne : entre machines du site, chaque nom mene a son service	2026-09-29 13:25:37 -04:00
handlers	deploiement : deux attentes de premier demarrage, et trois defauts leves	2026-08-07 09:30:48 -04:00
meta	supervision : la sonde se declare dans le role, comme le flux	2026-09-09 21:45:49 -04:00
tasks	depot de binaires : le site tient ce que les runners allaient chercher	2026-09-12 23:45:00 -04:00
templates	supervision : la sonde se declare dans le role, comme le flux	2026-09-09 21:45:49 -04:00
README.md	client_pki : l'empreinte du root CA n'est pas un secret de voûte	2026-08-01 22:37:27 -04:00

README.md

client_pki

Intégration cliente PKI / identité machine : chaque hôte fait confiance à l'AC interne (serveur_step_ca), obtient son propre certificat et le renouvelle automatiquement.

Rôle

Installe step-cli (dépôt apt Smallstep).
Confiance : step ca bootstrap --install → installe la racine de l'AC dans le magasin de confiance système (l'hôte fait confiance au TLS interne réel).
Certificat d'hôte : step ca certificate <fqdn> via le provisioner.
Renouvellement automatique : unités systemd officielles cert-renewer@.{service,timer} (vérifie/renouvelle toutes les 15 min, recharge le service consommateur s'il existe).

« Chaque hôte authentifiable »

Après ce rôle, l'hôte possède une identité machine vérifiable : un certificat émis par l'AC interne, renouvelé sans intervention. Les services peuvent l'utiliser pour du TLS / mTLS interne.

Secrets requis (Vault)

client_pki_provisioner_password: "{{ vault_step_ca_provisioner_password }}"  # partage avec serveur_step_ca

Un seul — et l'empreinte racine n'en fait pas partie.

L'empreinte du root CA n'est pas un intrant

Elle est dérivée à chaud depuis l'autorité (step certificate fingerprint exécuté sur serveur_step_ca, en delegate_to), et non lue depuis la voûte. La raison : un from-zero régénère l'AC, donc son empreinte change. Une empreinte figée en voûte serait périmée dès la première reconstruction — et une empreinte périmée fait échouer le bootstrap de chaque hôte, sans que rien n'indique pourquoi.

Si l'AC est injoignable ou pas encore déployée, un assert échoue avec un message clair plutôt que de laisser passer une empreinte vide — ce qui reviendrait à faire confiance à n'importe quelle autorité au premier contact.

Pour épingler explicitement une empreinte (AC externe, migration) : client_pki_ca_fingerprint_override.

Variables principales

Variable	Défaut	Rôle
`client_pki_ca_url`	`https://infra-pki-01.exemple.internal:8443`	URL de l'AC
`client_pki_provisioner`	`admin@exemple.internal`	Provisioner émetteur
`client_pki_nom_cert`	FQDN de l'hôte	Nom du certificat

Notes / sécurité

Émission via le provisioner JWK (mot de passe partagé) : tout hôte avec ce secret peut émettre des certificats. Acceptable en interne ; pour durcir, basculer vers ACME ou des jetons à usage unique par hôte (phase ultérieure).
Pour qu'un service (nginx, keycloak…) recharge automatiquement après renouvellement, nommer son certificat d'après le service (instance cert-renewer@<service>).

Prérequis

Dépendance client_pki requiert serveur_step_ca actif (déjà dans docs/dependances-groupes.yml).
Réseau vers l'AC (:8443).