Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
121 lines
6.7 KiB
Markdown
121 lines
6.7 KiB
Markdown
# 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 `idm-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 **universelle** : tout nœud **obtient un certificat** de l'AC (via ACME) et **fait confiance à la racine**. Elle ne se déclare pas — elle est dérivée, et **P26** refuse qu'un hôte y échappe. Seule exemption, dérivée : l'hôte qui *est* l'AC, qui ne s'enrôle pas auprès d'elle-même. | é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
|
|
|
|
1. **Regarde un certificat.** Sur un nœud avec `client_pki` :
|
|
```bash
|
|
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é**.
|
|
2. **Suis la chaîne de confiance.**
|
|
```bash
|
|
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.
|
|
3. **Vois-le servir en vrai.** Le LDAPS d'OpenLDAP utilise ce certificat :
|
|
```bash
|
|
openssl s_client -connect idm-01.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.
|
|
4. **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**.
|
|
```bash
|
|
echo | openssl s_client -connect EDGE:443 -servername keycloak.chezlepro.internal 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.
|
|
|
|
Ce diagnostic est **outillé** depuis le 2026-08-08 : `make certificats-plan` compare, pour
|
|
toute la flotte, ce que le disque porte à ce que la mémoire sert. Il a trouvé quelque chose
|
|
à sa première exécution — sur `infra-pki-01`, **l'autorité elle-même**, le certificat était
|
|
expiré depuis plus de huit heures et le renouvellement échouait toutes les quatorze minutes
|
|
sur `'step ca renew' requires the '--ca-url' flag`. Rien ne le signalait, et le harnais
|
|
était entièrement vert.
|
|
|
|
> **Ne compare pas les empreintes, regarde l'échéance de ce qui est SERVI.** Avec des certs
|
|
> de 24 h renouvelés toutes les ~14 minutes, une empreinte servie *différente* de celle sur
|
|
> disque est l'état **normal** : un contrôle par empreinte crierait en permanence, et on
|
|
> apprendrait à l'ignorer.
|
|
|
|
**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**.
|