Tout savoir sur les certificats SSL et le protocole HTTPS

IPAddress-Lookup.com · June 25, 2025

Chaque fois que vous consultez un site web et que vous voyez un petit cadenas à côté de l'adresse, ou que vous remarquez que l'URL commence par https:// au lieu de http://, vous comptez sur l'un des éléments technologiques les plus importants de l'Internet moderne : le chiffrement SSL/TLS et les certificats numériques qui le rendent possible. Ces certificats protègent discrètement vos mots de passe, vos numéros de carte bancaire, vos messages privés et vos habitudes de navigation contre toute personne susceptible d’intercepter les données sur le réseau entre vous et le serveur. Pourtant, malgré leur importance fondamentale, le fonctionnement des certificats SSL et du protocole HTTPS reste un mystère pour la plupart des gens. Ce guide lève le voile et explique, en termes simples, ce qu’est exactement le protocole SSL/TLS, comment fonctionne le chiffrement, ce qu’un certificat atteste réellement et comment votre navigateur décide de faire confiance ou non à un site.

Que sont réellement SSL et TLS ?

SSL signifie « Secure Sockets Layer », un protocole initialement conçu par Netscape au milieu des années 1990 pour sécuriser les communications entre les navigateurs Web et les serveurs. Le problème qu’il résolvait était simple à énoncer mais difficile à résoudre : le Web d’origine (HTTP) envoyait toutes les données sous forme de texte clair, lisible. Toute personne se trouvant entre vous et un site web — un point d’accès Wi-Fi malveillant, un fournisseur d’accès à Internet, un routeur compromis — pouvait lire, voire altérer, les données échangées. Le protocole SSL a enveloppé ce trafic d’une couche de cryptographie afin qu’il devienne incompréhensible pour les espions.

Le protocole SSL lui-même est désormais obsolète. Les versions SSL 2.0 et SSL 3.0 se sont avérées comporter de graves failles de sécurité et ont été retirées depuis des années. Le protocole qui assure aujourd’hui la sécurité du Web s’appelle TLS, ou Transport Layer Security. Le TLS est le successeur direct du SSL, et lorsque l’on parle de « certificat SSL », on fait presque toujours référence à un certificat utilisé avec le TLS. Le nom est simplement resté, car il était familier. L’évolution se présente comme suit :

• SSL 1.0 — jamais rendu public en raison de failles de sécurité.
• SSL 2.0 (1995) et SSL 3.0 (1996) — tous deux désormais obsolètes et désactivés partout.
• TLS 1.0 (1999) — la première version sous le nom de TLS ; également obsolète aujourd’hui.
• TLS 1.1 (2006) — retiré en même temps que la version 1.0.
• TLS 1.2 (2008) — toujours largement utilisé et considéré comme sécurisé lorsqu’il est correctement configuré.
• TLS 1.3 (2018) — la norme actuelle, plus rapide et débarrassée des anciens algorithmes faibles.

TLS 1.3 a fait l’objet d’une refonte majeure. Il a supprimé des dizaines d’options de chiffrement obsolètes qui avaient causé des vulnérabilités, et il a rationalisé l’établissement de la connexion afin que les sessions sécurisées s’établissent plus rapidement. Les navigateurs modernes négocient la version la plus élevée prise en charge par les deux parties, ce qui signifie en pratique TLS 1.2 ou 1.3.

Le rôle réel d’un certificat SSL

Un certificat SSL/TLS remplit deux fonctions distinctes, et il est important de comprendre qu’elles sont séparées. La première est le chiffrement : brouiller les données afin qu’elles ne puissent pas être lues pendant leur transit. La seconde est l’authentification, ou vérification d’identité : prouver que le serveur auquel vous vous connectez appartient bien au domaine affiché dans la barre d’adresse, et non à un imposteur qui aurait intercepté votre connexion.

