verifier / verifier (push) Has been cancelled

Details

documentation : la tournee des 74 documents, parce qu un balayage ne lit pas

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

2026-09-06 16:18:23 -04:00

6.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 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

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 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.

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.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.

6.7 KiB Raw Blame History