Qu'est-ce qu'une chaîne de certificats SSL ? Comment ça fonctionne

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

Une chaîne de certificats SSL (également 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 (CA) racine de confiance. Chaque certificat de la chaîne est signé numériquement par celui qui se trouve au-dessus, créant un chemin vérifiable de confiance depuis votre serveur jusqu'à une CA racine à laquelle les navigateurs font déjà confiance.

Pensez-y comme une chaîne d'endossements. Le certificat de votre serveur dit « Je suis example.com. » La CA intermédiaire dit « Je me porte garante du certificat d'example.com. » La CA racine dit « Je me porte garante de cet intermédiaire. » Votre navigateur fait déjà confiance à la CA racine, donc en suivant la chaîne de signatures, il fait aussi confiance à votre serveur.

Lorsque vous visitez un site HTTPS, votre navigateur parcourt cette chaîne silencieusement en quelques millisecondes. Si chaque maillon est correct, vous voyez l'icône du cadenas. Si un maillon manque, est expiré ou invalide, vous recevez un avertissement de sécurité.

Les trois maillons de toute chaîne de certificats

La plupart des chaînes de certificats SSL comportent exactement trois niveaux. Comprendre chacun est essentiel pour résoudre les problèmes HTTPS.

Certificat Racine

Le certificat racine est l'ancre de confiance au sommet de la chaîne. Il est auto-signé, ce qui signifie 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 — cette collection s'appelle le magasin de confiance (trust store).

Il existe environ 150 CA racines auxquelles les principaux navigateurs font confiance par défaut. Des organisations comme DigiCert, Let's Encrypt (ISRG), Sectigo et GlobalSign exploitent des certificats racine. Parce que les clés racine sont si critiques, les CA les stockent dans des modules de sécurité matériels (HSM) à l'intérieur de coffres-forts physiquement sécurisés et isolés du réseau.

Certificat Intermédiaire

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

Votre serveur web doit envoyer les certificats intermédiaires avec votre certificat leaf lors du handshake TLS. Contrairement aux certificats racine, les intermédiaires ne sont pas préinstallés dans les navigateurs — si votre serveur ne les envoie pas, la chaîne se brise.

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 (la CA 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 les certificats — Votre serveur web envoie son certificat leaf plus tous les certificats intermédiaires au navigateur.

• Le navigateur construit la chaîne — Le navigateur organise les certificats dans l'ordre : leaf → intermédiaire(s) → racine. Il identifie la racine en vérifiant son magasin de confiance.

• Vérification des signatures — En partant du leaf, le navigateur vérifie que la signature numérique de chaque certificat a été créée par la clé privée du certificat suivant dans la chaîne.

• Recherche de la racine — Le navigateur confirme que le certificat racine au sommet de la chaîne existe dans son magasin de confiance intégré. Si la racine n'est pas reconnue, la vérification échoue.

• Vérifications de validité — Pour chaque certificat de la chaîne, le navigateur vérifie : non expiré, non révoqué (via CRL ou OCSP), et le domaine du certificat leaf correspond à l'URL.

Ce qui se passe après la vérification

Si toutes les vérifications réussissent, le navigateur établit une connexion chiffrée et affiche l'icône du cadenas. Si une seule vérification échoue — même sur un certificat intermédiaire — le navigateur affiche un avertissement comme « Votre connexion n'est pas privée » ou « NET::ERR_CERT_AUTHORITY_INVALID. »

C'est pourquoi toute la chaîne compte, pas seulement le certificat leaf. Un certificat intermédiaire expiré cassera HTTPS aussi sûrement qu'un certificat serveur expiré.

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 la CA 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 CA intermédiaire est compromise, seuls les certificats de cet intermédiaire sont affectés. La CA racine peut révoquer l'intermédiaire compromis et en émettre un nouveau — sans invalider tous les certificats jamais émis.

• Flexibilité opérationnelle — Les CA 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 :

openssl s_client -connect example.com:443 -showcerts 2>/dev/null | grep -E 's:|i:'

Méthode 2 : Visualiseur de certificats du navigateur

Tous les principaux navigateurs vous permettent d'inspecter la chaîne de certificats sans outils spéciaux :

• Cliquez sur l'icône du cadenas dans la barre d'adresse

• Sélectionnez « La connexion est sécurisée » → « Le certificat est valide »

• Ouvrez l'onglet « Chemin de certification » (Chrome/Edge) ou « Détails » (Firefox)

• Vous verrez la chaîne complète de la racine (haut) au leaf (bas)

Méthode 3 : Vérificateur SSL DNS Robot

Le moyen le plus rapide de vérifier la chaîne de certificats d'un site web est avec un outil en ligne. Notre Vérificateur SSL affiche la chaîne complète, les détails de l'émetteur, les dates de validité et le statut de vérification — en un seul clic. Entrez n'importe quel domaine et voyez la chaîne complète instantanément.

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 verify the first certificate » ou « incomplete certificate chain »

Cause : Votre serveur n'envoie que le certificat leaf sans l'intermédiaire. Les navigateurs de bureau contournent parfois ce problème en mettant en cache les intermédiaires de visites précédentes, mais les navigateurs mobiles et les clients API échouent presque toujours.

Solution : Téléchargez le certificat intermédiaire depuis la documentation de votre CA et ajoutez-le au fichier de certificat de votre serveur. Sous Nginx, concaténez-les en 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 »

Cause : Le certificat racine a été inclus inutilement dans la chaîne envoyée par le serveur, ou un certificat est véritablement auto-signé et ne provient pas d'une CA de confiance.

Solution : Supprimez le certificat racine du fichier de chaîne de votre serveur. Votre serveur ne doit envoyer que le leaf + intermédiaire(s). Les navigateurs ont déjà la racine dans leur magasin de confiance — l'envoyer est inutile et peut causer cette erreur.

Mauvais ordre des certificats

Message d'erreur : La vérification de la chaîne peut échouer silencieusement ou produire des avertissements « certificat non fiable ».

Cause : Les certificats dans le fichier de chaîne sont dans le mauvais ordre.

Solution : L'ordre correct est toujours : certificat leaf en premier, puis intermédiaire(s) du plus proche du leaf au plus proche de la racine. Ne jamais inclure le certificat racine.

Certificat expiré dans la chaîne

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

Cause : Un certificat intermédiaire de la chaîne a expiré. C'est moins courant mais peut arriver lorsque les CA effectuent la rotation de leurs intermédiaires.

Solution : Téléchargez le certificat intermédiaire actuel de votre CA et remplacez l'ancien. Ensuite, utilisez notre Vérificateur SSL pour vérifier la chaîne mise à jour.

Bonnes pratiques pour les chaînes de certificats

• Installez toujours les intermédiaires — Ne supposez jamais que le navigateur trouvera la solution tout seul. Configurez toujours votre serveur pour envoyer la chaîne complète (leaf + intermédiaires).

• N'envoyez pas la racine — Les navigateurs ont déjà les certificats racine. Inclure la racine gaspille de la bande passante et peut déclencher des erreurs chez certains clients.

• Respectez le bon ordre — Leaf en premier, intermédiaires ensuite, pas de racine. Certains serveurs sont stricts sur l'ordre ; d'autres le tolèrent mais peuvent être plus lents à vérifier.

• Surveillez l'expiration — Les certificats intermédiaires expirent aussi. Mettez en place des alertes ou utilisez la gestion automatisée des certificats (comme certbot avec Let's Encrypt).

• Vérifiez après les changements — Après le renouvellement d'un certificat ou un changement d'hébergement, vérifiez toujours la chaîne avec un outil comme notre Vérificateur SSL. Ce qui fonctionnait avant le renouvellement peut ne plus fonctionner si la CA a changé son intermédiaire.

• Utilisez l'OCSP Stapling — Activez l'OCSP stapling sur votre serveur pour que les navigateurs puissent vérifier le statut de révocation des certificats plus rapidement, sans contacter la CA directement.