TL;DR
- HTTPS = HTTP + TLS. Le "S" signifie que la connexion est chiffree entre ton navigateur et le serveur.
- Le handshake TLS negocie les algorithmes, echange les cles, et verifie l'identite du serveur. Tout ca en moins de 200ms.
- Les certificats sont des cartes d'identite numeriques signees par des autorites de confiance. Ton navigateur en connait environ 150.
- Let's Encrypt a rendu les certificats gratuits et automatiques. Il n'y a plus aucune excuse pour ne pas etre en HTTPS.
- HSTS force le navigateur a toujours utiliser HTTPS, meme si l'utilisateur tape http://. C'est un header, une ligne de config.
Chaque jour, des milliards de requetes HTTPS. Mais comment ca marche ?
Tu tapes https://radnoumane.com dans ton navigateur. En moins de 200 millisecondes, une connexion securisee est etablie. Tes donnees sont chiffrees, l'identite du serveur est verifiee, et personne entre toi et le serveur ne peut lire ou modifier le trafic.
Mais qu'est-ce qui se passe concretement pendant ces 200 millisecondes ? La plupart des devs savent que HTTPS "c'est securise" et que "ca utilise des certificats". Mais le mecanisme precis reste flou. Et quand tu dois configurer du TLS sur un Nginx ou deboguer un certificat expire en production a 2h du matin, le flou devient un probleme.
HTTP vs HTTPS : la difference fondamentale
HTTP (HyperText Transfer Protocol) est un protocole en texte clair. Tout ce que tu envoies et recois -- les headers, les cookies, le body, les credentials -- transite lisiblement sur le reseau. N'importe qui sur le meme Wi-Fi, n'importe quel routeur entre toi et le serveur, peut lire le trafic.
HTTPS ajoute une couche TLS (Transport Layer Security) entre TCP et HTTP. TLS chiffre tout le trafic, verifie l'identite du serveur, et garantit l'integrite des donnees (personne ne peut modifier le contenu en transit).
HTTP : Client ←→ [Réseau en clair] ←→ Serveur
HTTPS : Client ←→ [TLS chiffré] ←→ Serveur
Note historique : on parle encore de "SSL" par habitude, mais SSL est mort depuis 2015. Les versions SSL 2.0 et 3.0 avaient des failles critiques (POODLE, DROWN). Le protocole actuel est TLS 1.3 (depuis 2018). Quand quelqu'un dit "certificat SSL", il parle en realite d'un certificat TLS.
Le handshake TLS : ce qui se passe en 200ms
Quand ton navigateur se connecte a un serveur HTTPS, un handshake TLS s'engage avant tout echange de donnees HTTP. Voici ce qui se passe, etape par etape.
Etape 1 : ClientHello. Ton navigateur envoie les versions de TLS qu'il supporte, la liste des algorithmes de chiffrement (cipher suites) qu'il connait, et un nombre aleatoire.
Etape 2 : ServerHello. Le serveur choisit la meilleure version de TLS et la meilleure cipher suite parmi celles proposees. Il envoie aussi un nombre aleatoire.
Etape 3 : Certificat. Le serveur envoie son certificat, qui contient sa cle publique et son identite (nom de domaine). C'est l'equivalent de montrer sa carte d'identite.
Etape 4 : Verification. Ton navigateur verifie que le certificat est valide : pas expire, signe par une autorite de confiance, et correspond au domaine visite.
Etape 5 : Echange de cles. Le navigateur genere une cle pre-master secrete, la chiffre avec la cle publique du serveur, et l'envoie. Seul le serveur peut la dechiffrer avec sa cle privee.
Etape 6 : Cle de session. Les deux cotes calculent une cle de session symetrique a partir du pre-master secret et des nombres aleatoires echanges. Cette cle symetrique sera utilisee pour chiffrer tout le reste de la communication.
Etape 7 : Connexion chiffree. Les deux cotes confirment que le handshake est termine. A partir de la, tout le trafic HTTP est chiffre avec la cle de session.
TLS 1.3 simplifie ce processus : le handshake passe de 2 allers-retours a 1 seul (1-RTT), et supporte meme le 0-RTT pour les connexions subsequentes. C'est plus rapide et plus securise car il elimine les cipher suites obsoletes.
Cles publiques et privees : l'asymetrie au coeur de TLS
Le handshake utilise deux types de chiffrement :
Chiffrement asymetrique (RSA, ECDHE). Deux cles : une publique (que tout le monde peut avoir) et une privee (que seul le serveur possede). Ce qui est chiffre avec la cle publique ne peut etre dechiffre qu'avec la cle privee. C'est utilise uniquement pendant le handshake pour echanger la cle de session.
Chiffrement symetrique (AES-256-GCM). Une seule cle partagee par les deux cotes. Beaucoup plus rapide que l'asymetrique. C'est utilise pour chiffrer tout le trafic apres le handshake.
Pourquoi ne pas utiliser l'asymetrique pour tout ? Parce que c'est environ 1000 fois plus lent que le symetrique. Le handshake utilise l'asymetrique pour echanger securisement une cle symetrique, puis tout le reste utilise cette cle symetrique. Le meilleur des deux mondes.
# Générer une paire de clés RSA (ne fais pas ça en production, utilise Let's Encrypt)
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key
# Voir le contenu d'un certificat
openssl x509 -in certificate.crt -text -noout
# Vérifier qu'un certificat correspond à une clé privée
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5
# Les deux hashes doivent être identiques
Les certificats : la chaine de confiance
Un certificat TLS contient :
- Le nom de domaine (ex:
radnoumane.com) - La cle publique du serveur
- L'identite de l'emetteur (l'autorite de certification)
- La signature de l'emetteur
- Les dates de validite
Ton navigateur fait confiance a environ 150 autorites de certification (CA) preinstallees. Quand un serveur presente un certificat signe par une CA connue, le navigateur le considere comme valide.
La chaine de confiance fonctionne ainsi :
- Root CA. L'autorite racine, preinstallee dans ton navigateur/OS. Elle ne signe pas directement les certificats des sites.
- Intermediate CA. Signee par la Root CA. C'est elle qui signe les certificats des sites web.
- Certificat du site. Signe par l'Intermediate CA. Presente pendant le handshake.
Le navigateur remonte la chaine : certificat du site, signe par l'Intermediate CA, elle-meme signee par une Root CA connue. Si la chaine est complete et valide, le cadenas vert s'affiche.
Pourquoi les Intermediate CA ? Pour limiter les degats en cas de compromission. Si une Intermediate CA est compromise, on la revoque. Si une Root CA etait compromise, il faudrait mettre a jour tous les navigateurs du monde.
Let's Encrypt : pourquoi c'est gratuit et comment ca marche
Avant 2016, un certificat TLS coutait entre 10 et 300 euros par an. Let's Encrypt a rendu les certificats gratuits et automatiques. Aujourd'hui, plus de 300 millions de sites utilisent Let's Encrypt.
Le protocole ACME (Automatic Certificate Management Environment) automatise tout le processus :
- Tu demandes un certificat pour
monsite.comvia un client ACME (certbot, acme.sh). - Let's Encrypt verifie que tu controles le domaine. Deux methodes : HTTP-01 (placer un fichier sur ton serveur) ou DNS-01 (ajouter un record TXT dans ton DNS).
- Si la verification passe, Let's Encrypt signe et te delivre un certificat valable 90 jours.
- Le renouvellement est automatique. Un cron job relance le processus tous les 60 jours.
# Installation avec certbot (la méthode la plus courante)
sudo apt install certbot python3-certbot-nginx
# Obtenir un certificat et configurer Nginx automatiquement
sudo certbot --nginx -d monsite.com -d www.monsite.com
# Vérifier le renouvellement automatique
sudo certbot renew --dry-run
# Le cron est ajouté automatiquement :
# 0 0,12 * * * certbot renew --quiet
La configuration Nginx generee par certbot :
server {
listen 443 ssl;
server_name monsite.com;
ssl_certificate /etc/letsencrypt/live/monsite.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/monsite.com/privkey.pem;
# Paramètres TLS recommandés
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
# HSTS
add_header Strict-Transport-Security "max-age=63072000" always;
}
# Redirection HTTP → HTTPS
server {
listen 80;
server_name monsite.com;
return 301 https://$server_name$request_uri;
}
Pourquoi 90 jours et pas 1 an ? Parce que des certificats courts forcent l'automatisation. Et l'automatisation est plus fiable que les humains qui oublient de renouveler. La plupart des incidents de certificat expire viennent de certificats long-terme geres manuellement.
HSTS et les protections supplementaires
HTTPS ne suffit pas si un utilisateur peut toujours acceder a la version HTTP. HSTS (HTTP Strict Transport Security) resout ca.
HSTS. Un header HTTP qui dit au navigateur : "Ne me contacte plus jamais en HTTP. Toujours HTTPS." Le navigateur memorise cette instruction pour la duree specifiee (generalement 2 ans).
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Avec preload, ton domaine est ajoute a une liste codee en dur dans Chrome, Firefox, Safari et Edge. Meme la premiere visite sera en HTTPS, sans jamais passer par HTTP.
OCSP Stapling. Au lieu que le navigateur contacte la CA pour verifier si le certificat est revoque (lent), le serveur attache ("staple") la reponse OCSP a la connexion TLS. Plus rapide et plus prive.
# OCSP Stapling dans Nginx
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
Certificate Transparency. Tous les certificats emis sont publies dans des logs publics verifiables. Si une CA emet un certificat frauduleux pour ton domaine, tu peux le detecter. Des outils comme crt.sh te permettent de surveiller les certificats emis pour tes domaines.
Les erreurs courantes
En tant que dev, voici les problemes TLS que tu vas rencontrer :
Certificat expire. Le classique. Le cron de renouvellement a echoue silencieusement, ou quelqu'un a oublie de le configurer. Solution : automatise avec certbot et surveille les dates d'expiration.
Chaine incomplete. Le serveur envoie le certificat du site mais pas l'Intermediate CA. Certains navigateurs s'en sortent (ils telechargent l'intermediaire), d'autres non. Solution : configure le fullchain.pem, pas juste le cert.pem.
Mixed content. La page est en HTTPS mais charge des ressources en HTTP (images, scripts). Le navigateur bloque les scripts et affiche un warning pour les images. Solution : utilise des URLs relatives ou https:// partout.
Mauvais domaine. Le certificat est pour www.monsite.com mais l'utilisateur accede a monsite.com (sans www). Solution : genere le certificat pour les deux domaines, ou redirige l'un vers l'autre.
# Diagnostiquer les problèmes TLS
# Vérifier la chaîne de certificats
openssl s_client -connect monsite.com:443 -servername monsite.com
# Tester la configuration TLS
curl -vI https://monsite.com 2>&1 | grep -E "SSL|certificate|expire"
# Scanner en ligne : ssllabs.com/ssltest
En resume
HTTPS n'est pas optionnel. En 2025, Chrome affiche un warning pour tout site en HTTP. Google penalise les sites non-HTTPS dans le SEO. Et surtout, transmettre des donnees en clair sur internet, c'est irresponsable.
La bonne nouvelle : avec Let's Encrypt et certbot, passer en HTTPS prend 5 minutes et coute zero euro. Le handshake TLS ajoute moins de 100ms au temps de chargement (et souvent moins avec TLS 1.3 et le session resumption).
Le HTTPS n'est pas un luxe. C'est la base. Maintenant tu sais exactement ce qui se passe quand tu tapes ce petit s apres http.
Ressources
- Let's Encrypt - Getting Started -- guide officiel pour obtenir un certificat gratuit
- Mozilla SSL Configuration Generator -- genere la config TLS optimale pour Nginx, Apache, etc.
- SSL Labs Server Test -- teste et note la configuration TLS de ton serveur
- Certificate Transparency Logs -- surveille les certificats emis pour tes domaines
- TLS 1.3 RFC 8446 -- la specification officielle du protocole
- Certbot Documentation -- documentation du client ACME le plus utilise