Chrome charge mon site Web hébergé local en tant que https au lieu de http, générant une erreur (survenant après une mise à jour Ubuntu)
J'ai un projet local wordpress sur lequel je travaille et, habituellement, j'ouvre mon site Web en tapant example.dev dans la barre d'adresse, et mon site Web sur lequel je travaille correctement s'affiche.
Je apt-get update et apt-get upgrade mon ordinateur Ubuntu, et il a demandé un redémarrage. après le redémarrage - j'essaie d'ouvrir mon site Web local et j'obtiens une erreur:
Vous ne pouvez pas accéder à ce site. Example.dev a refusé de se connecter. Essayer:
Vérification de la connexion Vérification du proxy et du pare-feu ERR_CONNECTION_REFUSED RechargerHIDE DÉTAILS Vérifiez votre connexion Internet Vérifiez tous les câbles et redémarrez les routeurs, modems ou autres périphériques réseau que vous pourriez utiliser. Autorisez Chrome à accéder au réseau avec les paramètres de votre pare-feu ou de votre antivirus. S'il est déjà répertorié en tant que programme autorisé à accéder au réseau, essayez de le supprimer de la liste et de l'ajouter à nouveau. Si vous utilisez un serveur proxy… Vérifiez vos paramètres de proxy ou contactez votre administrateur réseau pour vous assurer que le serveur proxy fonctionne. Si vous ne pensez pas que vous devriez utiliser un serveur proxy: Allez dans le menu Chrome> Paramètres> Afficher les paramètres avancés…> Modifier les paramètres du proxy… et assurez-vous que votre configuration est définie sur "pas de proxy" ou "direct."
et remarqué qu'il sert mon site Web comme "https" au lieu de "http", chaque fois que je modifie le "https" en "http", après avoir appuyé sur Entrée, il le charge toujours en tant que https.
Je n'étais pas tellement sûr que ce soit le problème - alors j'ai ouvert firefox et j'ai fait de même - et j'ai obtenu une sortie correcte de mon site Web, avec "http" au début et non "https".
Qu'est-ce qui cause cela dans Chrome?
Mon site Web fonctionne sur un serveur Apache2. Cela ne s'est pas produit avant la mise à jour.
edit: je suis tombé sur ce post - https://superuser.com/a/1251483/414388 et je ne comprends pas vraiment pourquoi dois-je changer de nom de domaine - je ne veux vraiment pas suivre cette méthode. Ce n'est pas une solution.
Si vous naviguez vers l'article posté dans le post de superutilisateur, le tl; dr l'explique:
tl; dr: Chrome 63 (sorti en décembre 2017), tous les domaines se terminant par .dev (et .foo) seront forcés de être redirigés vers HTTPS via un en-tête HTTP préchargé Strict Transport Security (HSTS) préchargé.
Ainsi, vos seules solutions sont soit de changer d’outil autre que le .dev TLD, soit de créer un certificat et d’implémenter HTTPS dans votre configuration d’hôte virtuel pour le développement local.
Afin d’expliquer pourquoi c’est votre seule solution, je vais devoir commencer par comprendre ce que signifie HSTS et son fonctionnement.
HSTS en général
HSTS est un nouvel en-tête HTTP relativement qui, une fois défini, indique aux navigateurs que la prochaine fois que quelqu'un accédera au domaine, il n'y accédera que via HTTPS sans nécessiter de redirection côté serveur. .
Par exemple, considérons que vous avez accédé à http://example.com. Dans les en-têtes de réponse, vous recevez les éléments suivants:
Strict-Transport-Security: max-age=31536000
Cet en-tête indique au navigateur que, pour l'année suivante (31536 000 secondes), lorsque l'utilisateur accède à http://example.com, redirige cette URL vers https://example.com localement sans qu'il soit nécessaire de faire de redirection de serveur. Et seulement alors, accédez au site avec https://example.com.
HSTS pour les sous-domaines
Le précédent n'est valable que pour un seul domaine. Ainsi, par exemple, si vous essayez d'accéder à http://subdomain.example.com, le site fonctionnera sans aucune redirection.
Pour résoudre ce problème, l'en-tête précédent doit être remplacé par:
Strict-Transport-Security: max-age=31536000; includeSubdomains
Maintenant, même si vous n'avez jamais accédé à aucun sous-domaine de example.com, le navigateur redirige TOUJOURS les sous-domaines vers https avant de faire une demande.
Préchargement HSTS
La dernière étape consiste à résoudre un dernier problème. La première fois que vous accédez à un site, vous y accédez toujours via HTTP, ce qui vous redirige vers HTTPS et vous envoie l'en-tête HSTS. Le précédent n'est pas sécurisé et reste un problème de sécurité.
Pour résoudre ce problème, les principaux navigateurs utilisent la liste de préchargement HSTS (HTTP Strict Transport Security) de Chrome pour les domaines codés en dur et accessibles uniquement via HTTPS. Vous pouvez trouver le formulaire de soumission ici: https://hstspreload.org/
La seule modification à effectuer avant de soumettre votre domaine consiste à modifier votre en-tête afin de le mettre en cache dans les navigateurs pendant au moins 2 ans et d'y ajouter l'option preload.
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
Après avoir envoyé votre domaine et une fois qu'une nouvelle version de Chrome (ou de tout autre navigateur mettant en œuvre la liste de préchargement HSTS de Chrome, et pas nécessairement la version suivante), votre domaine sera codé en dur dans Chrome en tant que HTTPS uniquement.
Préchargement HSTS pour les TLD
Les propriétaires d'un TLD sont autorisés (et encouragés) à soumettre l'intégralité de leur TLD pour le préchargement de HSTS .
Les propriétaires de gTLD, de ccTLD ou de tout autre domaine de suffixe public sont invités à précharger HSTS dans tous leurs domaines enregistrables. Cela garantit une sécurité robuste pour l'ensemble du TLD et est beaucoup plus simple que le préchargement de chaque domaine.
Et puisque Google est propriétaire du TLD .dev, c'est précisément ce qu'ils ont fait. Alors maintenant, tous les domaines *.dev ne fonctionneront que sous HTTPS sous Chrome. Et comme la plupart des navigateurs utilisent la même liste de préchargement, ces navigateurs cesseront également de fonctionner.
Si vous recherchez le liste des domaines préchargés (ATTENTION: La page est plus de 40 Mo et cela prendra un peu de temps. Pour que votre ordinateur se bloque s'il n'est pas assez puissant!), vous pouvez constater que les TLD sont préchargés: google, dev, foo, page, app, chrome.
// eTLDs
// At the moment, this only includes Google-owned gTLDs,
// but other gTLDs and eTLDs are welcome to preload if they are interested.
{ "name": "google", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true, "pins": "google" },
{ "name": "dev", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "foo", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "page", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "app", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "chrome", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
Si vous ne pouvez plus modifier votre domaine .dev actuel, vous pouvez rétrograder votre Chrome à la version 61 (je l’ai fait avec succès => ici )