VPN connecté mais contenu mixte toujours bloqué : ce qu’il faut corriger
Triez l’URL bloquée selon qui l’a produite, réparez la référence ou transmettez-la au propriétaire de l’hôte, puis confirmez la correction depuis la console du navigateur.
La moitié de la page s’affiche, une feuille de style reste grisée dans le panneau Réseau, et le client VPN signale toujours un tunnel sain. Les trois observations sont vraies en même temps, car le navigateur a jugé une requête émise par la page et le tunnel n’avait pas voix au chapitre dans ce jugement. Ce qui clôt le dossier est une décision et non un réglage : réparer la référence, l’escalader vers qui possède l’hôte, ou abandonner la dépendance. Chacune de ces options a un test peu coûteux, et choisir la mauvaise coûte un cycle de support.
Pourquoi le tunnel ne peut pas couvrir une sous-ressource
Le contenu mixte commence par un document HTTPS qui demande une sous-ressource en HTTP simple. Chaque URL est jugée selon son propre schéma, donc la protection du document parent ne s’étend jamais à une requête enfant. Le chiffrement ajouté sous le navigateur change ce qui circule sur le fil, pas le http:// demandé par le balisage.
Les navigateurs actuels répartissent ces requêtes en deux groupes et les traitent différemment. Les scripts, feuilles de style, iframes et appels via fetch, XMLHttpRequest ou WebSocket sont refusés d’emblée, sans tentative de mise à niveau préalable. Les images, l’audio et la vidéo sont réécrits en https:// et redemandés, et le chargement est abandonné quand cette récupération sécurisée échoue. Une URL de sous-ressource dont l’hôte est une adresse IP nue échappe à la mise à niveau, si bien qu’une image HTTP sur un hôte IP reste bloquée au lieu d’être réparée en silence. La répartition, y compris cette exception du côté des ressources mises à niveau, est documentée dans le guide de Mozilla sur le contenu mixte. Chrome applique un refus similaire aux téléchargements non sécurisés lancés depuis une page sécurisée, ce qui explique qu’un lien PDF puisse mourir alors que la page environnante paraît intacte.
La ligne grisée est donc la preuve que le contrôle fonctionne, non la preuve que le tunnel a laissé fuir du clair. Traitez la ligne comme une constatation qui désigne une seule référence et non la page entière.
Déterminer à qui appartient la référence non sécurisée
Triez l’URL fautive selon l’endroit où elle est produite avant de modifier quoi que ce soit. Cette réponse décide si vous pouvez livrer un correctif aujourd’hui, si un fournisseur doit en publier un, ou si la dépendance doit quitter la page. Lisez-la dans la colonne Initiateur du panneau Réseau, car le balisage affiché est souvent assemblé à l’exécution.
| D’où vient l’URL | Qui peut la corriger | Premier pas |
|---|---|---|
| Codée en dur dans un modèle ou un partiel que vous déployez | Vous | Remplacez-la par la forme https:// puis videz le cache |
| Injectée par un gestionnaire de balises ou un paquet fournisseur | Le fournisseur, avec votre ticket | Envoyez l’URL exacte, le type de requête et la ligne de console |
| Servie uniquement sur le port 80 sans écouteur TLS | Le propriétaire de l’hôte | Demandez TLS, placez quelque chose que vous exploitez devant, ou abandonnez-la |
Quand l’hôte répond déjà sur 443 et que seule la référence dit http, la réparation est locale : changez la référence, videz le cache de la page et confirmez que la ligne devient https. Un hôte qui n’écoute que sur le port 80 ne peut pas être mis en conformité par édition, donc la ressource déménage, se fait précéder de quelque chose que vous contrôlez, ou disparaît. Une URL injectée par un gestionnaire de balises continue d’apparaître même quand votre modèle est propre, et ce cas relève d’un ticket avec l’URL exacte et la ligne de console jointes. Dire au personnel d’autoriser le contenu non sécurisé ne fait pas partie de ces options, car cela désactive le contrôle pour chaque site que ce profil de navigateur visite.
Réparer la référence plutôt que le réglage du navigateur
Rechargez le parcours défaillant en conservant le journal réseau et filtrez le panneau sur l’hôte que vous soupçonnez. La console nomme l’URL et la directive, ce qui tranche entre un refus et une mise à niveau avant que vous ne touchiez à un modèle.
curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.jsDeux contrôles d’appui méritent d’être connus, et aucun ne remplace la réparation. Un en-tête Content-Security-Policy portant upgrade-insecure-requests fait réécrire par le navigateur les URL de sous-ressources http avant qu’elles ne quittent la page, ce qui rattrape d’anciennes références que vous n’avez pas encore trouvées. La requête réécrite échoue encore quand l’hôte cible ne sert pas de HTTPS, donc l’en-tête change seulement l’URL que le navigateur essaie. HSTS s’applique par hôte, ce qui signifie qu’une politique sur votre propre domaine ne fait rien pour un CDN tiers qui n’a jamais envoyé l’en-tête. Après une modification de modèle, videz le cache de la page et cherchez l’ancien nom d’hôte dans le HTML rendu, car la même URL peut aussi arriver par un partiel, une chaîne de traduction ou un champ de base de données.
Suivez aussi les redirections, car une chaîne qui commence en https:// peut aboutir à un emplacement http:// et le navigateur juge le dernier saut. La -L forme de la seconde commande ci-dessus affiche cette URL effective pour vous. Si le dernier saut est du http pur, la référence reste fausse même si le lien que vous avez modifié semblait correct.
Confirmer la page avec la console et le panneau Réseau
Rechargez avec le cache désactivé et parcourez à nouveau le flux, y compris les boutons qui chargent du contenu à la demande. Un premier chargement de page masque les widgets différés, les tuiles de carte et les scripts de lecteur qui n’apparaissent qu’après un clic. La console ne doit contenir aucune entrée de contenu mixte et chaque ligne que vous avez touchée doit afficher https. Capturez la console et la ligne de requête avant de fermer le ticket, car cet état est difficile à reconstituer après le prochain déploiement.
Quand la ressource appartient à quelqu’un d’autre, envoyez quatre choses : l’URL exacte, le type de requête, le texte de la console et la page où elle apparaît. Masquez les identifiants de session dans tout ce que vous collez dans un ticket. Un rapport qui dit seulement que les images sont cassées ne donne rien à chercher au propriétaire.
Le tunnel continue de faire son propre travail pendant que le correctif réside dans la référence qui a produit la requête. Cherchez encore une fois le nom d’hôte dans le modèle et le paquet fournisseur après le déploiement, et ne clôturez l’affaire que lorsqu’aucune entrée de contenu mixte bloquée ne subsiste dans la console.