Une erreur de certificat sur un site web vient le plus souvent d’un certificat expiré, d’un nom d’hôte non couvert, d’une chaîne intermédiaire incomplète ou d’un mauvais certificat servi par le proxy ou le serveur.
Le navigateur valide le certificat réellement présenté au point de terminaison HTTPS. Renouveler un fichier sur l’origine ne suffit pas si un CDN, un répartiteur ou un autre serveur continue de servir l’ancien certificat.
L’essentiel en 30 secondes
Relevez le code d’erreur et testez chaque nom public avec SNI, puis consignez le certificat réellement servi : sujet, SAN, émetteur, dates, empreinte et chaîne. Comparez ces données au DNS et au point de terminaison attendu avant de renouveler ou déployer quoi que ce soit.
Comment identifier la cause avant d’agir ?
Le symptôme site problème certificat peut relever de plusieurs couches. Les hypothèses « Certificat expiré » et « Nom non couvert » doivent être départagées avant toute modification.
Conservez une capture sans donnée sensible lorsque le domaine racine fonctionne mais un alias ou sous-domaine échoue. Puis changez une seule variable jusqu’à obtenir ce résultat : chaque hôte public reçoit un certificat qui le couvre.
ERR_CERT_DATE_INVALID, COMMON_NAME_INVALID et une chaîne incomplète ne se corrigent pas de la même manière. Il faut aussi séparer le certificat du navigateur vers le CDN de celui du CDN vers l’origine.
Quel diagnostic correspond au symptôme ?
| Situation | Indice décisif | Priorité |
|---|---|---|
| Certificat expiré | le navigateur affiche une erreur de date sur tous les réseaux | renouveler, déployer puis recharger le point de terminaison |
| Nom non couvert | le domaine racine fonctionne mais un alias ou sous-domaine échoue | ajouter le nom au certificat et corriger SNI ou vhost |
| Chaîne incomplète | certains navigateurs fonctionnent mais des appareils ou robots échouent | installer le bundle recommandé et retester plusieurs clients |
| CDN ou proxy | le fichier de l’origine est neuf mais le public voit une autre empreinte | déployer sur le point de terminaison public et vérifier l’origine séparément |
| Renouvellement non chargé | un nouveau fichier existe mais le certificat servi reste ancien | valider la configuration puis recharger de manière contrôlée |
Quelle procédure suivre dans le bon ordre ?
Commencez par les vérifications réversibles et conservez les données utiles avant toute réinitialisation.
Suivez la séquence de site problème certificat sans cumuler les changements. À chaque étape, consignez le résultat associé à l’hypothèse testée.
Du symptôme à une preuve contrôlable
-
Inventorier les noms
Listez domaines, sous-domaines, CDN, origine et DNS.
Contrôle : le périmètre du certificat est complet
-
Capturer le certificat servi
Relevez SAN, dates, empreinte, émetteur et chaîne avec SNI.
Contrôle : le défaut réel est documenté
-
Localiser le point de terminaison
Séparez navigateur vers CDN et CDN vers origine.
Contrôle : la couche à corriger est identifiée
-
Déployer la correction
Renouvelez, ajoutez le nom ou installez la chaîne, puis validez la configuration.
Contrôle : le changement cible la cause exacte
-
Retester et surveiller
Vérifiez plusieurs réseaux et clients, puis ajoutez une alerte d’expiration.
Contrôle : la correction est publique et durable
Ne transmettez jamais la clé privée et ne désactivez pas durablement la validation TLS pour rétablir le site. Révoquez et remplacez immédiatement toute clé exposée.
La date Not After est-elle dépassée sur le certificat servi ?
Comment le reconnaître : le navigateur affiche une erreur de date sur tous les réseaux. L’hypothèse « Certificat expiré » devient crédible car le renouvellement a échoué ou le service sert encore l’ancien fichier. Comparez ce constat au résultat propre à site problème certificat : l’empreinte et la nouvelle date sont visibles publiquement.
Réponse la moins risquée : renouveler, déployer puis recharger le point de terminaison. Le diagnostic est confirmé lorsque l’empreinte et la nouvelle date sont visibles publiquement. Ne commencez pas par changer l’horloge du serveur pour masquer l’expiration, au risque d’ajouter un second problème au premier.
Le SAN contient-il exactement le nom demandé ?
Comment le reconnaître : le domaine racine fonctionne mais un alias ou sous-domaine échoue. L’hypothèse « Nom non couvert » devient crédible car le certificat n’a pas été émis pour ce nom ou le mauvais vhost répond. Comparez ce constat au résultat propre à site problème certificat : chaque hôte public reçoit un certificat qui le couvre.
Réponse la moins risquée : ajouter le nom au certificat et corriger SNI ou vhost. Le diagnostic est confirmé lorsque chaque hôte public reçoit un certificat qui le couvre. Ne commencez pas par supposer qu’un wildcard couvre tous les niveaux, au risque d’ajouter un second problème au premier.
Tous les intermédiaires nécessaires sont-ils servis ?
Comment le reconnaître : certains navigateurs fonctionnent mais des appareils ou robots échouent. L’hypothèse « Chaîne incomplète » devient crédible car le serveur peut omettre un certificat intermédiaire. Comparez ce constat au résultat propre à site problème certificat : la chaîne complète mène à une racine de confiance.
Réponse la moins risquée : installer le bundle recommandé et retester plusieurs clients. Le diagnostic est confirmé lorsque la chaîne complète mène à une racine de confiance. Ne commencez pas par servir seulement le certificat feuille, au risque d’ajouter un second problème au premier.
Quel équipement termine réellement TLS ?
Comment le reconnaître : le fichier de l’origine est neuf mais le public voit une autre empreinte. L’hypothèse « CDN ou proxy » devient crédible car le CDN, le load balancer ou un proxy présente son propre certificat. Comparez ce constat au résultat propre à site problème certificat : edge et origine répondent selon le mode prévu.
Réponse la moins risquée : déployer sur le point de terminaison public et vérifier l’origine séparément. Le diagnostic est confirmé lorsque edge et origine répondent selon le mode prévu. Ne commencez pas par désactiver le mode strict pour cacher un certificat origine invalide, au risque d’ajouter un second problème au premier.
Le client ACME a-t-il renouvelé sans recharger le service ?
Comment le reconnaître : un nouveau fichier existe mais le certificat servi reste ancien. L’hypothèse « Renouvellement non chargé » devient crédible car le serveur conserve le certificat en mémoire jusqu’au reload. Comparez ce constat au résultat propre à site problème certificat : l’empreinte publique change sans interruption.
Réponse la moins risquée : valider la configuration puis recharger de manière contrôlée. Le diagnostic est confirmé lorsque l’empreinte publique change sans interruption. Ne commencez pas par redémarrer brutalement la production sans test, au risque d’ajouter un second problème au premier.
Quel dossier de preuve préparer avant un changement TLS ?
Dressez la liste des noms publics : domaine racine, www, sous-domaines, anciens alias et endpoints API. Pour chacun, relevez DNS, adresse ou CDN, certificat présenté avec SNI, SAN et date d’expiration. Un certificat valide pour example.com ne couvre pas automatiquement un sous-domaine à plusieurs niveaux. Ne partagez jamais la clé privée dans un ticket.
Testez depuis au moins deux réseaux et un outil externe pour éviter qu’un cache local ou une interception d’entreprise ne fausse le résultat. Comparez ensuite l’edge public et l’origine directement, uniquement si l’accès est autorisé. Si le CDN est correct mais l’origine échoue en mode strict, déployez un certificat valide sur l’origine sans affaiblir durablement le chiffrement.
Pour une chaîne incomplète, servez le certificat feuille accompagné des intermédiaires attendus, sans ajouter inutilement la racine. Vérifiez le bundle produit par l’autorité et la documentation de votre serveur. Un navigateur moderne peut parfois reconstruire une chaîne que d’autres clients ne trouvent pas, ce qui explique un défaut limité à certains appareils.
Contrôlez le renouvellement automatique : date du dernier job, sortie du client ACME, challenge DNS ou HTTP, droits du fichier et rechargement du service. Le certificat peut avoir été renouvelé sur disque sans que le processus Web ait relu le nouveau fichier. Programmez une alerte avant expiration et un test externe après chaque déploiement.
Quelles erreurs aggravent la situation ?
Réagir à « Certificat expiré » sans preuve : le risque vient du fait que changer l’horloge du serveur pour masquer l’expiration peut compliquer le diagnostic. Préférez cette réponse vérifiable : renouveler, déployer puis recharger le point de terminaison.
Réagir à « Nom non couvert » sans preuve : le risque vient du fait que supposer qu’un wildcard couvre tous les niveaux peut compliquer le diagnostic. Préférez cette réponse vérifiable : ajouter le nom au certificat et corriger SNI ou vhost.
Réagir à « Chaîne incomplète » sans preuve : le risque vient du fait que servir seulement le certificat feuille peut compliquer le diagnostic. Préférez cette réponse vérifiable : installer le bundle recommandé et retester plusieurs clients.
Réagir à « CDN ou proxy » sans preuve : le risque vient du fait que désactiver le mode strict pour cacher un certificat origine invalide peut compliquer le diagnostic. Préférez cette réponse vérifiable : déployer sur le point de terminaison public et vérifier l’origine séparément.
Comment éviter que le problème revienne ?
État de référence pour site problème certificat : gardez un cas fonctionnel opposé à le navigateur affiche une erreur de date sur tous les réseaux. Validez la mesure en vérifiant que l’empreinte et la nouvelle date sont visibles publiquement.
Couche « Nom non couvert » : isolez cette cause car le certificat n’a pas été émis pour ce nom ou le mauvais vhost répond. Validez la mesure en vérifiant que chaque hôte public reçoit un certificat qui le couvre.
Retour arrière préparé : notez comment annuler l’action suivante : installer le bundle recommandé et retester plusieurs clients. Validez la mesure en vérifiant que la chaîne complète mène à une racine de confiance.
Surveillance du signal utile : observez uniquement si le fichier de l’origine est neuf mais le public voit une autre empreinte. Validez la mesure en vérifiant que edge et origine répondent selon le mode prévu.
Ce contrôle peut être complété par notre dossier consacré à la surveillance des services exposés pour compléter site problème certificat. Une alerte d’expiration et un test externe préviennent les interruptions.
Ce contrôle peut être complété par notre dossier consacré à la notion de chaîne de confiance pour compléter site problème certificat. Le certificat feuille doit remonter par ses intermédiaires vers une racine approuvée.
Quand contacter l’hébergeur ou l’autorité de certification ?
Escaladez si le renouvellement échoue malgré le contrôle de domaine, si le CDN sert un certificat inattendu ou si la chaîne fournie par l’autorité reste incompatible. Pour documenter le problème, préparez : domaines, DNS, heure, code navigateur, certificat et chaîne servis, empreintes, point de terminaison et logs ACME expurgés. Dans ce dossier « site problème certificat », ne transmettez aucun secret à un interlocuteur non vérifié.
Contactez l’hébergeur, le fournisseur CDN ou l’autorité qui contrôle la couche en défaut. Le support peut corriger le provisioning ou le déploiement, mais ne doit jamais demander la clé privée en clair. Conservez le numéro de dossier avec la chronologie propre à site problème certificat.
Notre méthode de vérification
Les causes et actions ont été confrontées aux documentations officielles actuelles du service ou du fabricant.
Les vérifications de site problème certificat vont du test le plus réversible à l’intervention la plus engageante. Cette hiérarchie protège les éléments utiles au diagnostic.
Sources officielles
- Mozilla : codes d’erreur des certificats
- Mozilla : échec de connexion sécurisée
- Cloudflare : diagnostiquer les erreurs SSL
- Cloudflare : exigences et renouvellement des certificats
Questions fréquentes sur site problème certificat
Pourquoi le nouveau certificat n’apparaît-il pas ?
Il peut être installé sur l’origine alors qu’un CDN sert l’ancien, ou le service n’a pas rechargé le fichier renouvelé.
Un wildcard couvre-t-il tous les sous-domaines ?
Non. Un wildcard ne couvre généralement qu’un seul niveau et doit correspondre au nom demandé.
Pourquoi le site marche-t-il sur certains appareils ?
Une chaîne intermédiaire incomplète ou un magasin de confiance ancien peut produire des résultats différents.
Faut-il ajouter le certificat racine au bundle ?
En général, servez la feuille et les intermédiaires recommandés ; suivez la documentation de l’autorité et du serveur.
Que surveiller après la correction ?
Date d’expiration, empreinte publique, chaîne, noms couverts et résultat du renouvellement automatique.