Le chiffrement sans authentification serait dangereux. Vous pourriez avoir une connexion parfaitement chiffrée avec un attaquant qui se contenterait de relayer votre trafic tout en lisant tout ce qui y transite. Le certificat résout ce problème en associant une clé cryptographique à une identité vérifiée. Lorsque votre navigateur accepte un certificat, il confirme à la fois que la connexion sera privée et que l’autre partie est bien celle qu’elle prétend être. Ensemble, ces deux garanties sont ce qui rend sûrs les services bancaires en ligne, les achats et les connexions.

Cryptographie asymétrique et cryptographie symétrique

Pour comprendre le fonctionnement du protocole HTTPS, vous devez connaître deux concepts de cryptographie, qui sont plus simples qu’ils n’y paraissent.

Le chiffrement symétrique utilise une seule clé secrète partagée pour à la fois chiffrer et déchiffrer les données. Il est extrêmement rapide et efficace, ce qui le rend idéal pour chiffrer le volume important de données généré lors d’une session de navigation. Le problème est évident : les deux parties doivent disposer de la même clé, et si vous transmettez cette clé sur un réseau non sécurisé, un espion peut s’en emparer.

Le chiffrement asymétrique résout le problème du partage de clé en utilisant une paire de clés : une clé publique accessible à tous et une clé privée que le propriétaire garde secrète. Les données chiffrées avec la clé publique ne peuvent être déchiffrées qu’avec la clé privée, et inversement. Cela permet à deux inconnus de s’entendre sur un secret via un canal ouvert. Le chiffrement asymétrique est toutefois lent ; il n’est donc pas utilisé pour l’intégralité de la conversation.

Le protocole HTTPS combine le meilleur des deux mondes. Il utilise brièvement la cryptographie asymétrique, plus lente, au début de la session pour établir en toute sécurité un secret partagé, puis passe au chiffrement symétrique, plus rapide, pour le reste de la session. Cette négociation s’appelle la « poignée de main TLS ».

Fonctionnement du protocole HTTPS : présentation de la poignée de main TLS

Lorsque vous saisissez une adresse web, votre navigateur commence par résoudre le nom de domaine en une adresse IP — un processus étroitement lié au fonctionnement du DNS — puis établit une connexion avec ce serveur. Avant tout échange de pages web, la poignée de main TLS a lieu. Voici ce qui se passe, étape par étape.

1. ClientHello. Votre navigateur envoie le premier message. Il répertorie les versions TLS qu’il prend en charge, les suites de chiffrement (combinaisons d’algorithmes de chiffrement) qu’il peut utiliser, ainsi qu’une valeur aléatoire qui servira à la génération de clés. Considérez cela comme une façon de dire : « Voici qui je suis et voici ce que je sais faire. »
2. ServerHello. Le serveur répond en choisissant, parmi la liste fournie par le navigateur, la version TLS et la suite de chiffrement qu’il utilisera, puis envoie sa propre valeur aléatoire. Les deux parties s’accordent désormais sur les règles de la conversation.
3. Certificat. Le serveur présente son certificat SSL/TLS, qui contient sa clé publique et les informations d’identité signées par une autorité de certification. C’est à ce moment-là que votre navigateur vérifie que le certificat est valide, fiable et émis pour le domaine que vous visitez.
4. Échange de clés. À l’aide de la clé publique du certificat (ou d’un algorithme moderne d’accord de clés tel que Diffie-Hellman sur courbe elliptique), les deux parties dérivent en toute sécurité un secret partagé. Il est essentiel de noter qu’un espion surveillant chaque message ne peut toujours pas calculer ce secret, car la clé privée ne quitte jamais le serveur.
5. Clés de session et confirmation de fin. Les deux parties utilisent les données échangées et les deux valeurs aléatoires pour générer le même ensemble de clés de session symétriques. Chacune envoie un message « finished » chiffré avec ces clés pour prouver que la poignée de main a abouti. À partir de ce moment, l’intégralité de la conversation est chiffrée de manière symétrique — rapidement, en toute confidentialité et sans risque de falsification.

Tout ce processus s’effectue généralement en une fraction de seconde. Dans TLS 1.3, la poignée de main a été raccourcie à un seul aller-retour, et les visiteurs qui reviennent sur le site peuvent parfois reprendre la connexion encore plus rapidement. Le résultat final est un canal sécurisé sur lequel transitent vos requêtes et réponses HTTPS.

