Qu'est-ce que TLS ? Le handshake, TLS 1.3 et les certificats, expliqués

TLS et SSL : un même rôle, deux noms

TLS (Transport Layer Security) se place entre TCP et HTTP et transforme une connexion en clair en connexion privée. Quand une adresse commence par https://, c'est TLS qui la sécurise ; le même protocole protège aussi la messagerie, le DNS over TLS et la plupart des API.

SSL (Secure Sockets Layer) est le point de départ. Netscape a publié SSL 2.0 en 1995 et SSL 3.0 en 1996. En reprenant le protocole, l'IETF l'a rebaptisé : TLS 1.0 (1999) est, pour l'essentiel, un SSL 3.1. Sont venus ensuite TLS 1.1 (2006), TLS 1.2 (2008) et TLS 1.3 (2018).

Toutes les versions de SSL sont aujourd'hui interdites. SSL 3.0 est tombé sous l'attaque POODLE en 2014 et a été formellement proscrit en 2015 ; TLS 1.0 et 1.1 ont été dépréciés en 2021, alors que les navigateurs les avaient déjà abandonnés. Ce qui sert aujourd'hui, c'est TLS 1.2 et TLS 1.3.

L'ancien nom survit dans le langage courant. Quand on parle de « certificat SSL », on désigne le certificat que présente un serveur TLS ; il n'existe pas de certificat SSL distinct d'un certificat TLS. C'est le même fichier X.509, et il fonctionne avec la version du protocole sur laquelle les deux parties s'accordent. Si c'est le certificat lui-même qui vous intéresse, commencez par les certificats SSL gratuits.

Ce que TLS garantit, et ce qu'il ne garantit pas

TLS apporte trois propriétés à une connexion.

Confidentialité. Tout ce qui suit le handshake est chiffré avec des clés que seules les deux extrémités connaissent. Quelqu'un sur le même Wi-Fi, chez le fournisseur d'accès ou sur un lien de transit ne voit que des octets chiffrés.

Intégrité. Chaque enregistrement porte une étiquette d'authentification. Un seul octet modifié en route est détecté, et la connexion est fermée au lieu de livrer des données altérées à l'application.

Authentification. Le serveur prouve qu'il détient la clé privée d'un certificat émis pour le nom demandé par le navigateur. C'est ce qui empêche un attaquant de simplement répondre à votre place. Le client peut lui aussi être authentifié, avec le TLS mutuel (mTLS), mais c'est rare sur le web public.

Savoir ce que TLS ne fait pas est tout aussi utile. Il ne cache pas avec quel serveur vous communiquez : les adresses IP sont visibles, tout comme le nom de domaine transmis dans le SNI (nous y revenons plus bas). Il ne rend pas le contenu sûr : une injection SQL arrive aussi bien chiffrée qu'un formulaire de connexion, et l'arrêter est le travail d'un WAF. Enfin, il ne protège les données qu'en transit : une fois qu'elles sont déchiffrées sur le serveur, TLS n'intervient plus.

Le handshake TLS 1.2 : deux allers-retours

Avant qu'un seul octet HTTP ne parte, le navigateur et le serveur doivent s'accorder sur une version et un chiffrement, vérifier le certificat et dériver des clés communes. Cette négociation, c'est le handshake TLS, et en TLS 1.2 elle demande deux allers-retours complets en plus de la connexion TCP.

Premier aller-retour. Le navigateur envoie un ClientHello : les versions et suites de chiffrement qu'il accepte, une valeur aléatoire et des extensions comme le SNI et l'ALPN (la version de HTTP souhaitée). Le serveur répond par un ServerHello (version et chiffrement retenus), sa chaîne de certificats et, avec une suite ECDHE, sa part de l'échange de clés signée avec la clé du certificat.

Second aller-retour. Le navigateur vérifie le certificat, envoie sa propre part et les deux côtés calculent les mêmes clés de session. Chacun envoie ensuite un Finished, une empreinte de tout ce qui a été échangé jusque-là : si quelqu'un a trafiqué le handshake, il échoue précisément ici.

