Chaîne de certificats SSL : définition et fonctionnement

Qu'est-ce qu'une chaîne de certificats SSL ?

Une chaîne de certificats SSL (aussi appelée chaîne de confiance ou chemin de certification) est la liste ordonnée de certificats numériques qui relie le certificat SSL/TLS de votre site web à une autorité de certification (AC) racine de confiance. Chaque certificat de la chaîne est signé numériquement par celui du dessus, ce qui crée un chemin de confiance vérifiable de votre serveur jusqu'à une AC racine que les navigateurs approuvent déjà.

Voyez cela comme une chaîne de recommandations. Le certificat de votre serveur dit « Je suis example.com ». L'AC intermédiaire dit « Je me porte garante du certificat d'example.com ». L'AC racine dit « Je me porte garante de cet intermédiaire ». Votre navigateur fait déjà confiance à l'AC racine ; en suivant la chaîne de signatures, il fait donc confiance à votre serveur.

Quand vous visitez un site HTTPS, votre navigateur parcourt cette chaîne en quelques millisecondes. Si chaque maillon est valide, la page se charge sans avertissement. Si un maillon manque, a expiré ou n'est pas approuvé, vous obtenez à la place un avertissement de sécurité comme NET::ERR_CERT_AUTHORITY_INVALID.

Les trois types de certificats d'une chaîne

Chaque chaîne comporte trois types de certificats, même si un serveur peut envoyer plus d'un intermédiaire :

Certificat racine

Le certificat racine est l'ancre de confiance au sommet de la chaîne. Il est auto-signé, c'est-à-dire que l'autorité de certification a signé son propre certificat. Les certificats racine sont préinstallés dans votre navigateur et votre système d'exploitation ; cet ensemble s'appelle le magasin de confiance.

La liste de racines propre à Chrome en contient environ 100 (Chrome Root Store) ; Mozilla, Apple et Microsoft tiennent leurs propres listes. Des organisations comme DigiCert, Let's Encrypt (ISRG), Sectigo, GlobalSign et Google Trust Services exploitent des racines. Comme les clés racine ont une telle valeur, les AC les gardent hors ligne dans des modules de sécurité matériels et ne s'en servent que pour signer des intermédiaires.

Certificat intermédiaire

Les certificats intermédiaires se situent entre la racine et le certificat de votre serveur. L'AC racine signe le certificat intermédiaire, puis l'AC intermédiaire signe les certificats d'entité finale (serveur). La plupart des AC utilisent un ou deux intermédiaires.

Votre serveur web doit envoyer les certificats intermédiaires avec votre certificat leaf pendant la négociation TLS. Chrome peut télécharger un intermédiaire manquant et Firefox les précharge, mais les applications, clients d'API et anciens appareils Android n'ont ni l'un ni l'autre : pour eux, la chaîne est rompue.

Certificat leaf (certificat serveur)