Les autorités de certification et la chaîne de confiance

La fiabilité d’un certificat dépend entièrement de celle de l’entité qui se porte garante de celui-ci. Ce rôle revient à une autorité de certification (CA) — une organisation à laquelle votre navigateur et votre système d’exploitation ont décidé de faire confiance au préalable. Lorsqu’un propriétaire de site web demande un certificat, l’AC vérifie qu’il contrôle bien le domaine (et parfois l’identité de son entreprise) avant de signer le certificat avec sa propre clé. C’est cette signature que votre navigateur vérifie.

La confiance s’organise en une chaîne composée de trois maillons :

• Certificat racine. Le sommet de la chaîne. Les certificats racines sont préinstallés dans votre navigateur et votre système d’exploitation au sein d’un « magasin de confiance ». Leurs clés privées sont conservées hors ligne sous haute sécurité, car la compromission de l’une d’entre elles mettrait en péril l’ensemble du système.
• Certificat intermédiaire. Les certificats racines ne signent pas directement les certificats de sites web. Ils signent plutôt un ou plusieurs certificats intermédiaires, qui signent ensuite les certificats des sites proprement dits. Cela permet de maintenir la précieuse clé racine isolée et de révoquer un certificat intermédiaire compromis sans affecter la racine.
• Certificat de feuille. Également appelé « certificat d’entité finale », c’est celui qui est installé sur le site web lui-même. Il est signé par un certificat intermédiaire.

Lorsque votre navigateur valide un site, il remonte cette chaîne : le certificat de feuille est signé par un certificat intermédiaire, celui-ci est signé par un autre certificat intermédiaire ou par une racine, et la racine est une racine à laquelle il fait déjà confiance. Si chaque maillon est valide et que la racine figure dans le magasin de confiance, le certificat est accepté. C’est ce qu’on appelle la « construction de la chaîne » ; une cause fréquente des erreurs « non fiable » est un serveur qui oublie d’envoyer son certificat intermédiaire, ce qui rompt la chaîne.

Types de certificats

Tous les certificats ne se valent pas. Ils diffèrent par le niveau de rigueur avec lequel l’autorité de certification (CA) vérifie le demandeur, ainsi que par le nombre de domaines qu’ils couvrent. Le tableau ci-dessous résume les principaux types.

Un point essentiel pour les utilisateurs lambda : du point de vue du chiffrement, les certificats DV, OV et EV sont identiques. Ils offrent tous la même protection robuste pour vos données. La différence réside uniquement dans la vérification de l’identité. Autrefois, les certificats EV affichaient le nom de l’entreprise en vert dans la barre d’adresse, mais les navigateurs ont largement supprimé cette distinction ; c’est pourquoi la plupart des sites utilisent aujourd’hui des certificats DV peu coûteux, voire gratuits.

Certificats « wildcard » et multi-domaines

Un certificat « wildcard » utilise un astérisque pour couvrir tous les sous-domaines d’un domaine de base — par exemple, un seul certificat pour *.example.com protège à la fois www.example.com, shop.example.com et login.example.com. Un certificat multi-domaines, parfois appelé certificat SAN ou UCC, regroupe plusieurs noms de domaine totalement différents au sein d’un même certificat. Ces deux types de certificats permettent de réduire le nombre de certificats qu’un administrateur doit gérer.

Que contient un certificat ?

Un certificat est un document structuré, dont vous pouvez examiner chaque champ. Les plus importants sont :

• Sujet. L’identité à laquelle le certificat a été délivré, principalement le nom de domaine (nom commun).
• Émetteur. L’autorité de certification qui a signé et délivré le certificat.
• Période de validité. Les dates « pas avant » et « pas après » entre lesquelles le certificat est valide.
• Noms alternatifs du sujet (SAN). La liste complète des noms de domaine couverts par le certificat. Les navigateurs modernes s'appuient sur le champ SAN, et non sur l'ancien nom commun, pour identifier le site.
• Clé publique. La partie publique de la paire de clés, utilisée lors de la négociation de connexion.
• Algorithme de signature. La méthode cryptographique utilisée par l’autorité de certification pour signer, telle que SHA-256 avec RSA ou ECDSA.
• Empreinte. Un hachage unique de l’ensemble du certificat, utile pour l’identifier avec précision.
• Numéro de série. Identifiant unique attribué par l'autorité de certification émettrice.

