Set-OPS-Public/wiki/PKI-et-confiance.md

# 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

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