C'est seulement maintenant que la première requête peut partir. En comptant le handshake TCP, une nouvelle connexion HTTPS en TLS 1.2 consomme trois allers-retours avant même que le navigateur puisse demander la page. À 20 ms l'aller-retour, personne ne le remarque ; sur un lien mobile avec 150 ms entre le visiteur et le serveur, on approche de la demi-seconde. C'est l'une des raisons pour lesquelles un CDN termine TLS sur l'edge plutôt que sur une origine lointaine : les allers-retours du handshake deviennent courts.

TLS 1.3 : un seul aller-retour, et moins de pièges

TLS 1.3 (RFC 8446, 2018) repose sur une observation : le navigateur peut deviner. Presque tous les serveurs acceptent les mêmes quelques groupes d'échange de clés ; le navigateur envoie donc sa part de clé directement dans le ClientHello, sans attendre qu'on la lui demande.

Le serveur choisit un chiffrement, répond avec sa propre part, et dès cet instant les deux côtés disposent des clés. Tout ce qui suit le ServerHello, certificat compris, est déjà chiffré. Le navigateur vérifie le certificat, envoie son Finished et glisse sa première requête juste derrière : un aller-retour pour TLS, deux au total avec TCP. Avec HTTP/3, où QUIC transporte TLS 1.3 dans son propre handshake, transport et chiffrement tiennent ensemble en un seul.

Si le pari échoue, parce que le serveur veut un groupe pour lequel le navigateur n'a pas envoyé de part, le serveur répond par un HelloRetryRequest et le handshake coûte un aller-retour de plus. Comme pratiquement tous les navigateurs proposent X25519, c'est rare.

L'autre moitié de TLS 1.3, c'est ce qu'il a supprimé.

Plus d'échange de clés RSA. Chaque handshake utilise un (EC)DHE éphémère : toutes les connexions bénéficient de la confidentialité persistante (forward secrecy). Une clé privée volée l'an prochain ne pourra pas déchiffrer le trafic enregistré aujourd'hui.

Seuls les chiffrements AEAD restent : AES-GCM et ChaCha20-Poly1305. Le mode CBC, RC4, 3DES, SHA-1 et MD5 ne font même plus partie du protocole.

La renégociation et la compression ont disparu, et avec elles des familles entières d'attaques.

TLS 1.3 intègre aussi une protection contre la rétrogradation : un serveur TLS 1.3 poussé vers une version plus ancienne marque sa réponse, et un client TLS 1.3 qui voit cette marque coupe la connexion. Quand les deux côtés parlent 1.3, ils l'utilisent ; il n'y a aucun réglage « préférer 1.3 » à retenir.

0-RTT et reprise de session : le raccourci et son prix

Un visiteur déjà venu n'a pas besoin du handshake complet. À la fin d'un handshake TLS 1.3, le serveur peut remettre au navigateur un ticket de session ; la fois suivante, le navigateur le présente et les deux côtés sautent le certificat et le coûteux accord de clés. C'est la reprise de session, et elle coûte encore un aller-retour.

Le 0-RTT (early data) va plus loin. Grâce au ticket, le navigateur chiffre sa première requête avec des clés issues de la session précédente et l'envoie dans le même paquet que le ClientHello. Le serveur peut répondre aussitôt : la requête n'attend aucun handshake.

Le prix, c'est le rejeu (replay). Les données précoces partent avant que le serveur n'ait rien dit sur cette connexion ; elles ne contiennent donc rien de frais venant de lui. Un attaquant qui enregistre ce premier paquet peut le renvoyer, et le serveur voit deux fois une requête valide. Pour un GET de feuille de style, c'est sans conséquence ; pour un POST qui passe une commande, transfère de l'argent ou change un mot de passe, non. Les données précoces n'ont pas non plus de confidentialité persistante : quiconque obtient plus tard la clé des tickets peut les déchiffrer.

