« Votre connexion n’est pas privée » : causes et solutions

Lire le code d’erreur : il donne la réponse

Sous le message principal, le navigateur affiche un code technique. C'est lui qui identifie la cause réelle, et il vous évite de tester des solutions au hasard. ERR_CERT_DATE_INVALID signale un certificat expiré (ou une horloge fausse sur votre machine). ERR_CERT_AUTHORITY_INVALID veut dire que le certificat n'est pas signé par une autorité reconnue : certificat auto-signé, chaîne de certification incomplète, ou interception par un antivirus ou un proxy d'entreprise.

ERR_CERT_COMMON_NAME_INVALID indique que le certificat ne couvre pas le nom de domaine demandé : c'est le cas classique du certificat émis pour exemple.com alors que le visiteur arrive sur www.exemple.com. ERR_CERT_REVOKED signifie que le certificat a été révoqué avant son expiration, souvent après une compromission de la clé privée — celui-là ne doit jamais être contourné. Enfin, ERR_SSL_PROTOCOL_ERROR n'est pas un problème de certificat mais de négociation TLS, traité dans un guide à part.

Sur Firefox, les codes diffèrent (SEC_ERROR_EXPIRED_CERTIFICATE, SEC_ERROR_UNKNOWN_ISSUER, MOZILLA_PKIX_ERROR_MITM_DETECTED) mais correspondent aux mêmes causes. Notez le code avant toute chose : la suite de ce guide s'organise autour de lui.

Le message apparaît sur les sites que vous visitez

Si l'erreur surgit sur plusieurs sites différents, y compris de grands sites qui fonctionnent pour tout le monde, le problème vient de votre machine ou de votre réseau, pas des sites. Premier réflexe, et de loin le plus fréquent : vérifiez la date et l'heure de votre appareil. Un certificat est valide entre deux dates précises ; si votre horloge est décalée de plusieurs jours ou années, tous les certificats du web deviennent « invalides » de votre point de vue. Réglez la date automatiquement et rechargez.

Autres causes classiques : un antivirus qui inspecte le trafic HTTPS (Avast, Kaspersky, ESET et consorts intercalent leur propre certificat — désactivez temporairement l'option « analyse HTTPS » pour tester), un réseau Wi-Fi public à portail captif qui détourne les connexions tant que vous n'êtes pas authentifié, ou un cache SSL corrompu (dans Chrome, effacez les données de navigation en cochant les images et fichiers en cache). Le mode navigation privée, sans extensions, permet de départager rapidement.

Si l'erreur ne concerne qu'un seul site et que le code est ERR_CERT_REVOKED ou MITM_DETECTED, ne passez pas outre. Dans le doute, vérifiez la réputation et la configuration du site avec un scanner externe avant d'y saisir la moindre donnée : c'est exactement le rôle d'un audit de surface.

Le message apparaît sur VOTRE site : les 4 correctifs

Cas 1, le certificat a expiré. C'est la cause la plus fréquente et la plus évitable : les certificats Let's Encrypt durent 90 jours et doivent se renouveler automatiquement. Vérifiez que le renouvellement automatique fonctionne réellement dans votre hébergeur ou votre cron certbot, puis rechargez le service web pour que le nouveau certificat soit servi.

Cas 2, le domaine n'est pas couvert. Le certificat doit inclure toutes les variantes que vos visiteurs utilisent : exemple.com ET www.exemple.com, plus les sous-domaines actifs. Réémettez le certificat en cochant chaque nom, et mettez en place une redirection unique vers votre variante canonique.

Cas 3, la chaîne de certification est incomplète. Le certificat est valide, mais le serveur oublie de transmettre le certificat intermédiaire qui le relie à l'autorité racine. Symptôme caractéristique : le site s'affiche sans erreur sur votre ordinateur (où l'intermédiaire est déjà en cache) mais échoue sur mobile ou chez un client. Installez le fichier « fullchain » et non le certificat seul.

Cas 4, un certificat auto-signé traîne encore. Parfait pour un environnement de test, inacceptable en production : aucun navigateur ne lui fait confiance. Remplacez-le par un certificat Let's Encrypt gratuit, proposé en un clic par la plupart des hébergeurs mutualisés.

openssl s_client -connect exemple.com:443 -servername exemple.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# « Verify return code: 0 (ok) » = chaîne complète.
# « unable to get local issuer certificate » = intermédiaire manquant.
openssl s_client -connect exemple.com:443 -servername exemple.com </dev/null

SSLCertificateFile /etc/letsencrypt/live/exemple.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/exemple.com/privkey.pem

sudo certbot renew --force-renewal
sudo systemctl reload apache2   # ou nginx

Vérifier que la correction a bien pris effet

Après tout changement de certificat, le service web doit être rechargé : c'est l'oubli qui donne l'impression qu'un correctif « ne marche pas ». Testez ensuite depuis un autre appareil et un autre réseau (données mobiles), car votre propre navigateur garde en cache l'ancien état de la connexion.

Testez impérativement les quatre variantes de votre adresse : avec et sans www, en http:// et en https://. Une seule d'entre elles qui échoue suffit à afficher l'avertissement à une partie de vos visiteurs. Un scan externe automatise cette vérification : il contrôle la validité et l'expiration du certificat, la complétude de la chaîne, la correspondance du nom de domaine et la redirection HTTPS, et signale ce qui reste à corriger.