Un certificat SSL est un petit fichier signé qui associe une clé publique à un nom de domaine. Il permet à un navigateur de vérifier qu'il communique bien avec le vrai serveur et de chiffrer le trafic échangé entre les deux. La sécurité symbolisée par l'icône du cadenas repose sur une chaîne de certificats signés numériquement, qui remonte de votre site jusqu'à une autorité de certification (CA) racine à laquelle le navigateur fait déjà confiance. Comprendre cette chaîne, ainsi que la différence entre les validations DV, OV et EV, permet de choisir beaucoup plus facilement le bon certificat et de diagnostiquer les erreurs en cas de problème.
« SSL » (Secure Sockets Layer) est l'ancienne appellation ; le protocole réellement utilisé aujourd'hui est TLS (Transport Layer Security), actuellement en version TLS 1.3 (RFC 8446). TLS 1.2 (RFC 5246) reste courant, tandis que TLS 1.0/1.1 sont officiellement obsolètes (RFC 8996). Les certificats eux-mêmes suivent le format X.509 défini dans la RFC 5280. On continue de dire « certificat SSL » par habitude, et ce n'est pas un problème : cela désigne exactement la même chose qu'un certificat TLS.
Que contient réellement un certificat SSL ?
Un certificat est un document structuré, pas simplement une clé. Il contient au minimum :
- Le sujet : le ou les noms de domaine couverts par le certificat, listés dans l'extension Subject Alternative Name (SAN) (RFC 5280 §4.2.1.6).
- La clé publique que le serveur utilisera pour établir une session chiffrée.
- L'émetteur : la CA qui a signé le certificat.
- Une période de validité : une date de début (not-before) et une date de fin (not-after).
- La signature numérique de la CA, qui rend l'ensemble vérifiable.
Les certificats publics modernes utilisent des clés RSA d'au moins 2048 bits ou des clés ECDSA (généralement P-256), et sont signés en SHA-256 ou mieux : les navigateurs ont cessé de faire confiance aux certificats signés en SHA-1 vers janvier 2017. Vous pouvez inspecter les champs, la liste SAN et la date d'expiration de n'importe quel certificat en ligne avec notre outil gratuit de vérification SSL, plutôt que de fouiller dans les outils de développement du navigateur.
Comment fonctionne la chaîne de confiance ?
Les navigateurs et les systèmes d'exploitation sont livrés avec une liste intégrée de CA racines de confiance. Une CA racine ne signe presque jamais directement le certificat de votre serveur : elle signe plutôt un certificat de CA intermédiaire, et c'est cet intermédiaire qui signe votre certificat feuille (certificat d'entité finale). C'est ce qu'on appelle la chaîne de confiance :
Root CA (trusted by the browser, kept offline)
└── Intermediate CA (signs certificates day to day)
└── Your leaf certificate (example.com)
Lorsqu'un navigateur se connecte à votre serveur, celui-ci doit présenter le certificat feuille ainsi que le ou les certificats intermédiaires ; le navigateur possède déjà la racine. Si l'intermédiaire est absent, la plupart des navigateurs afficheront une erreur de confiance même si le certificat feuille est valide, car ils ne peuvent pas reconstituer le chemin jusqu'à une racine de confiance. C'est de loin la cause la plus fréquente des erreurs « certificat non approuvé » sur un certificat par ailleurs correctement émis, et il vaut la peine de la vérifier spécifiquement après chaque renouvellement ou migration.
WarningUne chaîne mal configurée ou incomplète (intermédiaire manquant) échouera dans la plupart des navigateurs même si le certificat n'a pas expiré : vérifiez toujours la chaîne complète, et pas seulement le certificat feuille, après l'installation ou le renouvellement d'un certificat.
DV, OV ou EV : quelle est la vraie différence ?
Les trois niveaux de validation produisent un certificat qui chiffre le trafic exactement de la même manière : la différence réside entièrement dans ce que la CA vérifie à propos du demandeur avant de l'émettre.
| Niveau | Ce qui est vérifié | Délai d'émission typique | Usage courant |
|---|---|---|---|
| DV (Domain Validation) | Uniquement le contrôle du domaine (enregistrement DNS, fichier HTTP ou e-mail) | Quelques minutes, souvent automatisé | La plupart des sites web, API, services internes |
| OV (Organization Validation) | Contrôle du domaine plus identité juridique de l'organisation demandeuse | Quelques jours | Sites d'entreprise, applications destinées aux clients |
| EV (Extended Validation) | Contrôle du domaine plus vérification rigoureuse et standardisée de l'identité et de l'existence légale | De quelques jours à quelques semaines | Services financiers, sites à haut niveau d'assurance |
Une remarque pratique : la barre d'adresse verte qui distinguait autrefois les certificats EV a été supprimée par Chrome vers 2019, et les autres grands navigateurs ont suivi. Les certificats EV ne bénéficient plus d'un affichage distinct dans les navigateurs grand public ; la principale raison de choisir EV aujourd'hui relève donc d'une politique interne ou d'exigences de conformité, et non d'un signal de confiance visible pour les visiteurs. La validation DV, émise automatiquement via le protocole ACME (RFC 8555), alimente la plupart des certificats Let's Encrypt et convient parfaitement à l'immense majorité des sites.
Si vous hésitez entre des certificats DV gratuits et un certificat commercial payant pour votre configuration, nous détaillons ce compromis dans Let's Encrypt ou certificat SSL commercial : lequel vous faut-il vraiment ?
Quelle est la durée de validité d'un certificat SSL ?
La durée de vie des certificats publiquement approuvés n'a cessé de diminuer au fil des ans, sous l'impulsion des Baseline Requirements du CA/Browser Forum : de 60 mois avant 2015, elle est passée à 39 mois en 2015, puis à 825 jours (~27 mois) en 2018, et à 398 jours (~13 mois) depuis septembre 2020. Les certificats Let's Encrypt ne durent que 90 jours par défaut et sont conçus pour être renouvelés automatiquement, généralement autour du 60e jour, plutôt que manuellement.
TipLes certificats à courte durée de vie deviennent la norme dans tout le secteur ; le renouvellement manuel représente donc un risque. Automatisez-le, ou utilisez un tableau de bord qui suit l'expiration de tous les certificats que vous gérez.
Qu'est-ce que la Certificate Transparency et pourquoi est-ce important ?
La Certificate Transparency (CT) est un système de journalisation public (RFC 6962, mise à jour par la RFC 9162) qui enregistre chaque certificat publiquement approuvé émis. Chrome exige la journalisation CT pour les certificats publiquement approuvés depuis avril 2018 : un certificat non journalisé est considéré comme non fiable, même s'il a été émis par une CA légitime. Les journaux CT sont aussi un outil de sécurité utile en soi : ils vous permettent de surveiller les certificats émis pour votre domaine sans que vous les ayez demandés, ce qui peut être un signe précoce de compromission d'un compte auprès d'une CA ou d'un registrar.
Révocation et certificat wildcard : ce qu'il faut savoir
Si une clé privée est compromise, le certificat doit être révoqué avant sa date d'expiration. Il existe deux mécanismes : les listes de révocation de certificats (CRL) et l'Online Certificate Status Protocol (OCSP, RFC 6960). L'OCSP stapling permet au serveur de présenter lui-même une réponse OCSP signée et horodatée, ce qui est plus rapide et plus respectueux de la vie privée que l'interrogation directe de la CA par le navigateur.
Une idée reçue fréquente : un certificat wildcard comme *.example.com ne couvre qu'un seul niveau de sous-domaines (www.example.com, api.example.com). Il ne couvre pas le domaine apex nu example.com, ni les sous-domaines imbriqués comme dev.api.example.com. Pour ceux-ci, il vous faut des entrées SAN supplémentaires ou un certificat distinct.
Gérer ses certificats SSL chez plusieurs fournisseurs
La vraie difficulté opérationnelle avec SSL vient rarement de la compréhension des standards : elle tient au suivi des dates d'expiration et de la configuration des chaînes sur des dizaines de domaines répartis entre différents registrars et hébergeurs. Un certificat qui expire discrètement sur un serveur de préproduction peu fréquenté peut tout de même faire tomber une intégration qui en dépend. La gestion des certificats d'InfraNest suit tous les certificats que vous gérez, chez tous vos fournisseurs, dans un seul tableau de bord, et signale les expirations à venir avant qu'elles ne provoquent une panne. Si vous gérez aussi les enregistrements DNS dont dépendent les certificats pour leur validation, notre guide des types d'enregistrements DNS présente les types d'enregistrements utilisés par les CA pour la validation du contrôle de domaine.
Vérifiez dès maintenant le certificat et la chaîne actuels de n'importe quel domaine avec notre outil gratuit de vérification SSL, ou mettez en place un suivi automatisé de vos certificats avec la gestion des certificats d'InfraNest.
Questions fréquentes
#SSL et TLS, est-ce la même chose ?
SSL (Secure Sockets Layer) est l'ancien nom, désormais obsolète, du protocole ; les connexions modernes utilisent TLS (Transport Layer Security), actuellement en version TLS 1.3. On continue de dire « certificat SSL » de manière informelle pour désigner un certificat TLS.
#Ai-je besoin d'un certificat OV ou EV si je gère simplement un site web ?
Pour la plupart des sites web, un certificat DV (Domain Validation) suffit et peut être émis et renouvelé automatiquement. Les certificats OV et EV ajoutent une vérification d'identité surtout pertinente pour des raisons de conformité ou de politique interne, puisque les certificats EV ne bénéficient plus d'un affichage particulier dans les navigateurs.
#Pourquoi mon certificat apparaît-il comme non approuvé alors qu'il n'a pas expiré ?
Il s'agit généralement d'un certificat intermédiaire manquant qui rompt la chaîne de confiance, plutôt que d'un problème lié au certificat lui-même : réinstallez la chaîne de certificats complète sur votre serveur, et pas seulement le certificat feuille.
#Un certificat wildcard couvre-t-il tous les sous-domaines ?
Non : un certificat wildcard comme *.example.com ne couvre qu'un seul niveau de sous-domaines et ne couvre ni le domaine apex ni les sous-domaines imbriqués comme dev.api.example.com ; ceux-ci nécessitent des entrées SAN supplémentaires ou des certificats distincts.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
