Le certificat SSL d'un site, de la demande au renouvellement

Un certificat SSL chiffre chaque donnée échangée entre un site web et ses visiteurs, et prouve au navigateur que le serveur détient la clé privée du nom de domaine inscrit dans la barre d'adresse. Délivré par une autorité de certification, il active le cadenas, le protocole HTTPS et la sécurité de chaque information saisie.

Que fait un certificat SSL, concrètement ?

Un certificat SSL est un fichier numérique au format X.509, installé sur le serveur web qui héberge un site. Il contient le nom de domaine protégé, une clé publique, l'identité de l'autorité de certification qui l'a signé, une date d'expiration et la signature de cette autorité, tiers de confiance reconnu par les navigateurs. Quand un utilisateur tape l'adresse d'un site internet, son navigateur reçoit ce certificat avant toute autre information et s'en sert pour établir, selon le protocole TLS, une connexion sécurisée où chaque donnée circule chiffrée.

Le certificat SSL remplit trois fonctions distinctes. La première est le chiffrement : les données qui circulent entre le visiteur et le serveur (mots de passe, formulaires de contact, numéros de carte bancaire, cookies de session) deviennent illisibles pour quiconque les intercepte, par exemple sur un réseau wifi public. La deuxième est l'authentification : le navigateur vérifie que le serveur détient la clé privée associée au nom de domaine du site, ce qui empêche un tiers de se faire passer pour lui. La troisième est l'intégrité : une donnée modifiée en route est détectée et rejetée.

Sans certificat, un site reste accessible en HTTP, mais Chrome affiche la mention « Non sécurisé » devant l'adresse de toutes les pages HTTP depuis sa version 68, sortie en juillet 2018. Firefox, Safari et Edge appliquent des avertissements comparables, plus visibles encore dès qu'une page contient un champ de mot de passe ou de paiement. Pour un site d'entreprise, une boutique ou un simple blog, ce message suffit à faire fuir une partie des visiteurs avant même la lecture de la première ligne.

Le certificat ne chiffre pas les fichiers stockés sur le serveur ni la base de données : il protège le trajet, pas le stockage. Cette nuance explique pourquoi un site en HTTPS peut tout de même subir une fuite d'informations si son application ou son hébergement présente une faille.

Du point de vue de l'utilisateur, la différence entre un site web sécurisé et un site en clair tient au préfixe https:// (HyperText Transfer Protocol Secure) et à l'icône du cadenas. Pour le propriétaire, utiliser un certificat SSL protège également les informations sensibles de l'administration du site : identifiants du back-office, données des clients, numéros de carte transmis au prestataire de paiement. L'utilisation du HTTPS conditionne aussi plusieurs fonctions récentes du web, comme la géolocalisation dans le navigateur, les service workers ou le protocole HTTP/2, que les navigateurs n'activent que sur un canal chiffré. Un site sans certificat se prive donc de technologies qui accélèrent l'affichage, en plus d'exposer chaque utilisateur à une interception de ses informations.

SSL ou TLS : pourquoi l'ancien nom reste dans l'usage

Le protocole SSL, pour Secure Sockets Layer, est né chez Netscape au milieu des années 1990. Ses versions successives présentaient des failles, et l'IETF a publié en 1999 son successeur, TLS (Transport Layer Security), dont la version 1.0 reprend largement l'architecture de SSL 3.0. Le standard actuel, TLS 1.3, date d'août 2018 (RFC 8446) ; TLS 1.2 reste largement accepté. L'IETF a déclaré SSL 3.0 obsolète en 2015 (RFC 7568), puis TLS 1.0 et 1.1 en 2021 (RFC 8996).

Aucun serveur web correctement configuré n'utilise donc encore le protocole SSL proprement dit. Le mot a pourtant survécu dans le langage courant, dans les offres des hébergeurs et dans les panneaux de gestion, si bien que « certificat SSL », « certificat TLS » et « certificat SSL/TLS » désignent exactement le même objet. Le certificat lui-même ne dépend d'ailleurs pas de la version du protocole : un fichier X.509 récent sert aussi bien sous TLS 1.2 que sous TLS 1.3. La version négociée se règle dans la configuration du serveur, pas au moment de l'achat du certificat.

