Qu'est-ce qu'un certificat SSL ?
Un certificat SSL/TLS est un document numérique, signé par une autorité de certification (CA) de confiance, qui lie une clé publique à un ou plusieurs noms d'hôte. Lorsqu'un client se connecte, le serveur présente le certificat dans le cadre du handshake TLS, et le client vérifie la signature de la CA, la période de validité et qu'un des noms listés correspond à l'hôte qu'il souhaitait joindre.
Malgré le nom historique, les certificats modernes utilisent le protocole TLS (TLS 1.2 et TLS 1.3 aujourd'hui) et non l'ancien SSL. Le format de certificat X.509 et la chaîne PKI sont définis dans **RFC 5280**, avec un comportement spécifique à HTTPS dans **RFC 2818**.
Pourquoi vérifier votre certificat SSL ?
1Évitez les expirations surprises
Tout navigateur et client de messagerie moderne cesse de fonctionner dès qu'un certificat expire — surveillez les jours restants de manière proactive
2Confirmez la couverture des hôtes
Un certificat n'est valide que pour les noms d'hôte de sa liste SAN — vérifiez chaque sous-domaine servi
3Détectez les chaînes non fiables
Les certificats auto-signés ou émis par une CA inconnue déclenchent des avertissements du navigateur — découvrez-les avant vos utilisateurs
4Auditez STARTTLS pour les e-mails
Les fournisseurs de boîtes attendent que les points MX négocient TLS proprement — un certificat cassé dégrade silencieusement la délivrabilité
Comment fonctionne la vérification SSL — étape par étape
Un client ouvre une connexion TLS vers votre domaine et envoie un ClientHello.
Votre serveur renvoie sa chaîne de certificats : le certificat feuille + les éventuels certificats intermédiaires.
Le client remonte la chaîne jusqu'à une CA racine de confiance installée dans son magasin.
Il vérifie chaque signature, que chaque certificat est dans sa période de validité et qu'aucun n'est révoqué.
Enfin, il vérifie que la liste SAN du certificat feuille contient le nom d'hôte que le client souhaite atteindre.
Si chaque étape réussit, le handshake se termine et la clé de session est échangée.
Champs du certificat en un coup d'œil
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -textChamps clés du certificat
Issuer— autorité de certification ayant signé le certSubject CN— nom d'hôte principal historiqueSAN— liste moderne des noms d'hôte validesNot Before / After— période de validitéKey Usage— opérations autorisées (auth serveur, etc.)Échecs SSL courants et solutions
Certificat expiré
Renouvelez immédiatement et configurez la surveillance — la plupart des équipes alertent à 30 jours restants
Le nom d'hôte ne correspond pas
Le nom d'hôte testé ne figure pas dans le SAN — réémettez avec le nom manquant ou un wildcard correct
Certificat auto-signé
Les navigateurs les rejettent — passez à un certificat Let's Encrypt gratuit ou à un certificat managé par votre CDN
Chaîne incomplète
Si les intermédiaires manquent, certains clients ne peuvent pas vérifier la chaîne — empaquetez-les avec le feuille dans la configuration du serveur
Foire aux questions
Un vérificateur SSL/TLS confirme qu'un domaine sert un certificat valide émis par une autorité de certification de confiance, que les Subject et Subject Alternative Names couvrent le nom d'hôte testé, que le certificat est dans sa période de validité actuelle et qu'il n'est pas auto-signé. Ces vérifications combinées prouvent qu'un navigateur ou client de messagerie fera confiance à la connexion.
Dès qu'un certificat expire, tous les navigateurs affichent un avertissement de sécurité et la plupart des clients de messagerie modernes refusent STARTTLS. Laisser expirer un SSL casse à la fois le trafic web et l'envoi authentifié de courrier. Surveiller les jours restants vous donne une marge pour renouveler — la plupart des équipes alertent en dessous de 30 jours.
Le Subject CN (Common Name) est le champ historique pour un nom d'hôte unique. Le Subject Alternative Names (SAN) est une liste moderne de tous les noms d'hôte pour lesquels le certificat est valide, y compris les entrées wildcard. Navigateurs et la plupart des clients de messagerie ignorent désormais le CN et valident contre la liste SAN, donc tout nom d'hôte absent du SAN échouera à la vérification TLS.
Les certificats auto-signés ne sont pas sûrs pour un service public. Ils chiffrent la connexion mais ne fournissent aucune preuve d'identité, et les navigateurs, appareils mobiles et clients de messagerie d'entreprise les rejetteront. Ils ne sont acceptables qu'en développement, dans des services internes où vous contrôlez chaque client, ou comme étape vers l'émission d'un certificat de confiance.
L'incohérence de nom d'hôte arrive quand la liste SAN du certificat ne contient pas exactement le nom testé. Causes fréquentes : tester un sous-domaine www contre un certificat apex uniquement, manque de wildcard pour les sous-sous-domaines, ou servir par erreur le mauvais hôte virtuel sur une IP partagée. Réémettez le certificat avec les bonnes entrées SAN.
Oui, indirectement. Les fournisseurs de boîtes attendent que les points MX, l'envoi SMTP et les domaines de tracking négocient TLS avec succès. Un certificat cassé ou expiré force un repli en texte clair ou un échec de livraison, ce qui abaisse la réputation à long terme. Maintenir tous les domaines liés au courrier avec un cadenas vert fait partie d'une posture saine d'authentification.