Clés, certificats et autorités

Objectifs

À la fin de cette leçon, vous saurez :

• expliquer la cryptographie asymétrique sans formule — et pourquoi elle résout le partage de secret ;
• décrire le contenu d'un certificat et la chaîne de confiance qui l'entoure ;
• suivre les cinq gestes du handshake TLS et expliquer pourquoi tout circule ensuite en symétrique.

🔗 Pour vous rafraîchir la mémoire : ce que HTTPS protège

Le problème du secret partagé

La cryptographie symétrique (une seule clé sert à chiffrer ET déchiffrer, ex. AES) est rapide et éprouvée. Mais elle pose une question apparemment insoluble :

Comment vous et le serveur allez-vous posséder LA MÊME clé secrète... sans jamais l'avoir transmise sur le réseau que vous cherchez justement à sécuriser ?

Envoyer la clé en clair = la donner à l'espion. La transporter par un autre canal ? Impraticable à l'échelle du web. Il fallait une idée neuve — c'est la cryptographie asymétrique.

Asymétrique : deux clés pour un coffre

Chaque partie génère un COUPLE de clés mathématiquement liées :

clé PUBLIQUE   → chiffre      (distribuée à tous, collée au domaine)
clé PRIVÉE     → déchiffre    (ne quitte JAMAIS le serveur)

Propriété fondamentale : ce que chiffre l'une ne peut être déchiffré QUE par l'autre. L'image du coffre à fente : n'importe qui peut y glisser une lettre par la fente publique ; seul le détenteur de la clé privée peut ouvrir le coffre.

Deux usages découlent de cette propriété :

Usage	Mécanisme	Garantit
Chiffrer vers quelqu'un	avec SA clé publique	seul lui peut lire
Signer	avec SA clé privée	tout le monde peut vérifier avec la publique → preuve d'identité

Le second usage est celui qui nous intéresse pour les certificats : signer prouve « c'est bien moi », car personne d'autre ne possède la privée capable de produire cette signature vérifiable.

Le certificat : une carte d'identité signée par un tiers de confiance

Reste une faille : comment être sûr qu'une clé publique trouvée sur le réseau appartient VRAIMENT à exemple.fr et non à un imposteur ? Un imposteur pourrait publier SA clé publique en se réclamant du domaine !

La solution : un certificat — un document qui associe le nom de domaine à la clé publique, le tout signé par une autorité de certification (AC) :

Certificat exemple.fr
├── sujet        : exemple.fr                    ← pour QUI
├── émetteur     : Let's Encrypt                 ← signé PAR QUI
├── validité     : du 01/01/2026 au 31/03/2026   ← jusqu'à QUAND
└── clé publique : -----BEGIN PUBLIC KEY-----    ← LA clé certifiée

Votre système (navigateur + OS) embarque d'avance la liste des AC légitimes avec leurs clés publiques racines. À la visite d'un site, il vérifie :

1. la signature du certificat provient d'une AC connue ;
2. le nom dans le certificat correspond AU DOMAINE visité ;
3. les dates sont valides ;
4. la chaîne remonte jusqu'à une racine intégrée (le certificat du site est souvent signé par une AC intermédiaire, elle-même signée par une racine).

C'est la chaîne de confiance, et elle mérite réflexion : je ne fais pas confiance à exemple.fr par magie ; je fais confiance aux AC préinstallées chez moi, qui ont vérifié — au moment de l'émission — que le demandeur contrôlait réellement le domaine (défi DNS ou fichier déposé sur le serveur). La confiance se transporte, elle ne s'invente pas.

Conséquence pratique : obtenir un certificat pour un domaine dont on n'est pas maître est impossible SANS compromettre une AC (rarissime, immédiatement traité par révocation). C'est ce qui rend l'usurpation HTTPS si coûteuse pour un attaquant.

Le handshake TLS en cinq gestes

L'établissement d'une session TLS (handshake) assemblé avec tout ce qui précède :

1. ClientHello     « bonjour, voici mes versions/capacités, un nombre aléatoire »
2. ServerHello     « d'accord, même accord » + CERTIFICAT (carte d'identité signée)
3. Vérification    le client contrôle : chaîne de confiance ✓ domaine ✓ dates ✓
4. Échange de clés les deux côtés calculent UNE CLÉ SYMÉTRIQUE DE SESSION,
                   chacun avec son secret — sans jamais la transmettre
5. Session         tout HTTP circule désormais chiffré avec cette clé

Détail élégant à retenir : l'asymétrique sert uniquement à l'ouverture (authentifier le serveur, amorcer l'accord), puis TOUT circule en symétrique. Pourquoi ce mélange ? L'asymétrique est des centaines de fois plus lent que le symétrique ; chiffrer chaque page web en RSA serait ruineux. La session TLS combine donc le meilleur des deux : l'asymétrique résout LE problème initial (se mettre d'accord sans échange préalable de secret), le symétrique fait ensuite le gros du travail rapidement. Chaque nouvelle connexion refait ce handshake — d'où les lignes TLS 1.3 connection observées dans vos sorties curl.

Exercice

1. Pourquoi la clé privée ne doit-elle JAMAIS quitter le serveur ? Que se passe-t-il en cas de fuite ?
2. Que vérifie exactement le navigateur dans un certificat ? (trois points minimum)
3. Un pirate peut-il obtenir un certificat valide pour banque-exemple.fr ?
4. Pourquoi ne pas chiffrer toute la session en asymétrique plutôt que de basculer en symétrique ?

Résumé

• Publique chiffre / privée déchiffre ; signée par la privée / vérifiée par la publique.
• Certificat = domaine + clé publique + signature d'une AC connue de votre système.
• Chaîne de confiance : mon OS → AC racines → AC intermédiaires → certificat du site.
• Handshake : s'identifier (asymétrique), convenir d'une clé de session, parler chiffré (symétrique rapide).