Sur un hébergement mutualisé, l'hébergeur gère ce réglage pour tous ses clients. Sur un serveur administré soi-même, la configuration recommandée en 2026 n'accepte que TLS 1.2 et TLS 1.3, avec des suites de chiffrement modernes comme AES-GCM ou ChaCha20. Un test en ligne de configuration TLS signale en une minute une version ancienne restée active.

Comment le navigateur vérifie un certificat SSL en quelques millisecondes

La vérification d'un certificat SSL se déroule pendant la « poignée de main » TLS, l'échange qui précède l'affichage de la page. Le serveur envoie son certificat, le navigateur le contrôle, puis les deux parties s'accordent sur une clé de session qui chiffre la suite de la connexion. L'ensemble prend une fraction de seconde et reste invisible pour l'utilisateur, sauf en cas de problème.

Clé publique, clé privée et signature numérique

Un certificat repose sur une paire de clés liées mathématiquement. La clé publique figure dans le certificat et circule librement ; la clé privée reste sur le serveur et ne doit jamais en sortir. Ce que l'une chiffre, seule l'autre peut le déchiffrer, et une signature produite avec la clé privée se vérifie avec la clé publique. Pendant l'échange, le serveur prouve qu'il possède la clé privée correspondant au certificat présenté : un imposteur qui aurait copié le fichier public ne pourrait pas réussir cette étape. Les algorithmes courants sont RSA, avec une clé de 2048 bits au minimum, et les courbes elliptiques (ECDSA), plus légères pour un niveau de sécurité équivalent.

La clé de session qui chiffre ensuite les échanges est symétrique et générée à chaque connexion. Avec TLS 1.3, l'échange de clés offre la confidentialité persistante : même la fuite ultérieure de la clé privée du serveur ne permet pas de déchiffrer les sessions enregistrées auparavant.

La chaîne de confiance jusqu'à l'autorité racine

Le navigateur ne connaît pas chaque site, mais il connaît une liste restreinte d'autorités racines, intégrée au système d'exploitation ou au navigateur lui-même. Le certificat du site est signé par une autorité intermédiaire, elle-même signée par une racine de cette liste. Le navigateur remonte cette chaîne de signatures ; si elle aboutit à une racine connue, que les dates sont valides et que le nom de domaine correspond à l'URL visitée, le cadenas s'affiche.

Le serveur doit envoyer le certificat du site accompagné des certificats intermédiaires. Une chaîne incomplète passe souvent sur un ordinateur de bureau, qui sait parfois retrouver l'intermédiaire manquant, et échoue sur certains téléphones ou outils en ligne de commande. Depuis 2018, Chrome exige en outre que tout certificat public figure dans les journaux publics de Certificate Transparency : chacun peut ainsi consulter la liste des certificats émis pour un domaine, sur crt.sh par exemple.

DV, OV, EV : quel type de certificat pour quel site ?

Le type d'un certificat SSL correspond au niveau de vérification que l'autorité de certification mène avant de le délivrer. Le chiffrement est identique dans les trois cas ; seule change l'identité contrôlée, et donc l'information inscrite dans le certificat.

Chrome et Firefox ont retiré en 2019 l'affichage du nom de l'entreprise en vert dans la barre d'adresse pour les certificats EV. L'identité vérifiée reste lisible en cliquant sur l'icône à gauche de l'URL, mais presque aucun visiteur ne fait cette démarche. Pour un site vitrine ou une boutique de taille modeste, un certificat DV protège les échanges aussi bien qu'un OV ou un EV.

Domaine unique, multidomaine ou wildcard

Un certificat se distingue aussi par le nombre de noms qu'il couvre. Le certificat à domaine unique protège un nom précis, souvent livré avec sa variante en www. Le certificat multidomaine, appelé SAN ou UCC, liste plusieurs noms dans un seul fichier : exemple.fr, exemple.com et boutique-exemple.fr par exemple. Le certificat wildcard, noté *.exemple.fr, couvre tous les sous-domaines d'un même niveau (blog.exemple.fr, mail.exemple.fr), mais ni exemple.fr lui-même s'il n'est pas ajouté, ni un sous-domaine de second niveau comme api.test.exemple.fr. Une organisation qui crée régulièrement des sous-domaines y trouve un moyen de gestion plus simple, au prix d'un risque plus large si la clé privée fuit.

