Qu'est-ce que les certificats SSL ?
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 chiffré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 détails de paiement) en transit, et de nombreux navigateurs et régimes de conformité rendent effectivement HTTPS obligatoire pour les workflows clés.
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 remplacé le protocole SSL original, ‘SSL’ reste le terme courant pour 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 vérifications 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 l’échange TLS pour l’échange de clés et l’authentification du serveur.
- Clé Privée : Réside en toute sécurité sur le serveur web ; utilisée pour déchiffrer le secret pré-maître ou prouver l’identité du serveur lors de l’échange.
Lorsqu’un navigateur se connecte à un site HTTPS, la négociation TLS fonctionne généralement comme suit :
- Demande d’Identification : Le navigateur demande l’identification du serveur.
- Transfert de Certificat : Le serveur envoie une copie de son certificat SSL et de sa clé publique.
- Validation & Authentification : Le navigateur valide le certificat par rapport à son magasin de racines de confiance. 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ères (généralement ECDHE). Les deux parties génèrent des clés temporaires et échangent les parties publiques, leur permettant de calculer indépendamment un secret partagé sans jamais l’envoyer sur le réseau. Ce processus fournit une confidentialité à long terme.
- Session Chiffrée Établie : Les deux parties utilisent la clé de session symétrique pour chiffrer toutes les données transmises pendant la durée de la connexion.
À quoi servent les certificats SSL ?
En pratique, SSL/TLS (utilisant des certificats) fournit trois propriétés fondamentales :
- Chiffrement : Conversion des données en texte 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 Man-in-the-Middle (MITM).
- Intégrité des Données : Assurer que les données n’ont pas été modifiées ou corrompues pendant 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és’ et mettent en œuvre 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, exigence d’une confirmation utilisateur supplémentaire pour les téléchargements ou les soumissions de formulaires.
- Conformité Réglementaire : Des cadres tels que PCI-DSS, HIPAA et GDPR imposent le chiffrement des données en transit.
- Optimisation pour les Moteurs de Recherche (SEO) : Les moteurs de recherche comme Google utilisent HTTPS comme un signal de classement mineur. Plus significativement, HTTPS permet des fonctionnalités web modernes (comme les workers de service) et préserve les données de référence qui peuvent indirectement bénéficier à la performance SEO.
Comment mettre en œuvre et inspecter les certificats SSL
Obtenir un certificat implique de générer une Demande de Signature de Certificat (CSR). Sur un serveur Linux/Apache/Nginx, vous utiliseriez généralement OpenSSL pour générer ceci :
openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr
Comment vérifier l’expiration du certificat SSL
Une fois qu’un certificat est installé, il est crucial de vérifier que la configuration est correcte et que la période de validité est celle que vous attendez. Vous pouvez manuellement vérifier l’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 yourdomain.com:443 -servername yourdomain.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).
Erreurs Courantes de Mise en Œuvre
Même avec un certificat valide, votre site peut afficher “Non Sécurisé” en raison de :
- Problèmes de Chaîne Intermédiaire : Si vous ne parvenez pas à installer le “CA Bundle,” le navigateur ne peut pas relier votre certificat à la CA 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 HTTPS, mais des images ou des scripts sont chargés via HTTP non sécurisé.
Types de Certificats SSL
Les certificats SSL sont classés par 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 d’antécédents effectuée par l’Autorité de Certification (CA).
Par Niveau de Validation
Au lieu de simplement regarder les 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 & Chiffrement Uniquement : Blogs personnels, environnements de test ou wikis internes. | Validation de Domaine (DV) | Vérification automatisée de DNS/Email. Délivré en quelques minutes. |
Identité de Marque : Sites d’entreprise, B2B SaaS ou pages de génération de leads. | Validation d’Organisation (OV) | Examen humain du registre des entreprises et de l’adresse physique. |
Confiance maximale : E-commerce, banque ou traitement de PII sensibles. | Validation étendue (EV) | Audit juridique et opérationnel rigoureux. Fournit le plus haut niveau d’assurance. |
Par domaines sécurisés
- SSL pour un seul domaine : Sécurise un nom de domaine pleinement 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 de gestion des certificats individuels pour des environnements à fort volume. Cependant, ils nécessitent une gouvernance de sécurité stricte ; si la clé privée est compromise, chaque sous-domaine associé devient vulnérable.
Certificats auto-signés vs. Certificats signés par une CA
Un certificat auto-signé est exactement ce qu’il semble : un certificat SSL signé par le développeur qui l’a créé plutôt que par une autorité de certification publique indépendante et de confiance. Les certificats auto-signés peuvent utiliser les mêmes algorithmes cryptographiques que les certificats signés par une CA, mais les navigateurs ne leur font pas confiance par défaut et afficheront des avertissements à moins que le certificat ne soit explicitement installé comme de confiance. Comme il n’y a pas de ‘chaîne de confiance’ indépendante, les navigateurs affichent des avertissements de sécurité proéminents 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 ne devraient être utilisés que dans des environnements de développement internes et privés—jamais en production.
Certificats SSL gratuits vs. payants
Oui. Grâce à des initiatives comme Let’s Encrypt, sécuriser 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) fournissent un chiffrement standard, ils ont généralement une période de validité de 90 jours. Cette durée de vie 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 comprendre comment SSL fonctionne est essentiel, mais s’assurer que vos certificats restent actifs et valides nécessite une surveillance continue. La surveillance des certificats SSL vérifie automatiquement les points de terminaison pour la validité des certificats (chaîne de confiance et correspondance du nom d’hôte), les seuils d’expiration et les problèmes de configuration TLS courants. La surveillance des certificats vérifie la validité des certificats, les dates d’expiration et les problèmes de configuration courants (par exemple, intermédiaires manquants) selon un calendrier. Des alertes peuvent notifier 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 plus de détails, voir : “Qu’est-ce que la surveillance des certificats SSL ?”
Étude de cas : Le piège des “intermédiaires”
Un problème courant est un site qui se charge dans certains navigateurs de bureau mais affiche un avertissement de certificat sur les navigateurs mobiles. Cela se produit parce que les navigateurs ont des capacités de construction de chaîne différentes – certains peuvent récupérer des intermédiaires manquants en utilisant des extensions AIA ou disposent de magasins de certificats locaux plus complets, tandis que d’autres (en particulier les navigateurs mobiles) nécessitent 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 de feuille 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” pour 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 et le renouvellement technique des certificats, la surveillance est la couche de vérification indépendante. La surveillance garantit que ces processus de gestion sont exécutés correctement et que le site reste accessible aux utilisateurs.
À quelle fréquence devrais-je vérifier mes certificats ?
Les vérifications d’expiration doivent avoir lieu quotidiennement au minimum. Pour les sites critiques pour les affaires, les vérifications de configuration et de cœur doivent avoir lieu toutes les quelques minutes pour détecter des changements soudains.
Dois-je surveiller les sous-domaines ?
Oui. Les sous-domaines utilisés pour les API, les environnements de test 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 de certificats non autorisés.
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 cryptage.
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.