Ce que signifie « Votre connexion n'est pas privée » et comment la corriger

Ce que signifie l'erreur

Le navigateur s'est connecté, le serveur a présenté son certificat, et le navigateur a refusé de lui faire confiance. Chrome affiche « Votre connexion n'est pas privée » avec un code d'erreur ; Firefox « Attention : risque probable de sécurité » ; Safari « Cette connexion n'est pas privée ». Le site n'est pas piraté, votre ordinateur n'est pas infecté : le certificat envoyé par le serveur échoue aux vérifications du navigateur.

Le code d'erreur dit quelle vérification a échoué :

• NET::ERR_CERT_DATE_INVALID : le certificat a expiré ou n'est pas encore valide (ou l'horloge du visiteur est fausse).
• NET::ERR_CERT_COMMON_NAME_INVALID : le certificat vaut pour un autre nom, par exemple www.example.com mais pas example.com.
• NET::ERR_CERT_AUTHORITY_INVALID : aucune autorité de confiance à l'origine : auto-signé, émetteur inconnu ou certificat intermédiaire manquant.
• NET::ERR_CERT_REVOKED : l'émetteur a révoqué le certificat.
• SSL_ERROR_BAD_CERT_DOMAIN et SEC_ERROR_EXPIRED_CERTIFICATE : les variantes Firefox pour le nom et la date.

Causes fréquentes

1. Le certificat a expiré. Le renouvellement automatique Let's Encrypt échouait depuis des semaines sans que personne ne le voie, ou le rappel du certificat acheté est parti vers une vieille adresse e-mail.
2. Renouvelé, mais pas rechargé. certbot a écrit le nouveau certificat sur le disque, mais le serveur web sert encore l'ancien, faute de hook de rechargement.
3. Mauvais nom. Le certificat couvre example.com, mais les visiteurs arrivent par www.example.com, ou un sous-domaine n'a pas de certificat.
4. Certificat intermédiaire manquant. Le serveur n'envoie que son propre certificat, pas la chaîne. Les navigateurs de bureau comblent souvent le trou ; smartphones et applications échouent.
5. Un problème d'horloge. Chez le visiteur, une date fausse fait paraître chaque certificat expiré. Sur le serveur, elle casse le renouvellement.
6. Un CDN ou un proxy devant, avec son propre certificat expiré ou sans le bon nom, alors que le serveur d'origine est en ordre.

Si vous êtes visiteur

Vérifiez d'abord la date et l'heure de votre appareil ; une synchronisation désactivée fait échouer tous les sites. Essayez ensuite un autre réseau. Si l'avertissement n'apparaît que pour un site, sur chaque appareil, c'est le certificat du site : le propriétaire doit le corriger. Cliquer sur « Continuer vers … (dangereux) » passe pour un site que vous connaissez, jamais pour un site avec identifiants ou paiement.

Si c'est votre site : vérifier d'abord

Lancez le SSL Checker : date d'expiration, noms couverts et chaîne complète ou non, depuis l'extérieur, sans cache de navigateur. Puis, sur votre propre serveur :

# qu'envoie le serveur ?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# qu'y a-t-il sur le disque ?
sudo certbot certificates

# l'horloge est-elle juste ?
timedatectl

Dates plus récentes sur le disque que dans la réponse du serveur ? Vous êtes dans le cas 2 : renouvelé, mais pas rechargé.

Solutions sur votre propre serveur

1. Renouveler avec certbot

sudo certbot renew
# si renew répond « not yet due » alors que le serveur sert un vieux certificat :
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # ou apache2

Si le renouvellement échoue, la raison est dans la sortie. Les classiques : le port 80 est bloqué ou redirigé (le défi HTTP-01 doit joindre /.well-known/acme-challenge/ en simple HTTP), le DNS pointe ailleurs, ou une limitation s'applique après trop d'échecs. Corrigez la cause et lancez sudo certbot renew --dry-run jusqu'à ce que cela passe.

2. Automatiser le rechargement

# certbot installe un timer ; vérifiez-le
systemctl list-timers | grep certbot

# hook pour que le serveur web prenne le nouveau certificat
echo 'systemctl reload nginx' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh

3. Ajouter le nom manquant

sudo certbot --nginx -d example.com -d www.example.com -d boutique.example.com --expand

--expand remplace le certificat existant par un certificat couvrant tous les noms listés.

4. Réparer la chaîne

Avec certbot, le serveur web doit pointer vers fullchain.pem, jamais vers cert.pem :

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Apache : SSLCertificateFile avec fullchain.pem. Pour un certificat acheté, téléchargez le « CA bundle » chez l'émetteur et ajoutez-le à la fin du fichier. Testez avec sudo nginx -t, rechargez, puis vérifiez la chaîne avec le SSL Checker.

5. Régler l'horloge

sudo timedatectl set-ntp true
timedatectl

Une horloge qui dérive de plus de quelques minutes fait échouer la vérification des certificats dans les deux sens.

6. Hébergement mutualisé ou constructeur de site

La plupart des hébergeurs délivrent et renouvellent les certificats Let's Encrypt depuis l'espace client. Vérifiez-y que le certificat couvre example.com et www.example.com, et cliquez sur renouveler. Si le panneau affiche un certificat valide alors que les navigateurs disent le contraire, le problème de rechargement ou de chaîne est chez l'hébergeur.

Si le problème vient de votre hébergeur

Bonjour, depuis environ 6 h 00 (UTC), les navigateurs affichent « Votre connexion n'est pas privée » (NET::ERR_CERT_DATE_INVALID) pour mon site example.com. L'espace client montre un certificat valide, le serveur semble donc servir l'ancien. Pourriez-vous recharger le certificat et vérifier le renouvellement automatique pour mon domaine ?

Pour que cela ne se reproduise pas

Un certificat expiré est la seule panne à date connue d'avance. La surveillance de certificat SSL vous prévient avant l'expiration, et encore si la chaîne ou le nom ne sont pas corrects ; l'offre gratuite inclut des vérifications SSL. Sur votre propre serveur, l'intervention rapide renouvelle le certificat là où certbot est configuré et recharge le serveur web, à prix fixe, 24 h/24 ; l'intervention approfondie met en place le renouvellement là où il manque. Le serveur refuse carrément la connexion sur le port 443 ? C'est un autre cas : ERR_CONNECTION_REFUSED.