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

---

## Pour aller plus loin *(dépôt)*
- Rôles : `roles/serveur_step_ca`, `roles/client_pki`.
- 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**.