Les règles en découlent. N'acceptez le 0-RTT que pour des requêtes idempotentes (GET et HEAD sans effet de bord). Faites marquer les requêtes en early data par le serveur ou le proxy, avec l'en-tête Early-Data: 1 et le statut 425 Too Early du RFC 8470, pour que l'application puisse refuser d'agir. Et ne voyez jamais le 0-RTT comme une accélération gratuite à activer partout.

L'edge de CDN.com.tr n'accepte pas les données précoces 0-RTT : la question du rejeu n'atteint jamais votre application. Un visiteur qui revient reprend sa session avec un handshake TLS d'un seul aller-retour.

Certificats et chaîne de confiance

Le certificat est ce qui permet au serveur de prouver son identité. Il associe une clé publique à un ou plusieurs noms de domaine, listés dans son champ Subject Alternative Name, porte une période de validité et est signé par une autorité de certification (CA).

Les navigateurs ne font pas confiance directement à votre certificat. Ils font confiance à quelques dizaines de certificats racines de leur magasin de confiance, et les racines ne signent pas elles-mêmes les certificats de sites : elles signent des intermédiaires, et c'est un intermédiaire qui signe le vôtre. Le navigateur doit construire un chemin de votre certificat jusqu'à une racine qu'il connaît : feuille (votre certificat, pour www.example.com) → intermédiaire (le certificat émetteur de la CA) → racine (dans le magasin de confiance).

On attend du serveur qu'il envoie la feuille et les intermédiaires. Oublier l'intermédiaire est la panne classique : les navigateurs de bureau fonctionnent souvent quand même, parce qu'ils ont le certificat manquant en cache ou savent le récupérer, tandis que curl, les applications Android, les callbacks de paiement et les clients d'API échouent avec « unable to get local issuer certificate ». Si quelque chose marche dans votre navigateur mais pas depuis un serveur, vérifiez d'abord la chaîne.

Un exemple réel : le 7 octobre 2026, cdn.com.tr servait un certificat Let's Encrypt signé par l'intermédiaire YR1, qui remonte à ISRG Root YR, et le serveur envoyait aussi Root YR contre-signée par ISRG Root X1, la racine à laquelle les navigateurs font confiance depuis des années. C'est cette signature croisée qui permet à une toute nouvelle racine de fonctionner sur des appareils qui ne la connaissent pas.

Durée de validité. Les certificats Let's Encrypt durent 90 jours, et tout le secteur va dans le même sens : avec les règles adoptées par le CA/Browser Forum en 2025, la durée de vie maximale d'un certificat public est passée à 200 jours en mars 2026 et sera de 47 jours en 2029. Le renouvellement n'est plus une corvée annuelle, c'est un processus qui doit tourner tout seul.

