Pourquoi le navigateur affiche « Non sécurisé » : causes et solutions

Un navigateur affiche « Non sécurisé » lorsqu'une page est servie sans chiffrement HTTPS valide : soit parce qu'elle est chargée en HTTP simple, soit parce qu'elle mélange des ressources HTTP et HTTPS, soit parce que son certificat TLS est expiré, mal émis ou ne correspond pas au domaine. La solution consiste presque toujours à servir l'intégralité de la page en HTTPS, avec un certificat valide et au périmètre correct, et sans aucune sous-ressource non sécurisée.

Ce qui déclenche réellement l'avertissement « Non sécurisé »

Le déclencheur principal est simple : toute page chargée en HTTP simple plutôt qu'en HTTPS (HTTP encapsulé dans TLS, Transport Layer Security) n'est ni chiffrée ni authentifiée, et le navigateur la signale donc. Depuis Chrome 68, en juillet 2018, Google marque toutes les pages en HTTP simple comme « Non sécurisé » dans la barre d'adresse, et pas seulement celles qui contiennent un formulaire de connexion, comme le prévoyait la politique antérieure, plus restrictive. Firefox affiche un cadenas barré pour les pages HTTP et renforce l'avertissement lorsque la page comporte un champ de mot de passe. Safari affiche le texte « Non sécurisé » à côté de la barre d'adresse, avec une mise en évidence supplémentaire en présence d'un champ de saisie de texte ou de mot de passe.

Les navigateurs avertissent également sur des pages HTTPS lorsque c'est le certificat lui-même qui pose problème : expiré, auto-signé, émis pour le mauvais nom d'hôte ou mal enregistré dans les journaux Certificate Transparency (un système de registre public que Chrome exige pour les certificats de confiance). Enfin, une troisième catégorie concerne les sites qui utilisent techniquement HTTPS mais chargent malgré tout certaines ressources en HTTP : le contenu mixte.

Les quatre véritables causes

Chacune de ces causes produit un message légèrement différent dans le navigateur, mais elles découlent toutes de la même idée de fond : le navigateur ne peut pas garantir que la connexion est chiffrée de bout en bout et qu'elle appartient réellement au domaine qu'elle prétend représenter.

Pourquoi un site en HTTPS reste « Non sécurisé »

C'est le cas qui déroute le plus, car le site affiche manifestement un cadenas ou dispose d'un certificat installé, et pourtant il est signalé. Il s'agit presque toujours de contenu mixte : le HTML est servi en HTTPS, mais une feuille de style, un script, une image ou un iframe est codé en dur en http:// au lieu de https:// ou d'une URL relative au protocole. Les navigateurs bloquent ou dégradent ces sous-ressources non sécurisées plutôt que de leur faire confiance. Le contenu mixte actif (scripts, iframes, feuilles de style et requêtes fetch/XHR) est purement et simplement bloqué, ce qui explique qu'une page puisse perdre sa mise en forme ou cesser complètement de fonctionner dès son passage en HTTPS. Le contenu passif, comme les images et les médias, est généralement toujours chargé, mais cela suffit à faire disparaître le cadenas et à afficher « Non sécurisé ».

Comment trouver et corriger le contenu mixte

1. Ouvrez la console du navigateur (DevTools → Console). Les avertissements de contenu mixte indiquent précisément les URL http:// en cause.
2. Corrigez chaque référence : remplacez http:// par https:// lorsque la ressource le permet, ou utilisez une URL relative à la racine (/path) ou relative au protocole (//host/path) afin qu'elle hérite du schéma de la page.
3. Vérifiez les endroits où elles se cachent habituellement : liens codés en dur dans les templates, ancien contenu du CMS, intégrations e-mail et marketing, balises publicitaires et analytiques, et widgets tiers.
4. Ajoutez un filet de sécurité : l'en-tête Content-Security-Policy: upgrade-insecure-requests indique au navigateur de réécrire silencieusement toute sous-ressource http:// restante en https://, afin qu'une seule URL oubliée ne fasse pas disparaître le cadenas.

Quand le certificat SSL/TLS est en cause

La raison récurrente la plus fréquente pour laquelle un site devient « Non sécurisé » n'est pas un mauvais déploiement, mais un certificat arrivé à expiration :

• Expiré : un certificat manuel que personne ne suivait, ou un renouvellement automatique qui a échoué sans bruit. Renouvelez-le et réinstallez-le, et automatisez le renouvellement (ACME / Let's Encrypt) partout où c'est possible.
• Chaîne incomplète : le certificat est valide, mais le serveur n'envoie pas le certificat intermédiaire, si bien que certains navigateurs et clients le rejettent. Réinstallez la chaîne complète.
• Mauvais nom d'hôte ou émetteur non reconnu : un certificat auto-signé, ou émis pour example.com alors que le site est servi sur www.example.com. Faites-le réémettre pour les noms d'hôte exacts (tous, dans la liste SAN) par une CA de confiance.

N'attendez pas qu'un client vous prévienne

« Non sécurisé » est un problème de confiance et de SEO (Google considère HTTPS comme un signal de classement, et les navigateurs affichent l'avertissement à chaque visiteur), mais c'est généralement par un client que vous l'apprenez, et non avant. La véritable solution consiste donc à le surveiller. InfraNest détecte chaque certificat TLS sur les domaines et serveurs que vous connectez, suit chaque date d'expiration avec des alertes plusieurs semaines à l'avance, note la configuration de A à F et signale les erreurs de configuration (un intermédiaire manquant, un mauvais nom d'hôte, une expiration imminente) avant qu'un navigateur ne transforme le cadenas en avertissement. Le vert reste vert.