Le certificat leaf (également appelé certificat d'entité finale ou certificat serveur) est le certificat installé sur votre serveur web. Il contient le nom de votre domaine, votre clé publique, la période de validité et les informations sur l'émetteur (l'AC intermédiaire qui l'a signé).

C'est le premier certificat que votre navigateur reçoit lors du handshake TLS. Le navigateur remonte ensuite la chaîne, vérifiant chaque signature jusqu'à atteindre une racine de confiance.

Comment fonctionne la chaîne de confiance

Lorsque votre navigateur se connecte à un site web via HTTPS, le handshake TLS déclenche un processus de vérification de chaîne qui se produit en quelques millisecondes :

• Le serveur envoie ses certificats — le leaf, puis les intermédiaires.
• Le navigateur construit un chemin — du leaf jusqu'à une racine de sa propre liste. Si un intermédiaire manque, Chrome le télécharge à l'adresse inscrite dans le certificat (AIA), et Firefox utilise son propre jeu préchargé ; de nombreux autres clients échouent tout simplement.
• Les signatures sont vérifiées — chaque certificat doit être signé par la clé de celui du dessus.
• La racine est vérifiée — le chemin doit se terminer sur une racine de la liste du navigateur. Une racine inconnue échoue.
• La validité est vérifiée — chaque certificat doit être dans ses dates et non révoqué, et le leaf doit couvrir le nom de la barre d'adresse.

Chaînes réelles : ce qu'envoient 12 grands sites

Nous avons demandé leurs chaînes à 12 des plus grands sites le 27 octobre 2026 (openssl s_client -showcerts, depuis deux emplacements). Aucun n'envoyait un simple leaf, et plusieurs ajoutaient des certificats signés en croisé pour que les anciens appareils atteignent encore une racine qu'ils connaissent. Ce qu'un serveur envoie peut varier selon votre version de TLS, la prise en charge d'ECDSA par votre client et l'emplacement CDN qui répond : facebook.com, par exemple, a envoyé 3 certificats en TLS 1.2.

Ce qui se passe après la vérification

Si toutes les vérifications réussissent, la connexion se poursuit. Si une seule échoue, même sur un intermédiaire, le navigateur affiche un avertissement comme « Votre connexion n'est pas privée » avec un code comme NET::ERR_CERT_AUTHORITY_INVALID. (Les échecs avant l'examen de tout certificat, pendant la négociation TLS elle-même, affichent d'autres codes : ERR_SSL_PROTOCOL_ERROR ou ERR_SSL_VERSION_OR_CIPHER_MISMATCH.)

C'est pourquoi toute la chaîne compte, pas seulement le certificat leaf. Un intermédiaire expiré casse HTTPS tout comme un certificat serveur expiré, sauf si le client peut construire un autre chemin pour le contourner.

Pourquoi les certificats intermédiaires existent

Les CA racines pourraient théoriquement signer chaque certificat serveur directement, en sautant complètement les intermédiaires. Mais il y a trois raisons critiques pour lesquelles elles ne le font pas :

• Isolation de sécurité — Les clés privées de l'AC racine sont conservées hors ligne dans des HSM à l'intérieur de coffres physiquement sécurisés. Elles ne sont utilisées que pour signer les intermédiaires, pas des millions de certificats serveur individuels. Cela réduit considérablement le risque de compromission de la clé racine.
• Confinement des dégâts — Si une AC intermédiaire est compromise, seuls les certificats de cet intermédiaire sont affectés. L'AC racine peut révoquer l'intermédiaire compromis et en émettre un nouveau — sans invalider tous les certificats jamais émis.
• Flexibilité opérationnelle — Les AC utilisent différents intermédiaires pour différentes fins : un pour les certificats DV, un autre pour les EV, des séparés pour différentes régions ou algorithmes de clé (RSA vs ECDSA).

Comment vérifier votre chaîne de certificats SSL

Il existe trois façons d'inspecter la chaîne de certificats d'un site web, des outils en ligne de commande aux vérifications dans le navigateur.

Méthode 1 : OpenSSL (ligne de commande)

La commande openssl est le moyen le plus détaillé d'inspecter une chaîne de certificats. Exécutez ceci dans votre terminal :

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

Méthode 2 : visualiseur de certificats du navigateur

Tous les principaux navigateurs affichent la chaîne qu'ils ont construite (elle peut différer de celle envoyée par le serveur, s'ils ont récupéré eux-mêmes un intermédiaire manquant) :

• Chrome : cliquez sur l'icône à gauche de l'adresse → La connexion est sécurisée → Certificat valide, puis ouvrez l'onglet Détails pour voir la hiérarchie des certificats
• Edge : cliquez sur le cadenas → « Connection is secure » → l'icône de certificat en haut du panneau
• Firefox : cliquez sur le cadenas → « Connection secure » → « More information » → « View Certificate » ; chaque certificat de la chaîne a son propre onglet
• Safari (18.4 et ultérieur) : choisissez Safari > Détails de la sécurité de la connexion dans la barre des menus (Apple) ; sur iPhone, touchez la gauche du champ d'adresse → « Privacy & Security » → « Connection Security Details »

Méthode 3 : vérificateur SSL DNS Robot

Le moyen le plus rapide de vérifier depuis l'extérieur de votre réseau est notre Vérificateur SSL : il affiche la chaîne envoyée par le serveur, si les listes de racines de Mozilla, Chrome, Apple et Microsoft l'approuvent chacune, un avertissement si la chaîne est incomplète et les dates de chaque certificat. Pour les sites derrière Cloudflare, il lit le certificat dans les journaux CT publics ; la chaîne envoyée par le serveur n'y est donc pas vérifiée.