Certificat SSL gratuit ou payant : ce que l'argent achète vraiment

Un certificat SSL gratuit chiffre exactement comme un certificat payant. Let's Encrypt, autorité de certification à but non lucratif lancée en 2015, délivre gratuitement des certificats DV que la plupart des hébergeurs installent d'un clic, et d'autres autorités comme ZeroSSL ou Google Trust Services proposent des offres comparables. D'après la foire aux questions de Let’s Encrypt, ses certificats par défaut restent valides 90 jours, et l'organisme recommande de les renouveler tous les 60 jours. Il ne délivre ni OV ni EV.

Le prix d'un certificat payant varie surtout selon trois critères : le niveau de validation (un EV coûte nettement plus qu'un DV), le nombre de noms couverts (un wildcard ou un multidomaine se situe dans le haut de la fourchette) et les services associés. Un certificat SSL premium se justifie dans quelques cas précis :

• un besoin d'identité vérifiée, OV ou EV, imposé par un client, un marché public ou une politique interne ;
• une garantie financière de l'autorité en cas d'erreur d'émission de sa part ;
• un support technique humain pour l'installation, utile à une équipe sans expert système ;
• des équipements anciens ou spécialisés qui ne reconnaissent pas les autorités récentes.

Hors de ces situations, acheter un certificat DV n'apporte aucun chiffrement supérieur. Le « sceau de confiance » que certaines offres permettent d'afficher sur le site relève de la présentation commerciale : il n'ajoute rien à la sécurité de la connexion. Avant de payer, mieux vaut vérifier si l'hébergeur inclut déjà un certificat gratuit renouvelé automatiquement dans son offre, ce qui est le cas chez la quasi-totalité des hébergeurs mutualisés.

Pour obtenir un certificat SSL payant, le parcours passe par un revendeur ou directement par l'autorité : commande, envoi de la demande de signature, validation, puis téléchargement du certificat et des intermédiaires. Un certificat émis ne se modifie pas : ajouter un nom impose une réémission, en général sans supplément de prix pendant la durée de l'abonnement. Le prix d'un abonnement pluriannuel couvre désormais plusieurs certificats successifs, puisque chaque certificat ne vit que quelques mois ; l'aide d'un outil de renouvellement reste nécessaire avec une offre payante comme avec une offre gratuite.

Obtenir et installer un certificat SSL, étape par étape

Obtenir un certificat SSL suit toujours la même logique : générer une paire de clés, prouver à l'autorité que l'on contrôle le domaine, recevoir le certificat signé, puis l'installer sur le serveur. La difficulté varie seulement selon la part que l'hébergeur automatise.

Chez un hébergeur mutualisé

Chez un hébergeur mutualisé, l'activation se fait dans le panneau de gestion : il suffit de cocher le domaine et l'option HTTPS, le certificat est émis en quelques minutes et renouvelé seul. Une condition s'impose : le nom de domaine doit déjà pointer vers l'hébergement, car l'autorité vérifie le contrôle du domaine en interrogeant le serveur. Un domaine encore en cours de transfert ou dont les DNS désignent l'ancien hébergeur bloque l'émission ; le problème se règle en corrigeant les enregistrements puis en relançant la demande.

Sur un serveur web administré soi-même

Sur un serveur web que l'on administre, la méthode classique consiste à créer une demande de signature de certificat (CSR, pour Certificate Signing Request) avec OpenSSL. Ce fichier contient la clé publique et le nom de domaine ; la clé privée reste sur la machine. L'autorité vérifie ensuite le domaine, signe le certificat et le renvoie.

Avec une autorité gratuite, le protocole ACME (RFC 8555) automatise toute la procédure. Un client ACME comme Certbot, publié par l'Electronic Frontier Foundation, demande le certificat, prouve le contrôle du domaine, place les fichiers dans la configuration d'Apache ou de Nginx et programme le renouvellement. La validation de domaine passe par l'un de ces défis :

