Un certificat SSL/TLS est un document numérique qui prouve l'identité d'un site web et permet à votre navigateur d'établir avec lui une connexion HTTPS chiffrée. Il associe un nom de domaine à une clé publique et il est signé par une autorité de certification (AC) en laquelle les navigateurs ont déjà confiance.
Chaque fois que vous voyez https:// et un cadenas (ou un indicateur similaire) dans la barre d'adresse, un certificat a été vérifié une fraction de seconde plus tôt. Les certificats remplissent deux fonctions à la fois : ils authentifient le serveur, pour que vous sachiez que vous parlez au vrai example.com et non à un imposteur, et ils permettent le chiffrement, pour que personne sur le trajet réseau ne puisse lire ni modifier ce que vous envoyez.
SSL ou TLS : quelle est la différence ?
SSL (Secure Sockets Layer) était le protocole d'origine, développé par Netscape dans les années 1990. Il a été remplacé par TLS (Transport Layer Security), et toutes les versions de SSL sont aujourd'hui considérées comme non sécurisées et officiellement abandonnées. TLS 1.0 et 1.1 l'ont été aussi, par la RFC 8996 (2021) : les connexions modernes utilisent donc TLS 1.2 ou TLS 1.3.
L'expression « certificat SSL » est pourtant restée. Le certificat lui-même n'est pas lié à une version du protocole ; le même certificat fonctionne avec n'importe quelle version de TLS. « Certificat SSL », « certificat TLS » et « certificat HTTPS » désignent la même chose.
Comment fonctionne la négociation TLS (handshake)
Avant l'échange de toute donnée d'une page web, le navigateur et le serveur effectuent une négociation (handshake). Simplifiée, une négociation TLS 1.3 se déroule ainsi :
- Client hello. Le navigateur se connecte, généralement sur le port 443, et indique les versions de TLS et les suites de chiffrement qu'il prend en charge. Il précise le nom d'hôte voulu (grâce à l'extension Server Name Indication, qui permet à une seule adresse IP d'héberger de nombreux sites) et sa part d'un échange de clés.
- Server hello. Le serveur choisit les paramètres, envoie sa propre part de clé et présente son certificat avec une signature prouvant qu'il détient la clé privée correspondante.
- Vérification. Le navigateur vérifie que le certificat couvre le nom d'hôte, qu'il est dans ses dates de validité et qu'il remonte jusqu'à une AC racine de confiance.
- Clés de session. Les deux parties dérivent les mêmes clés de session symétriques à partir de l'échange de clés. Tout le trafic suivant est chiffré avec elles.
La clé privée ne quitte jamais le serveur. La cryptographie à clé publique sert uniquement à authentifier et à s'accorder sur des clés ; les données volumineuses sont chiffrées avec des algorithmes symétriques rapides comme AES-GCM ou ChaCha20-Poly1305. TLS 1.3 accomplit tout cela en un seul aller-retour, contre deux pour TLS 1.2.
Ce que contient un certificat
Un certificat suit la norme X.509 et contient, entre autres, les champs suivants :
- Subject Alternative Names (SAN) : les noms d'hôte pour lesquels le certificat est valable. Les navigateurs vérifient cette liste, et non l'ancien champ Common Name.
- Clé publique : la clé publique RSA ou ECDSA du serveur.
- Émetteur : l'AC qui a signé le certificat.
- Période de validité : les dates « Not Before » et « Not After ».
- Numéro de série et signature : un identifiant unique et la signature de l'émetteur sur l'ensemble de ce qui précède.
Certificats SAN et certificats wildcard
Un même certificat peut couvrir de nombreux noms en les listant comme SAN, par exemple example.com, www.example.com et shop.example.com. Un wildcard tel que *.example.com couvre n'importe quel libellé unique à ce niveau : il correspond à www.example.com et api.example.com, mais pas à example.com lui-même ni aux noms plus profonds comme a.b.example.com. C'est pourquoi les certificats wildcard listent généralement le domaine nu comme SAN supplémentaire.
Certificats DV, OV et EV
Les certificats diffèrent par la rigueur des vérifications que l'AC a effectuées sur le demandeur avant de les émettre :
| Type | Ce qui est vérifié | Usage typique |
|---|---|---|
| Domain Validated (DV) | Uniquement que le demandeur contrôle le domaine, via un enregistrement DNS, un fichier sur le site ou un e-mail | La plupart des sites ; émis automatiquement en quelques secondes |
| Organization Validated (OV) | Le contrôle du domaine, plus l'existence légale de l'organisation | Les entreprises qui veulent le nom de la société dans les détails du certificat |
| Extended Validation (EV) | Une vérification plus stricte et normalisée de l'entité juridique | Certaines banques et grandes entreprises |
Les trois offrent exactement la même robustesse de chiffrement. La différence ne porte que sur les informations d'identité. Les principaux navigateurs ont cessé d'afficher en vert le nom de l'entreprise pour les certificats EV vers 2019 : pour la plupart des sites, un certificat DV est donc le choix pratique.
La chaîne de confiance
Votre système d'exploitation et votre navigateur sont livrés avec un magasin racine : une liste de certificats d'AC racines auxquels ils font confiance. Les AC racines signent rarement directement les certificats de sites. Elles signent des certificats intermédiaires, qui signent à leur tour le certificat feuille (celui du serveur) :
Root CA (in the browser's trust store)
└── Intermediate CA (sent by the server)
└── www.example.com (leaf certificate, sent by the server)Le serveur doit envoyer son certificat feuille et les certificats intermédiaires. Le navigateur vérifie alors chaque signature jusqu'à une racine à laquelle il fait déjà confiance. Cette organisation permet de garder les clés racines hors ligne et bien protégées. Pour se prémunir contre les émissions abusives, les certificats de confiance publique sont aussi consignés dans des journaux publics de Certificate Transparency, et les propriétaires de domaines peuvent restreindre les AC autorisées à émettre pour eux avec un enregistrement DNS CAA, décrit dans notre guide des types d'enregistrements DNS.
Let's Encrypt et durée de vie des certificats
Let's Encrypt, une AC à but non lucratif, a rendu courants les certificats DV gratuits. Ses certificats sont valables 90 jours et conçus pour être renouvelés automatiquement avec le protocole ACME, grâce à des clients comme Certbot ou à des fonctions intégrées à de nombreux serveurs web et panneaux d'hébergement. La plupart des hébergeurs et des CDN émettent et renouvellent désormais les certificats sans aucune étape manuelle.
Les durées de vie raccourcissent dans toute l'industrie. Selon le scrutin SC-081 du CA/Browser Forum, la validité maximale des certificats TLS de confiance publique est réduite par étapes, à commencer par 200 jours à partir de mars 2026, puis de nouvelles baisses les années suivantes. Le calendrier exact peut encore évoluer, mais la direction est claire : automatisez le renouvellement, car renouveler les certificats à la main deviendra de moins en moins réaliste.
Erreurs de certificat courantes et comment les corriger
Certificat expiré
Les navigateurs affichent des erreurs comme NET::ERR_CERT_DATE_INVALID. Renouvelez le certificat et rechargez le serveur web. Cherchez ensuite pourquoi le renouvellement automatique a échoué : c'est souvent un pare-feu qui bloque la validation, un changement DNS ou une tâche cron défaillante. Une horloge incorrecte sur l'appareil du visiteur peut provoquer la même erreur : vérifiez donc la date si un seul appareil se plaint.
Le nom ne correspond pas
Des erreurs comme ERR_CERT_COMMON_NAME_INVALID signifient que le nom d'hôte de la barre d'adresse ne figure pas dans la liste SAN du certificat, par exemple un certificat pour www.example.com servi pour example.com. Réémettez le certificat pour y inclure chaque nom d'hôte que vous servez, ou redirigez les visiteurs vers un nom couvert.
Chaîne incomplète
Si le serveur n'envoie que le certificat feuille sans ses intermédiaires, certains navigateurs s'en sortent en récupérant ou en mettant en cache l'élément manquant, tandis que d'autres, comme de nombreux outils en ligne de commande et applications, échouent. Configurez le serveur avec le fichier de chaîne complète (souvent appelé fullchain.pem).
Certificat auto-signé ou émetteur non approuvé
NET::ERR_CERT_AUTHORITY_INVALID signifie que la chaîne ne mène pas à une racine de confiance, généralement parce que le certificat est auto-signé ou provient d'une AC privée. C'est acceptable pour des tests internes mais pas pour un site public : remplacez-le par un certificat d'une AC publique. La même erreur peut apparaître quand un antivirus ou un proxy d'entreprise intercepte le HTTPS.
Contenu mixte
Le certificat est valide, mais la page charge des scripts ou des images en http:// simple. Mettez ces URL à jour en HTTPS et envisagez un en-tête HSTS pour que les navigateurs utilisent toujours HTTPS.
openssl s_client -connect example.com:443 -servername example.com affiche toute la chaîne envoyée par le serveur.Foire aux questions
HTTPS signifie-t-il qu'un site est sûr ?
Non. HTTPS signifie que votre connexion au site est chiffrée et que le site contrôle le domaine affiché. Les sites de phishing peuvent avoir des certificats DV valides, et c'est bel et bien le cas. Vérifiez toujours le nom de domaine lui-même.
Les certificats gratuits sont-ils moins sûrs que les certificats payants ?
Non. Un certificat DV gratuit de Let's Encrypt offre le même chiffrement qu'un certificat payant. Les certificats payants peuvent ajouter une validation d'identité (OV/EV), des garanties ou une assistance, mais pas un chiffrement plus fort.
Combien de temps dure un certificat SSL ?
Les certificats Let's Encrypt durent 90 jours. Les autres AC publiques sont soumises au maximum fixé par le CA/Browser Forum, qui est raccourci par étapes à partir de 200 jours en 2026. Le renouvellement automatique est l'approche la plus sûre.
Quel port utilise HTTPS ?
HTTPS utilise par défaut le port TCP 443, alors que le HTTP simple utilise le port 80. Consultez notre guide des ports réseau courants pour en savoir plus.