Chrome: el sitio web utiliza HSTS. Errores de red ... esta página probablemente funcionará más tarde

Estoy desarrollando contra localhost. Esta mañana, justo después de usar Fiddler, comencé a recibir este error en Chrome (funciona correctamente en Firefox)

"No puede visitar localhost en este momento porque el sitio web usa HSTS. Los errores y ataques de red suelen ser temporales, por lo que esta página probablemente funcionará más tarde".

Ahora localhost funciona en Chrome solo si se está ejecutando Fiddler. Ya me aseguré de que las redirecciones de proxy que realiza el violinista se corrijan cuando el violinista se apaga.

También intenté importar el certificado a mi raíz de confianza y reiniciar el navegador (y también la máquina).

Una forma muy rápida de evitar esto es cuando estás viendo la pantalla "Tu conexión no es privada":

tipo badidea

tipo thisisunsafe(crédito a The Java Guy por encontrar la nueva frase de contraseña)

Eso permitirá la excepción de seguridad cuando Chrome no permita que la excepción se establezca mediante clics, por ejemplo, para este caso HSTS.

Obviamente, esto solo se recomienda para conexiones locales y máquinas virtuales de red local, pero tiene la ventaja de funcionar para máquinas virtuales que se utilizan para el desarrollo (por ejemplo, en conexiones locales enviadas por puerto) y no solo para conexiones locales de host local.

Nota: los desarrolladores de Chrome han cambiado esta frase de contraseña en el pasado y pueden volver a hacerlo. Si badideadeja de funcionar, deje una nota aquí si aprende la nueva frase de contraseña. Intentaré hacer lo mismo.

Editar: a partir del 30 de enero de 2018, esta frase de contraseña parece que ya no funciona.

Si puedo cazar uno nuevo, lo publicaré aquí. Mientras tanto, me tomaré el tiempo para configurar un certificado autofirmado utilizando el método descrito en esta publicación de stackoverflow:

¿Cómo crear un certificado autofirmado con openssl?

Editar: a partir del 1 de marzo de 2018 y la versión de Chrome 64.0.3282.186, esta frase de contraseña vuelve a funcionar para los bloques relacionados con HSTS en los sitios .dev.

Editar: a partir del 9 de marzo de 2018 y la versión 65.0.3325.146 de Chrome, la badideafrase de contraseña ya no funciona.

Edición 2: el problema con los certificados autofirmados parece ser que, con los estándares de seguridad más estrictos en estos días, provocan que se arrojen sus propios errores (nginx, por ejemplo, se niega a cargar un certificado SSL / TLS que incluye un certificado autofirmado en la cadena de autoridad, por defecto).

La solución con la que voy ahora es cambiar el dominio de nivel superior en todos mis sitios de desarrollo .app y .dev con .test o .localhost. Chrome y Safari ya no aceptarán conexiones inseguras a dominios de nivel superior estándar (incluido .app).

La lista actual de dominios de nivel superior estándar se puede encontrar en este artículo de Wikipedia, incluidos los dominios de uso especial:

Wikipedia: Lista de dominios de nivel superior de Internet: dominios de uso especial

Estos dominios de nivel superior parecen estar exentos de las nuevas restricciones solo https:

• .local
• .localhost
• .prueba
• (cualquier dominio de nivel superior personalizado / no estándar)

Consulte la respuesta y el enlace de codinghands a la pregunta original para obtener más información:

respuesta de codinghands

Cuando visitó https: // localhost anteriormente en algún momento, no solo lo visitó a través de un canal seguro (https en lugar de http), también le dijo a su navegador, usando un encabezado HTTP especial: Strict-Transport-Security (a menudo abreviado como HSTS ), que SOLO debe usar https para todas las visitas futuras.

Esta es una característica de seguridad que los servidores web pueden usar para evitar que las personas sean degradadas a http (ya sea intencionalmente o por alguna parte malvada).

Sin embargo, si luego apaga su servidor https y solo quiere navegar por http, no puede hacerlo (por diseño, ese es el punto de esta característica de seguridad).