Erreurs courantes de chaîne de certificats et comment les corriger

Les problèmes de chaîne de certificats sont l'une des causes les plus fréquentes d'erreurs HTTPS. Voici les erreurs que vous rencontrerez le plus probablement et comment résoudre chacune.

Certificat intermédiaire manquant

Message d'erreur : « unable to get local issuer certificate » (curl, Python, PHP), « unable to verify the first certificate » (Node.js) ou « incomplete certificate chain »

Cause : le serveur n'envoie que le certificat leaf. Chrome corrige souvent cela en téléchargeant lui-même l'intermédiaire (le vérificateur d'Apple aussi), si bien que le site peut sembler correct dans un navigateur alors que curl sous Linux, Python, Java, les rappels de paiement et de nombreuses applications échouent.

Solution : envoyez les intermédiaires avec le leaf. Avec Let's Encrypt, pointez votre serveur vers fullchain.pem, pas cert.pem ; avec une autre AC, téléchargez son intermédiaire et placez-le après votre certificat dans un seul fichier :

cat your-domain.crt intermediate.crt > fullchain.crt

Certificat auto-signé dans la chaîne

Message d'erreur : « self-signed certificate in certificate chain » (erreur OpenSSL 19)

Cause : la chaîne se termine par une racine que le client n'approuve pas : une AC privée ou d'entreprise, ou un proxy ou antivirus qui re-signe le trafic avec sa propre racine. Envoyer une racine que le client approuve est inoffensif, simplement inutile.

Solution : utilisez un certificat d'une AC publique pour les sites publics, ou installez la racine privée sur les clients qui en ont besoin. Omettre la racine de la chaîne du serveur est plus propre mais ne corrige pas cette erreur.

Mauvais ordre des certificats

Message d'erreur : la vérification de la chaîne échoue dans certains clients, ou ils signalent le certificat comme non approuvé.

Cause : les certificats du fichier de chaîne sont dans le mauvais ordre. TLS 1.3 exige le certificat du serveur en premier et demande le reste dans l'ordre, tout en disant aux clients de tolérer d'autres ordres (RFC 8446 §4.4.2) ; des clients plus anciens ou plus stricts peuvent ne pas le faire.

Solution : placez le certificat leaf en premier, puis chaque intermédiaire, en commençant par celui qui a signé votre leaf.

Certificat expiré dans la chaîne

Message d'erreur : « certificate has expired » — alors que la date d'expiration de votre certificat leaf semble correcte.

Cause : un certificat plus haut dans la chaîne a expiré. Le cas le plus connu : DST Root CA X3 d'IdenTrust, qui avait signé en croisé la racine de Let's Encrypt, a expiré le 30 septembre 2021, et les appareils qui n'approuvaient pas ISRG Root X1 (ainsi que les clients sous OpenSSL 1.0.x) ont commencé à échouer sur les sites Let's Encrypt.

Solution : téléchargez le certificat intermédiaire actuel auprès de votre AC et remplacez l'ancien. Utilisez ensuite notre Vérificateur SSL pour vérifier la chaîne mise à jour.

Bonnes pratiques pour les chaînes de certificats

• Envoyez toujours les intermédiaires — ne comptez pas sur les navigateurs pour réparer la chaîne ; les applications et clients d'API ne le feront pas.
• La racine est facultative — les clients utilisent leur propre copie, donc envoyer une racine qu'ils approuvent ne fait qu'ajouter des octets ; une racine signée en croisé pour les anciens appareils est une exception voulue.
• Gardez l'ordre — leaf en premier, puis les intermédiaires de celui qui a signé votre leaf vers le haut.
• Automatisez le renouvellement — les certificats émis depuis mars 2026 durent 200 jours au plus, 100 à partir de mars 2027, et Let's Encrypt passe à des certificats de 64 jours en février 2027.
• Vérifiez après chaque renouvellement ou migration — une AC peut changer d'intermédiaire entre deux renouvellements. Passez ensuite le site dans le Vérificateur SSL.
• Surveillez chaque nom — www, le domaine nu et chaque sous-domaine peuvent être servis par des certificats et des chaînes différents. La Recherche de sous-domaines liste les noms que vos certificats ont couverts, d'après les journaux de certificats publics.