Chrome: le site Web utilise HSTS. Erreurs de réseau ... cette page fonctionnera probablement plus tard
Je me développe contre localhost. Ce matin, juste après avoir utilisé le violoniste, j'ai commencé à avoir cette erreur sur chrome (fonctionne correctement dans Firefox).
"Vous ne pouvez pas visiter localhost pour le moment, car le site Web utilise HSTS. Les erreurs et attaques réseau étant généralement temporaires, cette page fonctionnera probablement plus tard." 
Maintenant, localhost fonctionne dans chrome uniquement si le violon est en cours d'exécution. Je m'étais déjà assuré que les redirections de proxy créées par le violoniste étaient corrigées à la fermeture du violon.
J'ai également essayé d'importer le certificat sur ma racine de confiance et de redémarrer le navigateur (et également la machine).
Lorsque vous avez visité https: // localhost précédemment, il l'a non seulement visité via un canal sécurisé (https plutôt que http), mais il l'a également indiqué à votre navigateur, à l'aide d'un en-tête HTTP spécial: Strict-Transport -Security (souvent abrégé en HSTS), qu’il devrait utiliser UNIQUEMENT le https pour toutes les visites futures.
Il s'agit d'une fonctionnalité de sécurité que les serveurs Web peuvent utiliser pour empêcher les personnes d'être rétrogradées en http (intentionnellement ou par quelque parti pervers).
Toutefois, si vous éteignez ensuite votre serveur https et que vous souhaitez simplement parcourir http, vous ne pouvez pas (par nature, c’est l’intérêt de cette fonctionnalité de sécurité).
HSTS vous empêche également d’accepter et de ignorer les erreurs de certificat antérieures.
Pour réinitialiser cela, pour que HSTS ne soit plus défini pour localhost, tapez ce qui suit dans la barre d’adresses Chrome:
chrome://net-internals/#hsts
Où vous pourrez supprimer ce paramètre pour "localhost".
Vous voudrez peut-être aussi savoir ce qui l’a réglé pour éviter ce problème à l’avenir!
Notez que pour d'autres sites (par exemple, www.google.com), ils sont "préchargés" dans le code Chrome et ne peuvent donc pas être supprimés. Lorsque vous les interrogez sur chrome: // net-internals/# hsts, vous les verrez répertoriés sous la forme d'entrées static HSTS.
Enfin, notez que Google a commencé à précharger HSTS pour l’ensemble du domaine .dev: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
Une façon très rapide de contourner ce problème consiste à afficher l'écran "Votre connexion n'est pas privée":
tapez badidea
tapez thisisunsafe (crédit à Le Java Guy pour trouver la nouvelle phrase secrète)
Cela autorisera l'exception de sécurité lorsque Chrome n'autorisera pas la définition de l'exception par clic, par ex. pour ce cas HSTS.
Ceci n’est évidemment recommandé que pour les connexions locales et les machines virtuelles de réseau local, mais il présente l’avantage de fonctionner pour les ordinateurs virtuels utilisés pour le développement (par exemple, sur des connexions locales transférées par port) et pas seulement pour les connexions hôte local direct.
Remarque: les développeurs Chrome ont déjà changé cette phrase secrète et peuvent le faire à nouveau. Si badidea cesse de fonctionner, veuillez laisser une note ici si vous apprenez la nouvelle phrase secrète. Je vais essayer de faire la même chose.
Edit: à compter du 30 janvier 2018, cette phrase secrète semble ne plus fonctionner.
Si je peux en rechercher un nouveau, je le posterai ici. En attendant, je vais prendre le temps de configurer un certificat auto-signé en utilisant la méthode décrite dans cet article stackoverflow:
Comment créer un certificat auto-signé avec openssl?
Edition: à partir du 1 mars 2018 et Chrome version 64.0.3282.186, cette phrase secrète fonctionne à nouveau pour les blocs liés à HSTS sur les sites .dev.
Edit: à partir du 9 mars 2018 et Chrome Version 65.0.3325.146, la badidea phrase secrète ne fonctionne plus.
Edit 2: le problème avec les certificats auto-signés semble être que, avec le durcissement des normes de sécurité ces derniers temps, ils provoquent la création de leurs propres erreurs (nginx, par exemple, refuse de charger une Certificat SSL/TLS qui inclut un certificat auto-signé dans la chaîne d’autorité, par défaut).
La solution que je préconise maintenant consiste à échanger le domaine de premier niveau sur tous mes sites de développement .app et .dev avec .test ou .localhost. Chrome et Safari n'acceptent plus les connexions non sécurisées vers des domaines de premier niveau standard (y compris .app).
Cet article de Wikipedia contient la liste actuelle des domaines de premier niveau standard, y compris les domaines à usage spécial:
Wikipedia: Liste des domaines Internet de premier niveau: domaines à usage spécial
Ces domaines de premier niveau semblent être exemptés des nouvelles restrictions https-only:
- .local
- .localhost
- .tester
- (tout domaine de premier niveau personnalisé/non standard)
Voir la réponse et le lien entre codinghands et la question d'origine pour plus d'informations:
J'ai eu ce problème avec des sites fonctionnant sur XAMPP avec des noms d'hôtes privés. Pas si privé, il s'avère! Ils étaient tous domain.dev, ce que Google a maintenant enregistré en tant que gTLD privé , et qui force HSTS au niveau du domaine. Changé chaque hôte virtuel en .devel (eugh), a redémarré Apache et tout va bien maintenant.
J'ai récemment eu le même problème en essayant d'accéder à des domaines en utilisant CloudFlare Origin CA .
Le seul moyen que j’ai trouvé pour contourner/éviter l’exception de certification HSTS sur Chrome (construction de Windows) était de suivre les instructions abrégées de https://support.opendns.com/entries/66657664 .
La solution de contournement:
Ajoutez à Chrome raccourcissez l'indicateur --ignore-certificate-errors, puis rouvrez-le et accédez à votre site Web.
Rappel:
Utilisez-le uniquement à des fins de développement.
Cliquez n'importe où dans la fenêtre chrome et tapez thisisunsafe (au lieu de badidea précédemment) en chrome.
Cette phrase secrète pourrait changer à l'avenir. C'est la source
Selon cette ligne, tapez window.atob('dGhpc2lzdW5zYWZl') sur la console de votre navigateur pour obtenir le mot de passe complexe actuel.
Cette fois la phrase secrète est thisisunsafe.
Erreur similaire rencontrée. la réinitialisation de chrome: // net-internals/# hsts ne fonctionnait pas pour moi. Le problème était que l'horloge de ma machine virtuelle était faussée par les jours. réinitialiser le temps a fonctionné pour résoudre ce problème. https://support.google.com/chrome/answer/4454607?hl=fr
Je rencontre la même erreur et le mode incognito a le même problème. Je résous ce problème en clarifiant l'historique Chrome.
Je vois qu'il y a tellement de réponses utiles ici, mais je trouve quand même un article pratique et utile. https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/
J'ai rencontré le même problème et cet article m'a aidé à comprendre en quoi il consiste exactement et comment gérer ce problème. HTH :-)
Je souffre de ce problème depuis très longtemps. Je n'ai pas pu ouvrir de sites Web comme GitHub. J'ai presque essayé toute la réponse sur le web et personne n'a travaillé. J'ai essayé de réinstaller chrome également. J'ai trouvé la solution pour cela auprès de notre responsable réseau et cela a fonctionné. Il existe un correctif dans le registre qui résoudra cette erreur de manière permanente.
- Appuyez sur la touche Windows + R pour ouvrir la boîte de dialogue d'exécution
- tapez: regedit et appuyez sur Entrée pour ouvrir le registre
- Dans l'arborescence, cliquez avec le bouton gauche de la souris sur le chemin suivant HKEY_LOCAL_MACHINE> LOGICIEL> POLITIQUES> Microsoft> SystemCertificate> Authroot
- Maintenant, double-cliquez sur DisableRootAutoUpdate à droite et réglez-le sur 0(zero) dans la boîte de dialogue qui s'affiche.
- Redémarrez votre PC pour appliquer les modifications du registre et vous n'obtiendrez plus cette erreur
La solution ci-dessus est pour Windows 8. Elle est presque identique dans les versions ultérieures, mais je ne suis pas sûr pour les versions antérieures telles que XP et Vista. Donc, cela doit être vérifié.