HSTS también evita que acepte y saltee errores de certificados anteriores.

Para restablecer esto, para que HSTS ya no esté configurado para localhost, escriba lo siguiente en su barra de direcciones de Chrome:

chrome://net-internals/#hsts

Donde podrá eliminar esta configuración para "localhost".

¡Es posible que también desee saber qué estaba configurando esto para evitar este problema en el futuro!

Tenga en cuenta que para otros sitios (por ejemplo, www.google.com) estos están "precargados" en el código de Chrome y, por lo tanto, no se pueden eliminar. Cuando los consulta en chrome: // net-internals / # hsts los verá listados como staticentradas HSTS.

Y finalmente tenga en cuenta que Google ha comenzado a precargar HSTS para todo el dominio .dev: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/

Haga clic en cualquier lugar de la ventana de Chrome y escriba thisisunsafe(en lugar de badideaanteriormente) en Chrome.

Esta frase de contraseña puede cambiar en el futuro. Esta es la fuente

https://chromium.googlesource.com/chromium/src/+/master/components/security_interstitials/core/browser/resources/interstitial_large.js#19

De acuerdo con esa línea, escriba window.atob('dGhpc2lzdW5zYWZl')en la consola de su navegador y le dará la frase de contraseña real.

Esta vez la frase de contraseña es thisisunsafe.

Tuve este problema con los sitios que se ejecutan en XAMPP con nombres de host privados. ¡No es tan privado, resulta! Eran todos domain.dev, que Google ahora ha registrado como un gTLD privado , y está obligando a HSTS a nivel de dominio. Cambió cada host virtual a .devel(eugh), reinició Apache y ahora todo está bien.

Recientemente tuve el mismo problema al tratar de dominios de acceso utilizando CloudFlare Origen CA .

La única forma en que encontré para solucionar / evitar la excepción del certificado HSTS en Chrome (compilación de Windows) fue siguiendo las breves instrucciones en https://support.opendns.com/entries/66657664 .

La solución alternativa:
agregue a Chrome el acceso directo a la bandera --ignore-certificate-errors, luego vuelva a abrirla y navegue a su sitio web.

Recordatorio:
Úselo solo para fines de desarrollo.

Veo que hay muchas respuestas útiles aquí, pero aún así, me encuentro con un artículo útil y útil por ahí. https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/

Me encontré con el mismo problema y ese artículo me ayudó a saber qué es exactamente y cómo lidiar con ese HTH :-)

Se encontró un error similar. restablecer chrome: // net-internals / # hsts no me funcionó. El problema era que el reloj de mi VM estaba sesgado por días. restablecer el tiempo funcionó para resolver este problema. https://support.google.com/chrome/answer/4454607?hl=en

Me encuentro con el mismo error, y el modo de incógnito también tiene el mismo problema. Resuelvo este problema borrando el historial de Chrome.

He sufrido este problema por mucho tiempo. No pude abrir sitios web como GitHub. Casi probé todas las respuestas en la web y nadie trabajó. Intenté reinstalar Chrome también. Encontré la solución para esto de nuestro chico de la red y funcionó. Hay una solución en el registro que resolverá este error de forma permanente.

1. Presione la tecla Windows + R para abrir el cuadro de diálogo Ejecutar
2. escriba: regedit y presione enter para abrir el registro
3. En la vista de árbol a la izquierda, haga clic en la siguiente ruta HKEY_LOCAL_MACHINE> SOFTWARE> POLÍTICAS> Microsoft> SystemCertificate> Authroot
4. Ahora haga doble clic en DisableRootAutoUpdate a la derecha y configúrelo en 0 (cero) en el cuadro de diálogo que aparece
5. Reinicie su PC para aplicar cambios en el registro y ya no recibirá este error

La solución anterior es para Windows 8. Es casi idéntica en versiones posteriores, pero no estoy seguro de versiones anteriores como XP y vista. Entonces eso necesita ser verificado.