Cómo reparar Firefox 59 ya no acepta mi certificado SSL autofirmado en .dev virtualhost

20

En mi entorno local de Apache, tengo un sitio que requiere SSL para el desarrollo, por lo que he estado usando un certificado autofirmado. El sitio local ha funcionado bien en Firefox y Chrome hasta ahora, pero después de actualizar Firefox a la versión 59 hoy no puedo hacer que acepte la excepción de seguridad (en Chrome, el certificado autofirmado sigue funcionando).

Firefox me da esta información adicional en la página bloqueada:

... usa un certificado de seguridad no válido. El certificado no es de confianza porque está autofirmado. Código de error: SEC_ERROR_UNKNOWN_ISSUER

No hay ninguna opción para permitir la excepción aquí como solía haberla, pero fui a las Preferencias de Firefox en Certificados, luego en la pestaña "Servidor" agregué una excepción para el dominio local. El certificado aparece en el nombre correcto del servidor local, los detalles muestran la configuración de mi certificado de Emitido por y Emitido para que sea el mismo, con un intervalo de tiempo válido.

¿Alguien que tenga problemas similares con FF 59 o podría tener una idea de qué hacer para que el certificado autofirmado vuelva a funcionar localmente?

Editar: no veo ninguna mención de esto en las notas de la versión FF 59, pero algo en la nueva versión hace que todos mis hosts virtuales locales en dominios * .dev intenten automáticamente establecer una conexión https (es decir, todos los http las solicitudes de * .dev se envían automáticamente a la URL https). Quizás algo sobre este comportamiento es también lo que está causando estos problemas para mis hosts virtuales https reales.

ssl ssl-certificate firefox

— kontur
fuente

1

Supongo que ahora necesita una CA para un certificado autofirmado porque Firefox ha ido ajustando los requisitos gradualmente en las últimas versiones. Sin embargo, con Let's Encrypt ya no hay razón para usar certificados autofirmados.

— Simon Greenwood

No quiero adivinar, pero creo que @SimonGreenwood tiene razón. Pero generalmente Firefox solo establece las nuevas opciones como predeterminadas y le permite editar la configuración. Verifica tu configuración de privacidad.

@Broco Si algo está en la configuración de seguridad, no en la configuración de privacidad. Como se indicó anteriormente, incluso he agregado una excepción de seguridad, pero Firefox todavía insiste en no poder validar el certificado, porque obviamente el emisor es desconocido.

— kontur

@kontur para mí, el enlace se trata de: preferencias # privacidad para establecer la configuración de privacidad y seguridad, por eso dije privacidad. Considera publicarlo como un error.

1

@SimonGreenwood Hay muchas razones para no usar encriptemos en una conexión local. Uno no querría configurar vamos a encriptar.

— Jon

15

Todavía no tengo del todo claro cómo encaja todo esto exactamente, pero como se señala en esta respuesta, los .dev dominios ahora son TLD oficiales. Como tal, parece que los navegadores fuerzan algún tipo de comportamiento HSTS y fuerzan las conexiones https. Para esos TLD parece que mi certificado autofirmado ya no fue aceptado en Firefox. Cambiar mis hosts virtuales para usar .testresolvió el problema sin tener que cambiar nada en mis certificados autofirmados.

Vale la pena señalar que en Firefox también mis hosts virtuales no SSL actuaron desde la versión 59 hoy, porque el comportamiento HSTS parecía forzar SSL en los hosts virtuales que no había configurado para servir a través de SSL. En Chrome, esto todavía funcionaba, pero de cualquier manera es seguro decir que alejarse del .devTLD ahora oficialmente resuelto resolverá muchos dolores de cabeza.

— kontur
fuente

1

Sí, .deves un TLD válido desde hace algún tiempo, así que NO lo use para nombrar sus recursos internos. Lo mismo para cualquier otro nombre: no uses ningún nombre que creas que nadie más usará. Utilice los nombres de prueba a los que se hace referencia en RFC2606 o simplemente registre un nombre de dominio verdadero en cualquier lugar y use un subdominio como int.example.como dev.example.compara sufijar todos sus nombres internos. Entonces nunca tendrá colisiones o problemas (¡siempre y cuando recuerde renovar el nombre de dominio cada año!)

— Patrick Mevzek

2

Ver ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts

— Patrick Mevzek

1

Gracias por el enlace. Las líneas de tiempo mencionadas allí no se alinean, pero tal vez el autor habló sobre avances de desarrollo o similares. Dado lo que sé ahora, es realmente difícil ver por qué los proveedores de navegadores no agregarían información adicional de depuración, en particular con respecto al error SSL en los .devdominios. A menos que sepa que es un TLD, no hay posibilidad de inferir que este es el problema.

