Un certificat TLS (successeur du SSL) associe une clé cryptographique à l’identité d’un serveur. Sa validité ne se résume pas à une date : le navigateur contrôle la chaîne de confiance, le nom de domaine couvert et le statut de révocation avant d’autoriser la connexion chiffrée. Vérifier un certificat, c’est reproduire ces contrôles pour s’assurer qu’aucun maillon ne manque.
Le champ subjectAltName, premier contrôle à ne pas négliger
Depuis 2017, les navigateurs ne se fient plus au champ Common Name pour vérifier qu’un certificat correspond au domaine visité. Le champ qui fait foi s’appelle subjectAltName (SAN). Un certificat encore dans sa période de validité sera refusé si le domaine consulté n’apparaît pas dans cette liste.
A lire en complément : Quels sont les trois types de protection ?
Ce point explique des erreurs fréquentes après un changement de sous-domaine ou un ajout de service. Le certificat n’a pas expiré, mais il ne couvre tout simplement pas le nom d’hôte demandé par le navigateur.
Pour lire le SAN dans un navigateur, cliquez sur le cadenas (ou l’icône de sécurité) dans la barre d’adresse, puis affichez les détails du certificat. Sous la section « Extensions », la ligne « Subject Alternative Name » liste tous les domaines et sous-domaines couverts. Si votre domaine n’y figure pas, le certificat est techniquement invalide pour cette adresse.
A découvrir également : Comment savoir si mon ordinateur est protégé par un antivirus ?
Chaîne de confiance et magasin de racines : pourquoi deux appareils donnent des résultats différents
Un certificat TLS n’est jamais validé isolément. Le navigateur remonte une chaîne : certificat du serveur, certificat intermédiaire, puis certificat racine stocké localement dans un magasin de confiance. Si un seul maillon manque ou n’est pas reconnu, la connexion est rejetée.
Le détail à retenir : chaque plateforme gère son propre magasin de racines. Chrome utilise le Chrome Root Store sur la plupart des systèmes, mais s’appuie sur le magasin Apple quand il tourne sur iOS. Firefox embarque son propre magasin, indépendant du système d’exploitation.
Deux conséquences pratiques :
- Un certificat accepté sur un poste Windows avec Chrome peut être refusé sur un ancien terminal Android dont le magasin de racines n’a pas été mis à jour.
- Une autorité de certification retirée d’un magasin de racines rend invalides tous les certificats qu’elle a émis, même ceux dont la date d’expiration n’est pas atteinte. Chrome a par exemple cessé d’accepter certains certificats Entrust et AffirmTrust émis après le 11 novembre 2024, à partir de Chrome 131.
- Tester la validité d’un certificat sur un seul navigateur ou un seul appareil ne garantit rien pour l’ensemble de vos visiteurs.
Vérifier la révocation d’un certificat TLS : CRL ou OCSP
Un certificat peut être révoqué avant sa date d’expiration, par exemple après une compromission de clé privée ou un changement d’identité de l’organisation. Deux mécanismes permettent au navigateur de vérifier ce statut.
OCSP et son recul progressif
Le protocole OCSP (Online Certificate Status Protocol) interroge en temps réel un serveur de l’autorité de certification. Le navigateur envoie le numéro de série du certificat et reçoit une réponse signée : valide, révoqué ou inconnu.
Depuis le ballot SC-063v4 du CA/Browser Forum, l’OCSP est devenu facultatif pour les certificats TLS publics à compter du 15 mars 2024. Les autorités de certification ne sont plus tenues de maintenir un répondeur OCSP.
Les CRL comme point de contrôle principal
Les listes de révocation de certificats (CRL) prennent le relais. Le même ballot a rendu leur publication obligatoire. Une CRL est un fichier signé par l’autorité de certification, contenant les numéros de série des certificats révoqués.
En pratique, si vous administrez un serveur ou un outil de supervision, vérifiez quel mécanisme de révocation votre autorité publie réellement. Un outil qui ne consulte que l’OCSP risque de ne plus détecter un certificat révoqué si l’autorité a cessé de répondre via ce protocole.
Certificat SSL expiré ou bientôt à 47 jours : ce qui change pour la gestion
La date d’expiration reste le contrôle le plus visible. Un certificat expiré déclenche un avertissement bloquant dans tous les navigateurs, et aucune manipulation utilisateur ne rétablit la confiance sans intervention sur le serveur.
Le CA/Browser Forum a voté un raccourcissement progressif de la durée maximale des certificats TLS publics, avec un objectif de 47 jours. Ce calendrier change la donne pour quiconque gère des certificats manuellement : un certificat valable quelques semaines au lieu de plusieurs mois exige une automatisation du renouvellement.
Vérifier la date d’expiration depuis le navigateur
Dans Chrome, cliquez sur l’icône située à gauche de l’URL, puis « La connexion est sécurisée », et enfin « Le certificat est valide ». L’onglet « Général » affiche les dates « Valide du » et « Valide jusqu’au ». Dans Firefox, le chemin est similaire : cadenas, puis « Plus d’informations », puis « Afficher le certificat ».
Outils en ligne et ligne de commande
Des outils comme SSL Labs (Qualys) ou le vérificateur de certificat de ssl.com permettent de tester un domaine et d’obtenir un rapport complet : date d’expiration, chaîne de confiance, protocoles supportés, failles connues. En ligne de commande, la commande openssl s_client suivie de openssl x509 reste la méthode la plus directe pour extraire les informations d’un certificat distant.
Les erreurs de certificat courantes et ce qu’elles signalent
Chaque message d’erreur du navigateur pointe vers un problème précis. Comprendre la correspondance évite de chercher au mauvais endroit.
- ERR_CERT_DATE_INVALID : le certificat a expiré ou sa date de début est dans le futur. Vérifiez aussi l’horloge du poste client, un décalage de quelques minutes suffit.
- ERR_CERT_AUTHORITY_INVALID : le certificat racine n’est pas dans le magasin de confiance du navigateur. Cela peut indiquer un certificat auto-signé, un intermédiaire manquant, ou une autorité retirée du magasin (comme dans le cas Entrust mentionné plus haut).
- ERR_CERT_COMMON_NAME_INVALID : le domaine visité ne correspond à aucune entrée du subjectAltName. Fréquent après une migration de domaine ou un oubli de variante www.
- NET_ERR_CERT_REVOKED : le certificat figure dans une CRL ou a reçu une réponse OCSP « révoqué ». Seul le remplacement du certificat côté serveur résout le problème.
Un certificat valide passe ces quatre contrôles simultanément : date, chaîne de confiance, correspondance de domaine, absence de révocation. Lorsqu’un seul échoue, la connexion est considérée comme non fiable. Surveiller ces paramètres de façon régulière, surtout avec le raccourcissement annoncé des durées de vie, devient une tâche opérationnelle à part entière.
