Alerte HTTPS sur son propre site : causes et réparation
Ou : le message s’adresse à vos visiteurs, mais c’est à vous qu’il parle.
La réponse courte : quand tous vos visiteurs voient « Votre connexion n’est pas privée », le problème vient du certificat de votre site, pas de leur navigateur. Trois causes couvrent l’essentiel : le certificat a expiré parce que son renouvellement automatique a échoué, il ne couvre pas le nom saisi (avec ou sans www, un sous-domaine oublié), ou il n’est pas reconnu (certificat autosigné, chaîne incomplète). Le code affiché sous l’alerte de Chrome dit laquelle : NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID ou NET::ERR_CERT_AUTHORITY_INVALID. La réparation passe presque toujours par l’espace client de l’hébergeur, et elle fait partie de ce qu’il faut savoir pour protéger son site chez un hébergeur.
Si l’alerte n’apparaît que chez un seul visiteur, la cause est souvent chez lui, à commencer par une horloge d’ordinateur déréglée. Si elle apparaît partout depuis une date précise, regardez ce qui a changé ce jour-là : un transfert de DNS, une migration, un CDN ajouté devant le site, ou un enregistrement CAA, ce champ DNS qui dit quelles autorités peuvent délivrer un certificat pour votre domaine.
Pour qui : un indépendant ou une petite entreprise qui veut un certificat installé et renouvelé par l’hébergeur, sans manipulation.
À partir de : 5,75 € HT par mois pour l’hébergement web Infomaniak, facturé à l’année par défaut, sans prix promotionnel affiché (relevé du 12 novembre 2026), certificat Let’s Encrypt inclus.
Pour démarrer : commander l’hébergement web Infomaniak, pointer le domaine vers l’hébergement, puis activer le certificat gratuit.
« Votre connexion n’est pas privée » sur votre site : causes côté serveur et réparation
| Code affiché par Chrome | Ce qu’il signifie | Cause probable côté site | Réparation |
|---|---|---|---|
NET::ERR_CERT_DATE_INVALID | certificat expiré ou pas encore valide | renouvellement automatique bloqué : domaine pointé ailleurs, CAA, proxy | rétablir le DNS vers l’hébergement, puis relancer l’émission depuis le panneau |
NET::ERR_CERT_COMMON_NAME_INVALID | le certificat ne couvre pas ce nom | www ou sous-domaine absent du certificat, ancien certificat resté en place | ajouter le nom au certificat, ou rediriger vers le nom couvert |
NET::ERR_CERT_AUTHORITY_INVALID | autorité non reconnue | certificat autosigné du serveur, chaîne intermédiaire manquante | installer le certificat fourni par l’hébergeur avec sa chaîne complète |
Firefox et Safari affichent d’autres formulations, mais les trois familles sont les mêmes.
Le renouvellement qui échoue en silence. À chaque émission, Let’s Encrypt vérifie que vous contrôlez toujours le domaine. Avec la validation par HTTP, l’autorité demande au serveur de présenter un fichier précis ; si le domaine pointe vers l’ancien hébergeur après une migration, ou vers un autre serveur, la vérification échoue et le certificat finit par expirer. Le panneau affiche parfois l’erreur, souvent personne ne la lit. Rétablissez d’abord les enregistrements DNS, attendez leur propagation, puis relancez l’émission.
L’enregistrement CAA qui interdit votre propre autorité. Un champ CAA laissé par un ancien certificat payant peut n’autoriser qu’une seule autorité, par exemple Sectigo. Let’s Encrypt refuse alors d’émettre, en respectant la règle que le domaine lui impose. La documentation de Let’s Encrypt indique la valeur à ajouter : letsencrypt.org. Le plus simple est de supprimer les CAA dont personne ne connaît l’origine, ou d’y ajouter l’autorité de votre hébergeur.
Le proxy devant le site. Quand un CDN (un réseau de serveurs qui sert le site depuis des points proches des visiteurs) ou un proxy se place devant l’hébergement, le visiteur voit le certificat du proxy, et l’hébergement doit présenter le sien au proxy. Deux certificats, deux renouvellements, deux pannes possibles. En cas d’alerte, désactivez le proxy le temps de vérifier lequel des deux a expiré.
Le contenu mixte, un autre symptôme. Une page en HTTPS qui charge des images, des scripts ou des feuilles de style en HTTP ne déclenche pas cette alerte pleine page. Selon la documentation de MDN sur le contenu mixte, le navigateur passe les images en HTTPS de lui-même et bloque les scripts, les feuilles de style et les iframes chargés en HTTP. Le site s’affiche alors à moitié, sans mise en page ou sans formulaire. La réparation consiste à remplacer les adresses en http:// dans le contenu et les réglages du CMS.
Un certificat payant ne règle rien de tout cela
Remplacer le certificat gratuit par un certificat payant ne protège d’aucune de ces pannes : un certificat Sectigo expire aussi, refuse aussi un nom qu’il ne couvre pas, et se heurte au même champ CAA. Ce que le prix achète, et ce qu’il n’achète pas, est détaillé dans la comparaison entre certificat gratuit et payant.
Le proxy qui protège, et ce qu’il demande en échange
Un CDN placé devant le site sert souvent à absorber les attaques par saturation, puisqu’il reçoit le trafic à la place de l’hébergement. Il ajoute en échange un certificat de plus à surveiller. Le rôle de ces services face aux attaques, et les limites de la protection fournie par un mutualisé, sont décrits dans la protection d’un petit site contre un DDoS.