Déroulement complet, du premier octet au dernier, de la fabrication d’un certificat jusqu’à une connexion TLS réelle — le fil conducteur qui relie Chiffrement symétrique vs asymétrique, Diffie-Hellman — Échange de clés, Certificats — Vue d’ensemble et TLS et SSL.
La structure d’un certificat — 3 blocs
Base de tout ce qui suit : un certificat (cert.pem) est un fichier binaire structuré en 3 blocs.
cert.pem contient :
┌─────────────────────────────────────────────┐
│ BLOC 1 — TBSCertificate ("To Be Signed") │ ← c'est CE bloc qui est haché
│ Subject : monentreprise.fr │
│ Issuer : Let's Encrypt R11 │
│ Validity : dates │
│ Clé publique du site │
│ Extensions (SAN, KeyUsage...) │
├─────────────────────────────────────────────┤
│ BLOC 2 — Signature Algorithm │
│ sha256WithRSAEncryption │
├─────────────────────────────────────────────┤
│ BLOC 3 — Signature Value │ ← LA SIGNATURE elle-même,
│ 30:82:4f:1e:9a:... (des centaines d'octets)│ ajoutée APRÈS coup
└─────────────────────────────────────────────┘
- Bloc 1 : le contenu — ce qu’on vérifie.
- Bloc 2 : déclare l’algorithme utilisé (ex. SHA256 + RSA) — indique comment vérifier (sans lui, impossible de savoir quelle fonction de hash/signature rejouer). Apparaît aussi une deuxième fois à l’intérieur du Bloc 1 lui-même ; les deux déclarations doivent correspondre, sinon rejet (protection contre la confusion d’algorithme).
- Bloc 3 : le résultat — une signature de plusieurs centaines d’octets (donc jamais directement comparable à un hash de 32 octets), obtenue en signant le hash du Bloc 1, jamais le Bloc 1 en entier.
PHASE 1 — Fabrication du certificat (une fois, avant toute connexion)
1. Génération de la clé du site — site.key (privée, ne quitte jamais le serveur) / clé publique correspondante.
2. Création du CSR — le site construit son propre Bloc 1 (son identité + sa clé publique), le hash, et signe ce hash avec SA clé privée :
Bloc 3 du CSR = signature(hash(Bloc 1 du CSR), clé_privée_DU_SITE)
→ Prouve à la CA que le demandeur possède bien la clé privée correspondant à la clé publique proposée. Sans cette signature, n’importe qui pourrait proposer la clé publique de quelqu’un d’autre.
3. Envoi à la CA (Let’s Encrypt), via ACME — cet échange se fait lui-même sur une connexion TLS classique, sécurisée par le certificat de Let’s Encrypt, déjà valide et pré-approuvé — une couche facile à oublier : même la fabrication d’un certificat passe par une session HTTPS.
4. Validation du domaine — challenge HTTP-01/DNS-01/TLS-ALPN-01 : prouve que le demandeur contrôle réellement le domaine demandé.
5. La CA signe le certificat final — elle construit le Bloc 1 du certificat (identité + clé publique du site + dates de validité), le hash, et signe ce hash avec SA clé privée à elle :
Bloc 3 du certificat = signature(hash(Bloc 1 du certificat), clé_privée_DE_LA_CA)
→ Ne jamais confondre : le CSR est signé par le site (étape 2), le certificat final est signé par la CA (étape 5) — deux paires de clés différentes.
6. Déploiement — fullchain.pem (certificat du site + certificat de la CA intermédiaire, concaténés) + site.key installés sur le serveur, et référencés dans sa config :
ssl_certificate /etc/ssl/fullchain.pem; # PUBLIC : ce qu'on ENVOIE aux visiteurs
ssl_certificate_key /etc/ssl/site.key; # PRIVÉ : reste sur ce serveur, ne part jamaisAu démarrage, le serveur charge les deux fichiers en mémoire et vérifie que la clé publique du certificat correspond bien mathématiquement à site.key (vérification “modulus” — sinon il refuse de démarrer). Il les garde ensuite prêts pour chaque future connexion : fullchain.pem est envoyé tel quel comme Certificate (étape 11), et site.key sert à produire CertificateVerify (étape 11 aussi) — c’est cette étape de déploiement qui alimente concrètement toute la Phase 2.
À ce stade, le site est prêt — aucune communication n’a encore eu lieu avec un visiteur.
PHASE 2 — Une connexion réelle (Alice se connecte)
7-8. DNS puis connexion TCP vers l’IP du serveur, port 443.
9. ClientHello (en clair) — Alice envoie son key_share : sa clé publique Diffie-Hellman éphémère, nouvelle pour cette connexion, jamais réutilisée.
10. ServerHello (en clair, dernier message non chiffré) — le serveur répond avec son propre key_share DH éphémère.
→ Les deux calculent, chacun de son côté, le même secret partagé — jamais transmis directement (voir l’analogie du mélange de peinture dans Diffie-Hellman — Échange de clés) — dont dérive une clé symétrique AES-256-GCM. À partir d’ici, tout le reste du handshake est déjà chiffré.
11. Le serveur envoie (chiffré avec la clé issue du DH) :
Certificate— lefullchain.pemcompletCertificateVerify— hash de tout le transcript de cette connexion précise (ClientHello, ServerHello, Certificate), signé avec la clé privée du site (pas la clé DH éphémère, pas celle de la CA)Finished
12. Alice vérifie la chaîne de certificats — pour chaque certificat reçu : recalcule le hash de son Bloc 1, le compare à ce qu’elle extrait du Bloc 3 en déchiffrant avec la clé publique de l’émetteur (correspondance Subject/Issuer, de certificat en certificat, jusqu’à la racine déjà présente dans son trust store — jamais envoyée sur le réseau).
13. Alice vérifie CertificateVerify — recalcule elle-même le hash du transcript, le compare à ce qu’elle extrait en déchiffrant avec la clé publique du site (trouvée dans le certificat, pas celle de la CA cette fois) → prouve que le serveur possède réellement la clé privée maintenant, pas seulement qu’il a montré un certificat public (qu’un attaquant aurait pu copier/rejouer).
14. Alice vérifie le domaine — le Subject/SAN du certificat correspond-il au domaine demandé ? Simple comparaison de texte, aucune clé impliquée — une opération séparée de la vérification de signature (étape 12).
15. Finished côté client (chiffré) → handshake terminé, 1 seul aller-retour (1-RTT, TLS 1.3).
16. Données chiffrées — tout le trafic HTTP réel, avec la clé symétrique issue du secret Diffie-Hellman — jamais avec les clés du certificat, qui n’ont servi qu’à authentifier (étapes 12-13), pas à chiffrer la session.
Les 3 paires de clés à ne jamais confondre
| Paire de clés | Qui signe/utilise la privée | Qui vérifie avec la publique | Où |
|---|---|---|---|
| Clé du site | Le site (CSR, CertificateVerify) | La CA (CSR) / Alice (CertificateVerify) | Étapes 2, 11, 13 |
| Clé de la CA | La CA (signature du certificat) | Alice (chaîne de confiance) | Étapes 5, 12 |
| Clé DH éphémère | — (pas de signature, juste un échange public) | — | Étapes 9-10 ; dérive la clé qui chiffre les données (étape 16) |
Le renouvellement (tous les 90 jours chez Let’s Encrypt)
Tout le processus de la Phase 1 est rejoué depuis le début — nouveau CSR, nouveau challenge, nouvelle signature de la CA. Le Bloc 1 du nouveau certificat a au minimum de nouvelles dates de validité (souvent aussi une nouvelle clé publique) → hash différent → Bloc 3 nécessairement différent, même processus, même CA. Voir Cycle de vie et révocation.
En relation avec
- Chiffrement symétrique vs asymétrique — pourquoi le handshake est asymétrique et la session symétrique
- Diffie-Hellman — Échange de clés — le détail de l’échange de clé (étapes 9-10)
- Certificats — Vue d’ensemble / X.509 — Format des certificats — structure complète, extensions
- Comprendre les certificats — Exemple détaillé — la mécanique signature/vérification en détail
- PKI — Infrastructure à Clés Publiques — hiérarchie de confiance, trust store
- Let’s Encrypt et ACME — le détail de la Phase 1 (CSR, challenge, émission)
- Cycle de vie et révocation — renouvellement, révocation
- TLS et SSL — handshake complet, cipher suites, mTLS
- Parcours complet — Du certificat à la connexion mTLS — la même mécanique, avec authentification mutuelle