Daniel Allaire b6952759f5 Doc à jour : unité wiki Autorisation & RBAC + leçon renouvellement + runbooks

Fermeture des dettes de doc :
- nouvelle unité wiki « Autorisation & RBAC » (authZ, exemple Grafana) ;
- section « le renouvellement est un système » dans l'unité PKI ;
- docs/runbooks-exploitation.md (cert expiré, RBAC Grafana, branding).
15 unités wiki.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-04 17:30:13 -04:00

5.7 KiB

Raw Blame History

PKI & confiance

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Chiffrement asymétrique : une paire de clés — une privée (secrète) et une publique (partageable). Ce que l'une chiffre, l'autre le déchiffre. La privée signe, la publique vérifie.

Un certificat = une clé publique + une identité (« ce serveur est id-ldap-01 »), le tout signé par une autorité. Il répond à : « à qui est-ce que je parle, vraiment ? »

L'autorité de certification (AC / CA) signe les certificats. On lui fait confiance, donc on fait confiance à ce qu'elle signe. Chaîne de confiance : une racine (hors-ligne, précieuse) signe une intermédiaire, qui signe les certificats des serveurs. Faire confiance à la racine = faire confiance à toute la chaîne.

mTLS (TLS mutuel) : les deux parties présentent un certificat — chacune prouve son identité.

ACME : le protocole d'automatisation de l'émission/renouvellement des certificats (popularisé par Let's Encrypt).

② Comment Set-OPS le fait

Pièce	Rôle	Concept incarné
step-ca (`serveur_step_ca`)	l'autorité de certification interne (racine + intermédiaire, base des émissions).	AC, chaîne de confiance
client_pki (`client_pki`)	intégration : un nœud obtient un certificat de l'AC (via ACME) et fait confiance à la racine.	émission ACME, magasin de confiance

Le motif : chaque service qui doit prouver son identité (LDAPS d'OpenLDAP, HTTPS de l'edge…) reçoit un certificat d'hôte signé par step-ca ; la racine est déposée dans le magasin de confiance système de chaque nœud. Résultat : les nœuds se parlent en TLS vérifié, sans avertissement, sans dépendre d'une AC publique. La souveraineté commence par sa propre confiance.

Le Tier 0 des sauvegardes, c'est justement /etc/step-ca (les clés de l'AC) — perdre la racine = tout re-émettre et re-truster. (voir l'unité Sauvegardes.)

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
step-ca (AC interne)	HashiCorp Vault PKI · AD Certificate Services · EJBCA · une AC OpenSSL maison
ACME interne	Let's Encrypt (public) · ZeroSSL · tout serveur ACME
racine dans le magasin système	exactement le même mécanisme que les AC publiques préchargées dans ton OS/navigateur

Tu as appris la PKI, la chaîne de confiance, ACME, mTLS — pas « step-ca ». Ça vaut pour Let's Encrypt, Vault, une AC d'entreprise : le schéma est identique.

④ À toi de jouer

Regarde un certificat. Sur un nœud avec client_pki :
```
openssl x509 -in /etc/step/certs/$(hostname -f).crt -noout -subject -issuer -dates
```
Repère le sujet (l'identité), l'émetteur (l'intermédiaire) et la validité.
Suis la chaîne de confiance.
```
openssl verify -CAfile /etc/step/certs/root_ca.crt /etc/step/certs/$(hostname -f).crt
```
OK = la racine valide bien le certificat du serveur. C'est ① en action.

Vois-le servir en vrai. Le LDAPS d'OpenLDAP utilise ce certificat :

openssl s_client -connect id-ldap-01.lab.chezlepro.internal:636 \
  -CAfile /etc/step/certs/root_ca.crt </dev/null 2>/dev/null | grep -E 'Verify return code'

0 (ok) = confiance vérifiée.

Casse & répare. Retire la racine du magasin système, refais un curl HTTPS interne : avertissement de certificat (plus de confiance). Réinstalle la racine : ça remarche. Tu viens de sentir pourquoi « faire confiance à la racine » est la clé de voûte.

⑤ Le renouvellement : un système à part entière (leçon d'exploitation vécue)

Un certificat expire. Les certs internes de Set-OPS (step-ca) sont courts (~24 h) — c'est plus sûr (une clé volée ne vaut pas longtemps), mais ça exige un renouvellement automatique fiable. Et attention à un piège vécu en vrai :

Renouveler le fichier ne suffit pas — il faut recharger le consommateur. Un service (nginx, postfix, dovecot, slapd) charge son cert en mémoire au démarrage. Si le renouvellement réécrit le fichier mais ne recharge pas le service, celui-ci sert l'ancien cert périmé alors que le fichier sur disque est frais. Symptôme trompeur : openssl x509 -in fichier dit « valide », mais le service sert un cert expiré.

Diagnostic-réflexe : comparer le cert servi au cert fichier.

echo | openssl s_client -connect EDGE:443 -servername keycloak.lab… 2>/dev/null | openssl x509 -noout -enddate  # SERVI
openssl x509 -in /etc/step/certs/EDGE.crt -noout -enddate                                                        # FICHIER

Dans Set-OPS, client_pki_reload_services (par nœud) fait recharger les vrais consommateurs après chaque renouvellement — edge→nginx, mail→postfix/dovecot, annuaire→slapd. Fix d'urgence si ça arrive : systemctl reload nginx sur l'edge.

Casse & répare : sur l'edge, arrête le timer cert-renewer@…, laisse le cert expirer (ou force une horloge), observe le login SSO casser (échec TLS de l'échange OIDC), puis recharge nginx → tout revient. Tu sens que la PKI ne vit que si le renouvellement et le rechargement tournent.

Pour aller plus loin (dépôt)

Rôles : roles/serveur_step_ca, roles/client_pki (client_pki_reload_services).
Le motif « pont de certificat » (renouvellement automatique) : voir les tâches *-cert-sync des rôles (Dovecot, Postfix, nginx…).
Tier 0 des sauvegardes (/etc/step-ca) : unité Sauvegardes.

5.7 KiB Raw Blame History