05 - TLS, HTTPS et certificats : comment ca marche

Ce que tu vas apprendre

Ce qui se passe quand tu tapes https:// dans ton navigateur
Le rôle des Certificate Authorities
Let's Encrypt et le protocole ACME
Les certificats auto-signes et quand les utiliser
Comment Caddy simplifie tout ca

Prerequisites

01 - Chiffrement symetrique vs asymetrique : le chiffrement hybride est la base de TLS

Que se passe-t-il quand tu tapes https:// ?

Quand tu visites https://exemple.com, ton navigateur et le serveur font un TLS handshake avant d'échanger la moindre donnee. Ca prend entre 50 et 200 millisecondes, et ca se passe en gros comme ca :

Client Hello : ton navigateur envoie la liste des algorithmes de chiffrement qu'il supporte, plus un nombre aleatoire.
Server Hello : le serveur choisit un algorithme, envoie son certificat (qui contient sa clé publique) et un autre nombre aleatoire.
Verification du certificat : ton navigateur vérifié que le certificat est valide. Il est signe par une CA de confiance ? Il n'est pas expire ? Le nom de domaine correspond ?
Échange de clés : le client et le serveur utilisent un échange Diffie-Hellman éphémère (ECDHE) pour générer une clé symetrique partagee. Meme si quelqu'un enregistre tout le trafic, il ne pourra pas reconstituer cette clé (c'est le forward secrecy).
Chiffrement symetrique : à partir de la, toute la communication est chiffree avec AES (ou ChaCha20). Rapide, efficace.

C'est le chiffrement hybride dont on a parle dans l'article 01 : asymetrique pour l'échange, symetrique pour les donnees.

Les Certificate Authorities (CA)

Le certificat du serveur doit etre signe par une autorite de certification (CA) que ton navigateur reconnait. Ton OS et ton navigateur embarquent une liste de CAs de confiance (environ 150 racines dans Firefox en 2026).

Le système est hiérarchique. La CA racine signe des certificats intermediaires, qui signent les certificats des sites. Si tu veux voir la chaîne pour un site :

bashopenssl s_client -connect exemple.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | head -20

Le problème des CAs, c'est la confiance centralisee. En 2011, la CA DigiNotar a ete compromise et a emis de faux certificats pour google.com. Tous les navigateurs ont du revoquer DigiNotar d'urgence. En 2015, Symantec a emis des certificats de test pour des domaines Google sans autorisation. Google a progressivement revoque la confiance en Symantec entre 2017 et 2018. Le système marche, mais il n'est pas parfait.

Let's Encrypt : le chiffrement pour tous

Avant 2015, un certificat TLS coutait entre 10 et 200 euros par an. Beaucoup de petits sites restaient en HTTP. Let's Encrypt, lance en avril 2016 par l'ISRG (Internet Security Research Group), a change la donne : des certificats gratuits, automatiques, valides 90 jours.

En mars 2026, Let's Encrypt protégé plus d'un milliard de sites. Le protocole utilise s'appelle ACME (Automatic Certificate Management Environment, RFC 8555). Le principe :

Tu prouves que tu contrôles le domaine (en placant un fichier spécifique sur le serveur ou un enregistrement DNS)
Let's Encrypt te delivre un certificat
60 jours plus tard, le renouvellement est automatique

bash# Avec certbot (le client ACME officiel)
sudo certbot --nginx -d exemple.com -d www.exemple.com

Certbot configure automatiquement Nginx et planifie le renouvellement. Ca prend 30 secondes.

Caddy : le zero-config TLS

Si tu deploies des applications web, je te recommande Caddy plutot que Nginx + Certbot. Caddy obtient et renouvelle les certificats Let's Encrypt automatiquement, sans configuration.

# Caddyfile complet pour un reverse proxy HTTPS
exemple.com {
    reverse_proxy localhost:3000
}

C'est tout. Caddy gere le certificat, le renouvellement, la redirection HTTP vers HTTPS, HTTP/2, et OCSP stapling. Zero commande supplementaire. Quand j'ai découvert Caddy, j'ai arrêté de configurer Nginx pour mes projets perso.

Les certificats auto-signes

Un certificat auto-signe, c'est un certificat que tu générés toi-meme, sans CA. Le chiffrement fonctionne, mais le navigateur affiche un gros avertissement parce qu'il ne peut pas vérifier l'identité du serveur.

bash# Generer un certificat auto-signe (valide 365 jours)
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Quand c'est utile :

Développement local
Communication entre services internes
Tests

Quand c'est inacceptable :

Tout ce qui est expose a des utilisateurs
APIs publiques

Pour le dev local, mkcert est un meilleur choix : il créé une CA locale que ton navigateur accepte, sans avertissements.

bash# Installer mkcert et generer des certificats locaux
mkcert -install
mkcert localhost 127.0.0.1

mTLS : quand le client aussi prouve son identité

Dans le TLS classique, seul le serveur prouve son identité. Le mTLS (mutual TLS) ajoute un certificat cote client. Les deux parties se verifient mutuellement.

C'est utilise dans les architectures microservices (service mesh comme Istio), les APIs B2B, et certains VPNs. Tu n'en as probablement pas besoin pour un projet web classique, mais ca existe et ca vaut le coup de savoir que c'est possible.

Inspecter un certificat en ligne de commande

Quand un truc ne marche pas en HTTPS, openssl s_client est ton ami :

bash# Voir le certificat d'un site
echo | openssl s_client -connect exemple.com:443 2>/dev/null | openssl x509 -text -noout

# Verifier la date d'expiration
echo | openssl s_client -connect exemple.com:443 2>/dev/null | openssl x509 -enddate -noout

# Voir toute la chaine de certificats
echo | openssl s_client -connect exemple.com:443 -showcerts 2>/dev/null

J'utilise régulièrement la commande d'expiration pour vérifier que le renouvellement automatique fonctionne. Mieux vaut vérifier avant que les utilisateurs voient une erreur "NET::ERR_CERT_DATE_INVALID".

Recapitulatif

TLS combine tout ce qu'on a vu dans les articles précédents : chiffrement asymetrique pour l'échange de clés, symetrique pour les donnees, signatures pour l'authenticite, certificats pour la confiance. C'est le protocole qui fait tourner le web sécurisé.

Prochain article : on parle de la gestion des clés au quotidien. Rotation, backup, passphrases, clés materielles.

Navigation : Precedent : 04 - Signer ses commits Git | Suivant : 06 - Gerer ses clés

Sources

TLS 1.3 - RFC 8446 par IETF
Let's Encrypt - How It Works par ISRG
Caddy Documentation par Caddy Project
Mozilla SSL Configuration Generator par Mozilla

Retrouve d'autres articles techniques sur paltemps.fr.