Une erreur de certificat SSL signifie que le navigateur n’a pas pu établir une connexion sécurisée digne de confiance : il s’arrête et affiche un avertissement à la place de votre site. Les causes les plus fréquentes sont un certificat expiré (NET::ERR_CERT_DATE_INVALID), un certificat qui ne couvre pas le nom de domaine (ERR_CERT_COMMON_NAME_INVALID), un certificat auquel le navigateur ne fait pas confiance (ERR_CERT_AUTHORITY_INVALID) et un serveur qui envoie une chaîne de certificats incomplète ou utilise des paramètres TLS obsolètes. Presque toutes se corrigent côté serveur, et la plus courante, l’expiration, est entièrement évitable.
Ce guide passe en revue les erreurs que voient réellement les visiteurs, la cause de chacune et la façon de la corriger, avec des commandes à lancer pour vérifier votre propre site.
Pourquoi les navigateurs bloquent la page
Quand un navigateur se connecte en HTTPS, le serveur présente un certificat. Le navigateur vérifie trois choses avant d’envoyer quoi que ce soit : que le certificat est dans sa période de validité, qu’il a été émis pour le nom d’hôte exact de la barre d’adresse, et qu’il remonte jusqu’à une autorité de certification à laquelle le navigateur fait confiance. Si l’une de ces vérifications échoue, le navigateur affiche un avertissement pleine page, comme « Votre connexion n’est pas privée ». La plupart des visiteurs partent à ce moment-là. Les clients d’API et les applications n’affichent même pas d’avertissement : ils refusent la connexion, et votre intégration tombe en panne.
Les navigateurs ne nomment pas les mêmes problèmes de la même façon. Voici la correspondance des erreurs courantes :
ProblèmeChrome et EdgeFirefoxExpiré ou pas encore valideNET::ERR_CERT_DATE_INVALIDSEC_ERROR_EXPIRED_CERTIFICATEMauvais nom d’hôteNET::ERR_CERT_COMMON_NAME_INVALIDSSL_ERROR_BAD_CERT_DOMAINÉmetteur non reconnu ou auto-signéNET::ERR_CERT_AUTHORITY_INVALIDSEC_ERROR_UNKNOWN_ISSUERProblème de protocole ou de chiffrementERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCHSSL_ERROR_NO_CYPHER_OVERLAP
Safari affiche « Cette connexion n’est pas privée » pour la plupart d’entre elles, avec les détails derrière « Afficher les détails ».
D’abord, examinez vous-même le certificat
Avant de corriger quoi que ce soit, vérifiez ce que le serveur envoie réellement. Cette commande affiche les dates de validité du certificat, son sujet et les noms d’hôte qu’il couvre :
echo | openssl s_client -connect northwind.shop:443 -servername northwind.shop 2>/dev/null \
| openssl x509 -noout -dates -subject -issuer -ext subjectAltName
L’option -servername compte. Les serveurs qui hébergent plusieurs sites choisissent le certificat en fonction du nom demandé par le client, et sans elle vous risquez de voir le mauvais. Pour voir toute la chaîne envoyée par le serveur, ajoutez -showcerts à la première commande.
NET::ERR_CERT_DATE_INVALID
Le certificat est en dehors de sa période de validité. Presque toujours, cela signifie qu’il a expiré. Plus rarement, l’horloge de l’ordinateur du visiteur est fausse, ce qui fait paraître un certificat valide expiré ou pas encore valide.
Causes typiques côté serveur :
Le renouvellement automatique a cessé de fonctionner après une migration de serveur, un changement de serveur web ou une modification DNS qui a cassé la validation du domaine.
Le certificat a été renouvelé, mais le serveur web n’a jamais été rechargé : il sert toujours l’ancien depuis la mémoire.
Le certificat a été émis à la main il y a un an pour un sous-domaine que tout le monde a oublié.
Un load balancer, un CDN ou un second serveur détient encore l’ancien certificat alors que le serveur principal a le nouveau.
Solution : renouvelez le certificat, installez-le partout où il est servi et rechargez le service. Avec Certbot, un test à blanc vous indique si le renouvellement fonctionne avant que cela ne devienne critique :
sudo certbot renew –dry-run
sudo systemctl reload nginx
Vérifiez ensuite à nouveau le certificat servi avec la commande openssl ci-dessus. Ce n’est pas le fichier sur le disque que voient les visiteurs, c’est le certificat servi.
Si un seul visiteur signale l’erreur et que le certificat est valide, demandez-lui de vérifier la date et l’heure de son appareil.
NET::ERR_CERT_COMMON_NAME_INVALID
Le certificat est valide, mais pas pour ce nom d’hôte. Les navigateurs comparent la barre d’adresse aux noms listés dans le champ Subject Alternative Name du certificat.
Causes fréquentes :
Le certificat couvre northwind.shop mais pas www.northwind.shop, ou l’inverse.
Un certificat wildcard pour *.northwind.shop est utilisé sur shop.eu.northwind.shop. Un wildcard ne couvre qu’un seul niveau.
Un nouveau sous-domaine a été pointé vers un serveur qui sert un certificat par défaut destiné à un autre site.
Un enregistrement DNS pointe vers le mauvais serveur, par exemple un ancien hébergeur ou un CDN qui n’a pas de certificat pour votre domaine.
Solution : émettez un certificat qui liste chaque nom d’hôte que vous servez, ou un certificat distinct par nom d’hôte, et vérifiez que chaque bloc server ou virtual host utilise le bon. Si le nom d’hôte ne doit pas être servi du tout, supprimez son enregistrement DNS.
NET::ERR_CERT_AUTHORITY_INVALID
Le navigateur ne fait pas confiance à l’entité qui a signé le certificat. Causes :
Un certificat auto-signé, souvent un reste de l’environnement de staging ou de l’installation par défaut d’un panneau de contrôle.
Un certificat émis par une autorité de certification privée ou interne, utilisé sur un site public.
Une chaîne incomplète sur certains clients, voir ci-dessous.
Un élément entre le visiteur et le serveur qui intercepte la connexion, comme un proxy d’entreprise ou un antivirus. Dans ce cas, seuls certains visiteurs voient l’erreur.
Solution : sur les sites publics, remplacez les certificats auto-signés et internes par un certificat émis par une autorité de certification reconnue publiquement. Les certificats gratuits de Let’s Encrypt et des services similaires sont reconnus par tous les principaux navigateurs.
Chaîne de certificats incomplète
Votre certificat est signé par un certificat intermédiaire, lui-même signé par une racine à laquelle le navigateur fait confiance. Le serveur doit envoyer votre certificat et l’intermédiaire. S’il n’envoie que votre certificat, le résultat dépend du client : certains navigateurs de bureau récupèrent eux-mêmes l’intermédiaire manquant et n’affichent aucune erreur, tandis que d’autres navigateurs, les applications mobiles, curl et les clients d’API échouent. C’est pourquoi ce problème se manifeste souvent ainsi : « chez moi ça marche, mais les webhooks du prestataire de paiement échouent ».
curl le signale ainsi :
curl: (60) SSL certificate problem: unable to get local issuer certificate
Solution : configurez le serveur avec le fichier de chaîne complète. Avec Certbot sur nginx, cela signifie fullchain.pem, et non cert.pem :
ssl_certificate /etc/letsencrypt/live/northwind.shop/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/northwind.shop/privkey.pem;
ERR_SSL_PROTOCOL_ERROR et incompatibilités de chiffrement
Ces erreurs signifient que le navigateur et le serveur n’ont pas pu s’accorder sur la façon de communiquer de manière sécurisée, avant même toute vérification du certificat. Parmi les causes : un serveur qui ne propose que d’anciennes versions de protocole comme TLS 1.0 et 1.1, que les navigateurs actuels n’acceptent plus, un port mal configuré qui parle en HTTP simple sur le 443, une configuration TLS cassée après une mise à jour, ou un pare-feu ou un proxy qui interfère avec le handshake.
Solution : activez TLS 1.2 et TLS 1.3, utilisez les paramètres de chiffrement modernes par défaut de votre serveur web ou ceux d’un générateur de configuration fiable, et vérifiez que le port 443 sert bien du TLS. Vous pouvez tester une version de protocole précise avec openssl :
openssl s_client -connect northwind.shop:443 -servername northwind.shop -tls1_2
Contenu mixte
Le contenu mixte n’est pas une erreur de certificat, mais les visiteurs le perçoivent souvent comme tel. La page se charge en HTTPS, mais certaines ressources, comme des scripts, des images, des feuilles de style ou des iframes, sont demandées en HTTP simple. Les navigateurs bloquent purement et simplement les scripts et frames non sécurisés, ce qui peut casser la mise en page ou des fonctionnalités, et peuvent afficher la page sans l’indicateur de sécurité habituel.
Solution : remplacez les URL http:// codées en dur dans vos templates, votre base de données et vos réglages par https:// ou par des URL relatives. Sur WordPress, le contenu mixte provient souvent d’anciennes URL enregistrées dans le contenu des articles après un passage en HTTPS. En filet de sécurité, l’en-tête Content-Security-Policy: upgrade-insecure-requests indique aux navigateurs de demander plutôt ces ressources en HTTPS.
Pour repérer le contenu mixte avant vos visiteurs, la surveillance des liens cassés d’Uptimecheck explore votre site et son sitemap chaque jour et signale le contenu mixte et les liens cassés page par page.
Prévenir les erreurs de certificat
La plupart des erreurs de certificat sont des erreurs de configuration que l’on corrige une fois pour toutes. L’expiration, c’est autre chose : elle revient chaque fois qu’un certificat arrive en fin de vie, et elle frappe souvent quand la personne qui a mis en place le renouvellement est partie. La prévention est une routine, pas une correction ponctuelle :
Tenez un inventaire. Listez chaque nom d’hôte qui sert du HTTPS, y compris les API, les interfaces d’administration, le staging et les sites clients.
Automatisez le renouvellement partout où c’est possible, et sachez où il reste manuel.
Vérifiez le certificat servi après chaque changement. Les migrations de serveur, les nouveaux load balancers et les modifications DNS sont les moments où les renouvellements cassent.
Surveillez les dates d’expiration pour recevoir un rappel des semaines avant qu’un certificat n’expire, quand il reste du temps pour corriger sereinement un renouvellement défaillant.
Surveillez aussi le domaine et ses enregistrements. Un domaine expiré ou un enregistrement DNS modifié casse la validation, et le site avec.
La surveillance SSL d’Uptimecheck suit la date d’expiration du certificat servi sur chaque domaine et sous-domaine que vous surveillez en HTTPS, et envoie des rappels sur vos canaux d’alerte avant son expiration. Elle est incluse dans toutes les formules. Associez-la à la surveillance de l’expiration des domaines et à la surveillance DNS, car un certificat n’est fiable que si le domaine et les enregistrements qui le portent le sont aussi. Notre guide sur la surveillance de l’expiration des certificats SSL contient une checklist complète de renouvellement, et si le navigateur ne trouve même pas votre site, lisez notre article sur DNS_PROBE_FINISHED_NXDOMAIN.
En résumé
Chaque erreur SSL correspond à un navigateur qui refuse de faire confiance à une connexion : parce que le certificat est périmé, émis pour un autre nom, signé par une entité qu’il ne connaît pas, envoyé sans sa chaîne, ou proposé via un protocole qu’il n’accepte plus. Vérifiez le certificat servi avec openssl, corrigez la configuration, rechargez le serveur et vérifiez à nouveau. Faites ensuite de l’expiration un simple rappel plutôt qu’un incident.
Uptimecheck vous prévient avant l’expiration de vos certificats et domaines, et vous alerte quand votre site cesse de répondre. Essayez-le gratuitement pendant 14 jours, sans carte bancaire.