Lorsque votre navigateur valide un site, il vérifie que la date du jour se situe dans la période de validité, qu’une des entrées SAN correspond au domaine, que la signature est intacte et que la chaîne de certificats mène à une racine de confiance.

Expiration des certificats et raisons de la réduction de leur durée de vie

Chaque certificat a une date d’expiration, et les durées de validité ont considérablement diminué au fil des ans. Les certificats qui duraient autrefois plusieurs années sont désormais limités à environ un an, voire moins, le secteur s’orientant vers des durées de validité encore plus courtes, mesurées en semaines. Cette tendance s’explique par de bonnes raisons.

Des durées de validité plus courtes limitent les dégâts en cas de vol d’une clé privée : un certificat compromis expire tout simplement plus tôt, ce qui réduit la fenêtre d’opportunité dont un attaquant peut tirer parti. Elles garantissent également que les algorithmes cryptographiques obsolètes et les certificats révoqués ou émis par erreur soient rapidement éliminés de l’écosystème. En contrepartie, les administrateurs doivent procéder à des renouvellements beaucoup plus fréquents, ce qui explique pourquoi l’automatisation est devenue une nécessité plutôt qu’une option.

Que se passe-t-il lorsqu’un certificat n’est plus valide ?

Si une étape de la validation échoue, votre navigateur interrompt la connexion en affichant un avertissement en pleine page plutôt qu’une petite icône. Les cas d’échec les plus courants sont les suivants :

• Certificat expiré. La date du jour est postérieure à la date limite. C’est la cause la plus fréquente et cela signifie généralement que quelqu’un a oublié de le renouveler.
• Certificat auto-signé. Le certificat a été signé par sa propre clé plutôt que par une autorité de certification (CA) de confiance, il n’existe donc pas de chaîne de confiance. Cela convient pour des tests internes, mais les navigateurs le rejettent pour les sites publics.
• Non-correspondance de nom. Le domaine que vous avez visité n’apparaît pas dans la liste SAN du certificat — par exemple, un certificat destiné à un domaine est utilisé pour un autre.
• Émetteur non fiable. La chaîne de certificats remonte à une racine qui ne figure pas dans votre magasin de certificats de confiance, souvent parce qu’un certificat intermédiaire est manquant ou que l’autorité de certification n’est pas reconnue.
• Certificat révoqué. L’autorité de certification a invalidé le certificat avant son expiration, généralement en raison d’une compromission de la clé.

Dans chaque cas, le navigateur affiche un avertissement tel que « Votre connexion n’est pas privée » et bloque la page par défaut. Ces avertissements ont pour but de vous protéger : un certificat non correspondant ou non fiable peut être le signe d’une véritable attaque par interception ; il ne faut donc jamais les ignorer en cliquant dessus sans y prêter attention sur un site traitant des données sensibles.

Certificats gratuits et renouvellement automatique

L’une des évolutions les plus importantes en matière de sécurité web a été l’arrivée des certificats gratuits et automatisés. Let’s Encrypt, une autorité de certification à but non lucratif, a mis à disposition des certificats DV gratuits et, tout aussi important, entièrement automatisables grâce à un protocole appelé ACME (Automated Certificate Management Environment).

Grâce à ACME, un serveur peut prouver qu’il contrôle son domaine, demander un certificat, l’installer et le renouveler avant son expiration — le tout sans intervention humaine. C’est précisément pour cette raison que les durées de validité courtes des certificats sont pratiques : un certificat qui se renouvelle tout seul tous les deux mois ne pose aucun problème opérationnel. La combinaison de la délivrance gratuite et de l’automatisation est l’une des principales raisons pour lesquelles le protocole HTTPS est passé d’une fonctionnalité marginale à la norme quasi universelle sur le Web.