• HTTP-01 : le client dépose un fichier dans le répertoire /.well-known/acme-challenge/ du site, que l'autorité télécharge sur le port 80 ;
• DNS-01 : le client crée un enregistrement TXT nommé _acme-challenge dans la zone du domaine, seule méthode admise par Let's Encrypt pour un wildcard ;
• TLS-ALPN-01 : la preuve passe par une connexion TLS sur le port 443, une option plus rare.

Les réglages du passage au HTTPS

Le certificat installé ne suffit pas : le passage au HTTPS demande ensuite plusieurs réglages. Toutes les adresses en http:// doivent rediriger vers leur version https:// par une redirection 301. Les images, scripts et feuilles de style encore appelés en http:// provoquent un avertissement de contenu mixte et doivent passer en https://. L'en-tête HSTS (Strict-Transport-Security) indique ensuite au navigateur de ne plus jamais tenter de connexion en clair. Enfin, l'adresse du site se met à jour dans l'outil de statistiques et dans la Search Console.

Google présente le HTTPS comme un signal de classement depuis août 2014, un signal léger mais qui s'ajoute aux autres critères techniques détaillés dans l'article sur le rôle de l’hébergement dans le référencement. Une migration mal menée, avec des redirections en chaîne ou des pages en double, coûte davantage de trafic que le cadenas n'en rapporte.

Durée de validité : 200 jours en 2026, 47 jours en 2029

La durée de validité maximale d'un certificat SSL public baisse par paliers. Le CA/Browser Forum, qui réunit autorités de certification et éditeurs de navigateurs, a adopté en avril 2025 un calendrier de réduction : 200 jours au plus pour un certificat émis à partir du 15 mars 2026, 100 jours à partir du 15 mars 2027, puis 47 jours à partir du 15 mars 2029. Auparavant, la limite atteignait 398 jours, soit un peu plus d'un an.

Pour un site qui achetait un certificat chaque année et l'installait à la main, cette règle change la gestion quotidienne : deux renouvellements par an dès 2026, près de huit en 2029. L'automatisation par ACME, déjà la norme chez les hébergeurs, devient la seule méthode raisonnable. Let's Encrypt prévoit lui aussi de réduire la durée par défaut de ses certificats, avec un objectif de 45 jours en 2028.

Ce raccourcissement répond à un problème de sécurité : un certificat compromis ou émis par erreur reste dangereux jusqu'à son expiration, et la révocation fonctionne mal en pratique, car de nombreux navigateurs ne la contrôlent pas en ligne. Une durée courte limite la fenêtre d'exposition. Let's Encrypt a d'ailleurs cessé en 2025 d'envoyer des e-mails d'alerte avant expiration : la surveillance repose désormais sur l'hébergeur ou sur un outil choisi par le propriétaire du site.

Pour une entreprise qui gère des dizaines de certificats SSL, la réduction des durées impose un inventaire : quels certificats protègent quels sites web, quelle autorité les délivre, quel outil les renouvelle, qui reçoit l'alerte en cas d'échec. Les certificats oubliés se cachent souvent hors du site principal : interface d'un routeur, serveur de messagerie, outil interne, sous-domaine de test. Chaque certificat absent de l'inventaire devient une panne programmée et un risque pour la sécurité des informations qu'il protège. Les éditeurs de solutions de gestion du cycle de vie des certificats proposent ce suivi centralisé ; une petite structure s'en sort avec un tableur tenu à jour et une sonde de surveillance par site web.

Vérifier un certificat SSL et diagnostiquer une erreur

Pour vérifier un certificat SSL, le plus simple consiste à cliquer sur l'icône à gauche de la barre d'adresse, puis sur les détails de la connexion. Le navigateur affiche l'autorité émettrice, les noms couverts et la date d'expiration du certificat SSL, autant d'éléments qui fondent l'authentification du serveur. Un outil en ligne de test TLS va plus loin : chaîne complète ou non, versions du protocole acceptées, suites de chiffrement, présence de HSTS. En ligne de commande, openssl s_client donne les mêmes informations.

Un certificat SSL expiré reste la panne la plus fréquente. Le navigateur bloque alors l'accès derrière une page d'alerte que peu de visiteurs franchissent. Le renouvellement automatique échoue souvent sans bruit : changement de DNS, domaine déplacé chez un autre prestataire, port 80 fermé par erreur, règle de pare-feu modifiée. Un service de surveillance qui contrôle la date d'expiration et alerte une à deux semaines avant l'échéance évite cette mauvaise surprise.

