Dernière mise à jour : 14 mars 2026
Un certificat SSL/TLS lie une clé publique à un nom de domaine (et parfois à une organisation) afin que les navigateurs puissent authentifier le serveur et établir une connexion HTTPS cryptée. La plupart des sites web accessibles au public devraient utiliser des certificats TLS pour chiffrer les données sensibles (par exemple, les identifiants et les informations de paiement) en transit, et de nombreux navigateurs ainsi que des régimes de conformité rendent effectivement le HTTPS obligatoire pour les principaux flux de travail.
Qu’est-ce que SSL ?
SSL (Secure Sockets Layer) est le protocole original pour sécuriser les connexions internet. Bien que TLS (Transport Layer Security) ait supplanté le protocole SSL original (Secure Sockets Layer), « SSL » reste le terme courant pour désigner les certificats utilisés pour sécuriser le trafic web. Les certificats « SSL » modernes sont utilisés avec TLS, qui chiffre le trafic et utilise des contrôles d’intégrité afin que les données interceptées ne puissent pas être lues ou modifiées sans détection.
Comment fonctionnent les certificats SSL ?
Les certificats SSL/TLS utilisent l’infrastructure à clé publique (PKI), qui repose sur deux clés cryptographiques distinctes :
- Clé publique : Intégrée dans le certificat ; utilisée lors de la poignée de main TLS pour l’échange de clés et l’authentification du serveur.
- Clé privée : Stockée de manière sécurisée sur le serveur web ; utilisée pour déchiffrer le secret pré-maître ou prouver l’identité du serveur pendant la poignée de main.
Lorsqu’un navigateur se connecte à un site HTTPS, la poignée de main TLS fonctionne généralement ainsi :
- Demande d’identification : Le navigateur demande l’identification du serveur.
- Transfert du certificat : Le serveur envoie une copie de son certificat SSL et de sa clé publique.
- Validation et authentification : Le navigateur valide le certificat en le comparant à son magasin de racines fiables. Le serveur utilise ensuite sa clé privée pour signer sa partie des paramètres d’échange de clés. Le navigateur vérifie cette signature, confirmant l’identité du serveur.
- Échange de clés : Le client et le serveur effectuent un échange de clés éphémère (typiquement ECDHE). Les deux parties génèrent des clés temporaires et échangent les parties publiques, ce qui leur permet de calculer indépendamment un secret partagé sans jamais le transmettre sur le réseau. Ce processus assure la confidentialité persistante (forward secrecy).
- Session chiffrée établie : Les deux parties utilisent la clé symétrique de session pour chiffrer toutes les données transmises pendant toute la durée de la connexion.
À quoi servent les certificats SSL ?
En pratique, SSL/TLS (avec les certificats) fournit trois propriétés principales :
- Chiffrement : Conversion des données en clair en texte chiffré pour empêcher l’accès non autorisé pendant le transit.
- Authentification : Confirmation que le serveur appartient au propriétaire du domaine, atténuant les attaques de type homme du milieu (MITM).
- Intégrité des données : Garantie que les données n’ont pas été modifiées ou corrompues lors de la transmission via un hachage cryptographique.
Pourquoi les sites web ont-ils besoin d’un certificat SSL ?
Dans de nombreux cas, SSL/TLS est requis ou fortement attendu en raison du comportement des navigateurs et des exigences de conformité :
- Exigences des navigateurs : Les navigateurs modernes signalent les sites non-HTTPS comme « Non sécurisé » et appliquent des politiques de plus en plus restrictives : blocage du contenu mixte, prévention de l’accès aux API web modernes, et dans certains cas exigent une confirmation supplémentaire de l’utilisateur pour les téléchargements ou les soumissions de formulaire.
- Conformité réglementaire : Des cadres comme PCI-DSS, HIPAA et GDPR exigent le chiffrement des données en transit.
- Optimisation pour les moteurs de recherche (SEO) : Les moteurs de recherche comme Google utilisent HTTPS comme un léger signal de classement. Plus important encore, HTTPS permet les fonctionnalités web modernes (comme les service workers) et préserve les données de référents qui peuvent indirectement améliorer la performance SEO.
Comment implémenter et inspecter les certificats SSL
Obtenir un certificat consiste à générer une demande de signature de certificat (CSR). Sur un serveur Linux/Apache/Nginx, vous utiliseriez typiquement OpenSSL pour générer cela :
openssl req -new -newkey rsa:2048 -nodes -keyout votredomaine.key -out votredomaine.csr
Comment vérifier la date d’expiration d’un certificat SSL
Une fois un certificat installé, il est essentiel de vérifier que la configuration est correcte et que la période de validité correspond à ce que vous attendez. Vous pouvez manuellement vérifier la date d’expiration du certificat SSL et inspecter les détails du certificat en direct via la ligne de commande (CLI) en utilisant cette commande :
openssl s_client -connect votredomaine.com:443 -servername votredomaine.com | openssl x509 -noout -dates
Cette commande se connecte au serveur, récupère le certificat actif et filtre la sortie pour afficher les dates notBefore (début) et notAfter (expiration).
Pièges courants lors de l’implémentation
Même avec un certificat valide, votre site peut afficher « Non sécurisé » à cause de :
- Problèmes de chaîne intermédiaire : Si vous ne parvenez pas à installer le “CA Bundle”, le navigateur ne peut pas rattacher votre certificat à l’autorité de certification racine.
- Incohérence de nom d’hôte : Les noms alternatifs du sujet du certificat ne correspondent pas au nom d’hôte demandé (par exemple, accéder à store.example.com avec un certificat valide uniquement pour example.com).
- Contenu mixte : La page est en HTTPS, mais des images ou scripts sont chargés via HTTP non sécurisé.
Types de certificats SSL
Les certificats SSL sont catégorisés selon deux facteurs principaux : leur niveau de validation et le nombre de domaines qu’ils sécurisent. Le niveau de validation reflète la profondeur de la vérification effectuée par l’autorité de certification (CA).
Par niveau de validation
Au lieu de se contenter des définitions, utilisez ce cadre pour faire correspondre l’objectif de votre site avec le niveau de validation approprié.
Si votre objectif est… | Utilisez ce niveau de validation | Profondeur de vérification |
|---|---|---|
Vitesse et chiffrement uniquement : Blogs personnels, environnements de test, ou wikis internes. | Validation de domaine (DV) | Contrôle automatisé du DNS/Email. Délivré en quelques minutes. |
Identité de marque : Sites d’entreprise, SaaS B2B, ou pages de génération de leads. | Validation d’organisation (OV) | Revue humaine du registre commercial et de l’adresse physique. |
Maximum Trust: E-commerce, banking, or handling sensitive PII. | Validation étendue (EV) | Audit légal et opérationnel rigoureux. Fournit le plus haut niveau de garantie. |
Par nombre de domaines sécurisés
- SSL pour domaine unique : Sécurise un nom de domaine entièrement qualifié (FQDN) ou un sous-domaine (par exemple, example.com).
- SSL multi-domaines (UCC/SAN) : Sécurise plusieurs noms de domaine distincts sous un seul certificat (par exemple, com, example.org).
- SSL Wildcard : (Voir ci-dessous pour une explication détaillée).
Certificats SSL Wildcard
Un certificat SSL Wildcard sécurise un domaine principal et un nombre illimité de ses sous-domaines de premier niveau (par exemple, *.example.com) sous un seul certificat. Cela réduit la charge administrative liée à la gestion de certificats individuels pour les environnements à fort volume. Cependant, ils nécessitent une gouvernance stricte de la sécurité ; si la clé privée est compromise, tous les sous-domaines associés deviennent vulnérables.
Certificats auto-signés vs signés par une AC
Un certificat auto-signé est exactement ce que cela signifie : un certificat SSL signé par le développeur qui l’a créé plutôt que par une autorité de certification publique indépendante et fiable. Les certificats auto-signés peuvent utiliser les mêmes algorithmes cryptographiques que les certificats signés par une AC, mais les navigateurs ne leur font pas confiance par défaut et afficheront des avertissements à moins que le certificat ne soit explicitement installé comme étant de confiance. Parce qu’il n’existe pas de « chaîne de confiance » indépendante, les navigateurs affichent des avertissements de sécurité importants et rendent plus difficile (mais pas impossible) l’accès des utilisateurs aux sites avec des certificats auto-signés. Les certificats auto-signés devraient seulement être utilisés dans des environnements de développement internes privés — jamais en production.
Certificats SSL gratuits vs payants
Oui. Grâce à des initiatives comme Let’s Encrypt, obtenir un certificat de validation de domaine (DV) de base est complètement gratuit. Ces certificats gratuits utilisent le protocole ACME (Automated Certificate Management Environment) pour émettre et renouveler automatiquement les certificats via des scripts.
Bien que les certificats gratuits (comme ceux de Let’s Encrypt) offrent un chiffrement standard, ils ont généralement une période de validité de 90 jours. Cette durée plus courte nécessite un renouvellement automatisé via le protocole ACME. Si l’automatisation échoue, le certificat expirera, entraînant des avertissements de sécurité qui empêchent la plupart des utilisateurs d’accéder au site sans contourner explicitement les protections du navigateur.
Qu’est-ce que la surveillance des certificats SSL ?
Bien que comprendre le fonctionnement de SSL soit essentiel, garantir que vos certificats restent actifs et valides nécessite une supervision continue. Tout comme la surveillance DNS, la surveillance des certificats SSL vérifie automatiquement la validité des certificats (chaîne de confiance et correspondance du nom d’hôte), les seuils d’expiration et les problèmes courants de configuration TLS. La surveillance vérifie la validité, les dates d’expiration et les problèmes courants de configuration (par exemple, manques dans la chaîne intermédiaire) selon un calendrier. Des alertes peuvent prévenir votre équipe avant l’expiration afin que vous puissiez renouveler ou corriger la chaîne avant que les navigateurs ne commencent à afficher des avertissements. Pour éviter les failles de sécurité, de nombreuses organisations utilisent les meilleurs outils de surveillance des certificats SSL pour automatiser les contrôles multi-sites et les alertes en temps réel.
Pour plus de détails, voir : “Qu’est-ce que la surveillance des certificats SSL ?”
Étude de cas : le piège de l’« intermédiaire »
Un problème courant est un site qui se charge sur certains navigateurs de bureau mais affiche un avertissement de certificat sur les navigateurs mobiles. Cela se produit car les navigateurs ont des capacités différentes de construction de chaîne – certains peuvent récupérer les intermédiaires manquants via des extensions AIA ou disposent de magasins de certificats locaux plus complets, tandis que d’autres (notamment les navigateurs mobiles) exigent que le serveur fournisse la chaîne complète. Lorsque les navigateurs rencontrent la chaîne incomplète pour la première fois, ils ne peuvent pas valider le certificat. Si votre serveur est mal configuré pour n’envoyer que le certificat principal et non la chaîne intermédiaire, les utilisateurs mobiles rencontreront un mur “Votre connexion n’est pas privée”. La surveillance continue détecte immédiatement cette erreur de « chaîne incomplète », même si le site semble « correct » à votre équipe interne.
FAQ
La surveillance est-elle la même chose que la gestion des certificats ?
Non. Bien qu’une stratégie de gestion des certificats robuste (utilisant des outils comme Let’s Encrypt ou DigiCert) gère l’émission technique et le renouvellement des certificats, la surveillance est la couche de vérification indépendante. La surveillance garantit que ces processus de gestion ont été correctement exécutés et que le site reste accessible aux utilisateurs.
À quelle fréquence dois-je vérifier mes certificats ?
Les vérifications d’expiration devraient avoir lieu au moins quotidiennement. Pour les sites critiques, les contrôles de configuration et de fonctionnement devraient avoir lieu toutes les quelques minutes pour détecter les changements soudains.
Dois-je surveiller les sous-domaines ?
Oui. Les sous-domaines utilisés pour les API, les environnements de préproduction ou les outils internes sont des points de défaillance fréquents et sont souvent négligés lors des audits manuels.
Qu'est-ce que la surveillance de la transparence des certificats (CT) ?
La surveillance CT suit les journaux publics pour identifier chaque certificat émis pour votre domaine, aidant à détecter le “Shadow IT” ou l’émission non autorisée de certificats.
La surveillance SSL aide-t-elle à la conformité PCI-DSS ou SOC2 ?
Oui. La surveillance automatisée fournit la trace d’audit requise par les cadres de sécurité pour prouver le maintien des normes de chiffrement.
Puis-je surveiller les certificats sur des réseaux internes ou derrière des pare-feu ?
Oui. Des agents de surveillance privés peuvent être déployés pour suivre les certificats sur les API internes et les portails employés qui ne sont pas accessibles aux scanners publics.