Comment vérifier le certificat d’un site

Vous n’avez pas besoin d’un logiciel spécifique pour examiner un certificat. Dans n’importe quel navigateur moderne, vous pouvez cliquer sur l’icône représentant un cadenas dans la barre d’adresse et choisir l’option permettant d’afficher les détails du certificat. Vous y trouverez le sujet, l’émetteur, les dates de validité, la liste des noms alternatifs (SAN) et l’empreinte numérique. C’est un moyen rapide de vous assurer que vous êtes bien sur le site authentique et de vérifier la date d’expiration du certificat.

Pour un aperçu plus rapide et plus détaillé — incluant la chaîne complète de certificats, l’algorithme de signature et le nombre de jours restants avant l’expiration —, vous pouvez utiliser un outil en ligne. Notre propre outil de vérification des certificats SSL vous permet de saisir n’importe quel domaine et de voir instantanément si son certificat est valide, s’il est correctement chaîné à une racine de confiance et combien de temps il reste avant son renouvellement. C’est un moyen simple de repérer un certificat sur le point d’expirer avant qu’il ne déclenche un avertissement du navigateur pour vos visiteurs.

Foire aux questions

Le protocole SSL est-il identique au protocole TLS ?

Pas exactement. SSL est l’ancien protocole, désormais obsolète, tandis que TLS est son successeur moderne et assure aujourd’hui la sécurité des sites web. Cependant, le terme « certificat SSL » est resté d’usage courant ; ainsi, dans la pratique quotidienne, « SSL » et « TLS » sont souvent utilisés de manière interchangeable, même si la technologie sous-jacente est TLS.

L'icône du cadenas signifie-t-elle qu'un site web est sûr ?

Le cadenas signifie que votre connexion au site est chiffrée et que le certificat est valide pour ce domaine. Il ne garantit pas que le site lui-même soit fiable ou exempt d’escroqueries — même les sites frauduleux peuvent obtenir des certificats DV gratuits. Considérez le cadenas comme le signe d’une connexion privée, et non comme un gage de fiabilité globale.

Les certificats SSL gratuits sont-ils aussi sûrs que les certificats payants ?

Oui, en termes de chiffrement. Un certificat DV gratuit délivré par une autorité de certification (CA) telle que Let's Encrypt offre exactement le même niveau de chiffrement qu'un certificat payant. Les certificats OV et EV payants incluent une vérification supplémentaire de l'identité de l'organisation, mais ils ne renforcent pas la sécurité de la connexion chiffrée.

Pourquoi un avertissement concernant le certificat s'affiche-t-il sur certains sites ?

Les avertissements de certificat apparaissent lorsque la validation échoue — le plus souvent parce que le certificat a expiré, ne correspond pas au nom de domaine, est auto-signé ou est lié à une autorité non fiable. Cet avertissement est un moyen pour votre navigateur de vous protéger ; sur un site traitant des mots de passe ou des paiements, vous ne devriez pas l'ignorer sans comprendre pourquoi il est apparu.

Quelle est la durée de validité des certificats SSL ?

Les certificats publics modernes ont généralement une durée de validité d’environ un an, voire moins, et le secteur s’oriente progressivement vers des durées de validité bien plus courtes. Des périodes de validité courtes réduisent le risque lié au vol de clés et obligent à abandonner les méthodes de cryptographie obsolètes. Le renouvellement automatisé via des protocoles tels que l’ACME facilite les renouvellements fréquents.

Puis-je vérifier un certificat sans consulter le site dans un navigateur ?

Oui. Des outils en ligne vous permettent de saisir un nom de domaine et de consulter les détails de son certificat, notamment l’émetteur, les dates de validité, la chaîne de confiance complète et le nombre de jours restants avant l’expiration, sans avoir à inspecter manuellement le cadenas. Cela s’avère pratique pour surveiller vos propres sites ou vérifier un domaine avant de le consulter.