DV, OV, EV. Le niveau de validation indique ce que la CA a vérifié (le seul contrôle du domaine, ou aussi l'organisation), pas la force du chiffrement. Un certificat gratuit validé par domaine et un certificat EV coûteux produisent exactement la même connexion TLS.

SNI : de nombreux sites HTTPS sur une seule IP

Les débuts de HTTPS posaient un problème de l'œuf et de la poule. Le serveur doit présenter son certificat pendant le handshake, mais le nom de domaine voulu par le visiteur arrive dans l'en-tête HTTP Host, après le handshake. Chaque site HTTPS avait donc besoin de sa propre adresse IP.

Le SNI (Server Name Indication) règle la question en plaçant le nom de domaine dans le ClientHello. Le serveur le lit avant de choisir un certificat ; c'est ainsi qu'une seule adresse peut héberger des milliers de sites HTTPS, chacun avec son certificat. Tous les CDN et tous les hébergements mutualisés en dépendent, et tous les navigateurs de la dernière décennie l'envoient.

Deux conséquences méritent d'être connues.

Un client sans SNI reçoit le certificat par défaut. Les clients très anciens, certains appareils embarqués et les scripts qui se connectent à une IP sans indiquer de nom de serveur reçoivent le certificat de repli du serveur, puis échouent sur un nom qui ne correspond pas. Quand vous testez avec openssl, passez toujours -servername.

Le SNI n'est pas chiffré. Le nom de domaine circule en clair dans le ClientHello : un réseau peut voir, et filtrer, le site que vous ouvrez, même s'il ne voit pas la page. C'est ainsi que fonctionnent les blocages par SNI. Encrypted Client Hello (ECH) est l'extension qui le masque, et les navigateurs ont commencé à l'intégrer ; en attendant qu'elle soit partout, partez du principe que le nom de domaine est visible.

Suites de chiffrement : comment lire les noms

Une suite de chiffrement (cipher suite) désigne les algorithmes qu'utilise une connexion. TLS 1.2 regroupe quatre choix dans un seul nom.

ECDHE-RSA-AES128-GCM-SHA256 signifie : échange de clés ECDHE (Diffie-Hellman éphémère sur courbe elliptique, qui apporte la confidentialité persistante), authentification RSA (le type de clé du certificat), chiffrement des données en AES-128 mode GCM (un chiffrement AEAD : confidentialité et intégrité en une seule opération) et SHA-256 pour dériver les clés.

Les noms TLS 1.3 sont plus courts, car l'échange de clés et la signature se négocient à part, et il n'existe que cinq suites, dont trois réellement utilisées : TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 et TLS_CHACHA20_POLY1305_SHA256. Toutes sont AEAD et toutes offrent la confidentialité persistante : il ne reste rien à régler.

Une bonne liste TLS 1.2 place en tête l'échange ECDHE et les chiffrements AEAD, ne contient rien qui comporte RC4, 3DES, MD5, NULL ou EXPORT, et c'est le serveur qui choisit selon son propre ordre au lieu de suivre celui du client. Les anciennes suites CBC sont souvent gardées en fin de liste pour de très vieux clients ; quand le serveur choisit, un navigateur moderne n'y tombe jamais. Un scanner énumère tout ce que le serveur propose ; pour voir ce qu'une vraie connexion utilise, regardez la suite négociée avec les commandes en fin de guide.

ChaCha20-Poly1305 existe pour les appareils sans accélération AES matérielle, surtout d'anciens téléphones, sur lesquels il est plus rapide qu'AES-GCM en logiciel.

Erreurs TLS courantes et leur vraie signification

ERR_SSL_PROTOCOL_ERROR (Chrome) : le handshake s'est rompu d'une manière que le navigateur n'a pas su classer. Les causes habituelles : autre chose que TLS répond sur le port 443 (du HTTP en clair, un portail captif), un antivirus ou un équipement réseau intercepte la connexion, ou le serveur n'a pas de certificat pour ce nom de domaine. Essayez d'abord depuis un autre réseau ; si l'erreur n'apparaît que sur un seul, le serveur n'est pas en cause.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH, dans Firefox SSL_ERROR_NO_CYPHER_OVERLAP : le client et le serveur n'ont aucune version ni suite de chiffrement en commun. Aujourd'hui, cela signifie presque toujours que l'un des deux est très ancien, comme un appareil embarqué qui ne parle que TLS 1.0 ou un serveur encore configuré pour lui.

ERR_CERT_COMMON_NAME_INVALID : le certificat ne mentionne pas le nom de domaine ouvert. Typique quand le DNS pointe déjà un nouveau sous-domaine vers un serveur qui n'a pas encore de certificat pour lui, ou quand www manque dans le certificat.

ERR_CERT_DATE_INVALID : le certificat a expiré, ou l'horloge du visiteur est fausse. Si une seule personne la voit, vérifiez son horloge ; si tout le monde la voit, le renouvellement s'est arrêté.

unable to get local issuer certificate (curl, OpenSSL et de nombreux SDK) : le serveur n'a pas envoyé son certificat intermédiaire. Corrigez la chaîne sur le serveur, pas le magasin de confiance du client.

Une 502 renvoyée par un proxy ou un CDN alors que le navigateur affiche un cadenas valide : le TLS du visiteur était correct, mais la connexion du proxy vers votre origine a échoué. C'est un handshake distinct, avec son propre certificat et ses propres versions ; le guide de l'erreur 502 Bad Gateway le détaille pas à pas.

Comment CDN.com.tr termine TLS sur l'edge

Quand votre site est derrière CDN.com.tr, la connexion TLS du visiteur se termine sur un serveur edge de CDN.com.tr, pas sur votre origine : c'est l'edge qui détient votre certificat et mène le handshake. Il le fait pour chaque nom de domaine, sans réglage par site qu'on pourrait oublier.

TLS 1.2 et TLS 1.3 uniquement. TLS 1.0 et 1.1 sont refusés au handshake, pas rétrogradés. L'edge choisit le chiffrement dans sa propre liste, avec l'échange ECDHE et les chiffrements AEAD en tête ; lors de notre test du 7 octobre 2026, TLS 1.3 a négocié TLS_AES_256_GCM_SHA384 sur X25519. La politique est identique pour tous les comptes, et la page sur la politique TLS donne les détails que demandent les questionnaires de sécurité.

HTTP/3 pour tous les sites. HTTP/3 fonctionne sur QUIC, qui intègre TLS 1.3. Les navigateurs le découvrent via l'en-tête Alt-Svc et basculent à la connexion suivante ; il n'y a rien à activer. Plus de détails dans HTTP/3 et IPv6.

Un certificat par nom de domaine, choisi par SNI. Chacun de vos noms de domaine est servi avec son propre certificat.

Let's Encrypt, émis et renouvelé à votre place. Avec le SSL automatique, le certificat est demandé dès que votre domaine est vérifié et que son DNS pointe vers nous, puis renouvelé automatiquement 30 jours avant son expiration. Si le DNS de votre domaine est chez CDN.com.tr, le certificat peut être un wildcard couvrant le domaine racine et tous les sous-domaines de premier niveau, validé par un enregistrement DNS. Vous migrez un site en production ? L'assistant sans interruption émet ce wildcard grâce à un enregistrement TXT chez votre fournisseur DNS actuel avant la bascule : HTTPS fonctionne dès la première seconde.

Votre propre certificat si besoin. Un certificat OV ou EV acheté ailleurs peut être importé et associé à un nom de domaine, et il reçoit exactement la même politique TLS.

Une connexion TLS distincte vers votre origine. Par défaut, une requête HTTPS est aussi récupérée sur votre origine en HTTPS, via la propre connexion de l'edge vers le port HTTPS de votre origine. Le visiteur ne voit jamais ce handshake ; s'il échoue, il reçoit une 502, pas un avertissement de certificat.

HSTS quand vous êtes prêt. Une fois que tout fonctionne en HTTPS, le préréglage de sécurité HSTS indique aux navigateurs de ne plus jamais tenter le HTTP en clair sur votre nom de domaine.

Vérifier le TLS de n'importe quel site en une minute

Cinq commandes répondent à la plupart des questions sur TLS : quelle version et quel chiffrement une vraie connexion utilise, quelle chaîne le serveur envoie, quand le certificat expire, si les anciennes versions sont refusées et combien de temps prend le handshake. Remplacez www.example.com par votre nom de domaine et gardez -servername : sans lui, vous testez le certificat par défaut du serveur et non le vôtre.

Version, chiffrement, chaîne, expiration et durée du handshake en ligne de commande

# Version et chiffrement négociés
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher is"

# La chaîne envoyée par le serveur : titulaire (s:) et émetteur (i:) de chaque certificat
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9]+ s:|^ *i:"

# Date d'expiration du certificat
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate

# TLS 1.1 doit être refusé (SECLEVEL=0 évite que votre propre OpenSSL refuse en premier)
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1 -cipher 'DEFAULT:@SECLEVEL=0' </dev/null

# Secondes jusqu'à TCP, puis jusqu'à TCP + TLS
curl -so /dev/null -w 'tcp %{time_connect}  tls %{time_appconnect}\n' https://www.example.com/