D'autres messages d'erreur reviennent souvent, chacun avec sa cause :

• « NET::ERR_CERT_COMMON_NAME_INVALID » : le certificat couvre exemple.fr mais pas www.exemple.fr, ou l'inverse ;
• « NET::ERR_CERT_AUTHORITY_INVALID » : certificat auto-signé ou chaîne intermédiaire absente ;
• cadenas barré ou absent : une ressource de la page reste appelée en http:// ;
• erreur sur certains appareils seulement : chaîne incomplète, ou système trop ancien pour reconnaître la racine.

Le propriétaire d'un domaine peut enfin limiter les autorités autorisées à délivrer un certificat pour son site grâce à un enregistrement CAA, l'un des enregistrements de la zone DNS que les autorités consultent avant chaque émission. Un CAA mal rédigé, qui oublie l'autorité utilisée par l'hébergeur, fait échouer le renouvellement : c'est une cause d'expiration à garder en tête lors d'un changement de prestataire.

Ce que le cadenas ne garantit pas

Le cadenas signifie « connexion chiffrée vers le bon domaine », pas « site de confiance ». Un site d'hameçonnage obtient sans difficulté un certificat DV valide pour son propre domaine, par exemple un nom proche de celui d'une banque. Les campagnes de phishing utilisent massivement le HTTPS, précisément parce que beaucoup d'internautes associent encore le cadenas à la sécurité du site. Vérifier le nom de domaine exact dans l'URL protège bien mieux que de chercher l'icône.

Le certificat ne protège pas non plus le serveur lui-même : une extension WordPress vulnérable, un mot de passe d'administration faible ou une base de données mal configurée restent exploitables en HTTPS. Les autres briques de sécurité de l'hébergement, des sauvegardes aux mises à jour, font l'objet d'articles séparés dans le blog consacré à l’hébergement.

Enfin, un certificat SSL n'a aucune valeur juridique de signature. Un certificat de signature électronique, délivré à une personne ou à une entreprise par un prestataire de services de confiance, sert à signer des documents ou des marchés publics ; le règlement européen eIDAS encadre son usage et lui donne, dans sa version qualifiée, une valeur équivalente à la signature manuscrite. Ce certificat électronique se loge souvent sur une carte à puce ou une clé USB cryptographique, au nom d'une personne identifiée.Les deux objets reposent sur la même technique de clés, mais leur rôle et le droit qui les encadre diffèrent complètement.

Cinq questions sur le cadenas, le wildcard et l'expiration

Un certificat SSL est-il obligatoire pour un site web ?

Aucune loi n'impose un certificat SSL à tous les sites, mais le RGPD exige de sécuriser les données personnelles, ce qui rend le HTTPS indispensable dès qu'un formulaire collecte un nom, un e-mail ou un paiement. Les navigateurs, eux, marquent toute page HTTP comme non sécurisée.

Que se passe-t-il quand un certificat SSL expire ?

Un certificat expiré déclenche une page d'alerte dans le navigateur et bloque la plupart des visiteurs. Les données ne fuient pas pour autant, mais le site devient de fait inaccessible jusqu'au renouvellement, qui prend quelques minutes une fois la cause trouvée.

Un certificat wildcard couvre-t-il le domaine principal ?

Un certificat wildcard *.exemple.fr ne couvre pas exemple.fr par défaut. L'autorité ajoute généralement le domaine nu comme second nom dans le même fichier, mais il faut le vérifier dans les détails du certificat avant de l'installer.

Peut-on utiliser le même certificat sur plusieurs serveurs ?

Un certificat SSL s'installe sur autant de serveurs que nécessaire, à condition d'y copier aussi sa clé privée, ce qui multiplie les points d'exposition. Avec ACME, générer un certificat distinct par serveur reste plus sûr et ne coûte rien.

Un certificat auto-signé suffit-il ?

Un certificat auto-signé chiffre la connexion, mais aucune autorité reconnue ne le garantit : les navigateurs affichent une alerte. Il convient à un serveur de test ou à un réseau interne, jamais à un site public.