Le contenu mixte est une page servie en https:// qui appelle encore une ressource en http://. Le cadenas disparaît, ou la ressource est bloquée, selon son type. Le certificat peut être parfaitement valide : le problème est l’URL écrite dans la page, pas la date du certificat. Cette date se vérifie à part, voir expiration du certificat.
Actif ou passif
| Type | Exemples | Comportement actuel des navigateurs |
|---|---|---|
| Actif | <script>, <link rel="stylesheet">, iframe, fetch, XHR, formulaire vers http:// | Bloqué. La fonction, la feuille de style ou le cadre manque. |
| Passif | Image, audio, vidéo | Chrome tente de charger la même URL en https://. Si elle n’existe pas en HTTPS, la ressource est bloquée. |
Une feuille de style bloquée suffit à afficher une page sans mise en forme. Un script de paiement bloqué suffit à empêcher le bouton de payer, alors que le reste du catalogue s’affiche. Regardez la console, pas seulement le cadenas.
Trouver les URL en http
- Ouvrez la page en
https://, outils de développement, console. Filtrez « Mixed Content ». Chaque ligne cite l’URL bloquée ou mise à niveau. - Onglet Réseau : tri par schéma, ou cherchez
http://. - Code source : cherchez
http://dans le HTML. Vous verrez les images codées en dur, les iframes et les canonical erronés. - Cherchez aussi dans les CSS (
url(http://...)) et dans les réglages du CMS (URL du site, URL des médias, widgets collés).
curl sur la page ne montre le mixte que si vous lisez le HTML. Les en-têtes de sécurité, eux, se voient avec curl -sI. Une CSP peut signaler ou bloquer ces requêtes : vérifier les en-têtes.
Le cas le plus fréquent sous WordPress : siteurl est en HTTPS, mais d’anciens articles et le champ guid contiennent encore http://. On corrige le contenu publié. On ne réécrit pas le guid à la légère : WordPress s’en sert comme identifiant, pas comme lien à afficher.
WP-CLI, sur une copie d’abord :
wp search-replace "http://exemple.fr" "https://exemple.fr" --skip-columns=guid --dry-run
Puis la même commande sans --dry-run une fois les lignes relues. Les données sérialisées des widgets sont gérées par WP-CLI ; un remplacer dans un éditeur SQL les casse.
Corriger dans le bon sens
- Réécriture des URL en
https://dans la base, les modèles et les fichiers CSS. - Redirection 301 de
httpvershttpspour les pages, afin que personne ne reste sur l’ancien schéma. La chaîne se vérifie comme dans trouver les redirections. - Ressources tierces : si le fournisseur n’a pas d’HTTPS, retirez la ressource. Un proxy « SSL » maison qui rapatrie un script HTTP est rarement le bon entretien.
- En-tête de transition :
Content-Security-Policy: upgrade-insecure-requests. Le navigateur demande la version HTTPS. Gardez-le le temps de nettoyer, puis laissez-le en filet. - HSTS seulement après coup, quand plus aucune page légitime n’a besoin du HTTP. Sinon le navigateur refusera d’ouvrir les sous-domaines encore en clair.
Les URL sans protocole (//cdn.exemple.fr/x.js) dépendent de la page. Écrivez https:// en entier.
Revérifier
Rechargez sans cache. La console ne doit plus citer de contenu mixte. Contrôlez une page ancienne, pas seulement l’accueil : les articles et les fiches produits concentrent les URL collées il y a des années. Un test d’URL confirme que la page publique est bien en HTTPS avec un certificat cohérent ; la console du navigateur reste nécessaire pour les ressources internes au HTML.
Si une image « https » renvoie 404 alors que la version http existe, le virtual host HTTPS ne sert pas ce fichier. Ce n’est plus du mixte : c’est un fichier absent sur le bon hôte. On le déplace ou on corrige l’URL, on ne revient pas au HTTP.