— kontur

12

Hay una manera fácil de evitar esto.

Ir about:config
Busque "network.stricttransportsecurity.preloadlist".
Ponlo en false.

ADVERTENCIA: Esto deshabilitará HSTS por completo . Eche un vistazo a los comentarios sobre esta respuesta para una discusión sobre las desventajas de este método. Personalmente, creo que el beneficio supera el riesgo, pero usted es responsable de su propia seguridad.

— Andy Mercer
fuente

44

Esta es una muy mala idea, ya que esta configuración se aplicará a todos los sitios web que visite, no solo a los suyos. Estás bajando tu seguridad.

— Patrick Mevzek

Estoy en desacuerdo. HSTS es relativamente nuevo. Hemos estado bien sin él durante los últimos 20 años, por lo que decir que deshabilitarlo es muy malo para la seguridad es exagerado. En segundo lugar, incluso si ES una mala idea, en realidad no hay otra opción si quiero que mis servidores de desarrollo continúen funcionando, que no impliquen cambios realmente largos en mi entorno de desarrollo.

— Andy Mercer

1

Una solución como esta: security.stackexchange.com/a/154176 al menos afecta solo a un sitio, no a todos.

— Patrick Mevzek

1

Tan condescendiente como sé que esto va a sonar, a medida que envejezca, se dará cuenta de que cosas como "mejores prácticas" y "incorrecto" son flexibles y cambian con el tiempo. Lo que la gente considera "incorrecto" en este momento, no se consideró incorrecto durante muchos años, y puede que no lo sea nuevamente en el futuro. En cuanto a esta discusión específica, solo tendremos que aceptar estar en desacuerdo.

— Andy Mercer

1

Gracias por esta solución, funciona muy bien para mí en Firefox 59.0.1 (y Firefox Dev Edition 60). Nuestros .devproyectos actuales eventualmente se trasladarán a otro sufijo de TLD, pero por ahora esto ayuda a no detener el desarrollo local.

— Jake Bathman

4

Ajuste security.enterprise_roots.enableda truela about:configpágina resuelve esto para mí y permitió que mi certificado autofirmado para el trabajo durante el desarrollo.

Aquí hay un poco de discusión sobre los méritos de que esto esté activado de forma predeterminada:
establezca security.enterprise_roots.enabled en true de forma predeterminada .

Aunque la intención de este indicador es permitir que Firefox use el almacén raíz de CA de toda la máquina como una fuente válida para las autoridades de certificación, esto solucionó la situación para mi propio caso de uso en el que tengo un certificado de múltiples dominios autofirmado que uso localmente para pruebas (subjectAltName's) . Incluso después de agregar el certificado a la lista de certificados de Firefox, no fue hasta que encendí esto que permitió que se cargara el sitio local.

— Sean Aitken
fuente

Gracias, funcionó!

— informatik01

0

Tuve el mismo problema en el navegador web basilisk . Traté de cambiar la configuración del Proxy de red o de modificar los indicadores "network.stricttransportsecurity.preloadlist" o "security.enterprise_roots.enabled" ... pero no resolvió el botón que faltaba para agregar el certificado para el sitio web bloqueado. Solo esto logró atravesar:

Ir a about:support.
Haga clic Open Directoryen el perfil de su navegador.
Cierra el navegador por completo.
Edite el archivo " SiteSecurityServiceState.txt " en el directorio anterior.
Busque y elimine toda la línea que contiene el sitio HSTS bloqueado.
Guarde el archivo y vuelva a abrir su navegador en ese sitio.

— Noam Manos
fuente

-3

Fui por "Let's Encrypt"

https://letsencrypt.org/

Solo es válido por 3 meses a la vez, pero la actualización se puede automatizar.

Como puede ver en los comentarios, hay una trampa. Nuestros dominios de desarrollo y prueba se denominan dev-www.example.com y test-www.example.com. Usamos el certificado comodín de producción.

— Gerard H. Pille
fuente

55

¿El cifrado Let's no depende de que el servidor y el dominio estén disponibles públicamente? Estoy buscando opciones para usar SSL en hosts virtuales locales.

— kontur

Sí, eso no funciona para las personas que están haciendo desarrollo local.

— Andy Mercer

la pregunta es sobre DEV LOCAL

@Pieter, ¿es lo mismo que "desarrollo local"? Porque eso es lo que hacemos.

— Gerard H. Pille

1

@ GerardH.Pille Solo puede generar Encriptemos certificados si se puede acceder al servidor desde Internet. Para mi desarrollo local, este no es el caso, por lo que no es viable. Por favor avise si hay algo que me falta.

— kontur