.htaccess redirigir solo se ejecuta después de la advertencia del navegador

Question

Tengo una regla de reescritura que obliga a HTTPS y www. El certificado SSL es para la versión www del sitio. El sitio completo debe ser HTTPS.

El problema es que si la solicitud es https://example.com/ el navegador muestra una página de advertencia antes de que se pueda ejecutar la redirección. ('Esta conexión no es de confianza' en Firefox y 'Probablemente este no sea el sitio que estás buscando' en Chrome)

Si el usuario agrega una excepción en Firefox o ignora el error en Chrome, la regla de reescritura se ejecuta y son redireccionamientos a la versión www del sitio con una página 100% segura.

RewriteEngine on 

RewriteCond %{HTTP_HOST} ^example.com$ [OR] 
RewriteCond %{HTTPS} !on 
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L] 

RewriteCond %{HTTP_HOST} ^www.example.com$ 
RewriteCond %{HTTPS} !on 
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L] 

He estado probando las reglas en el sitio, así como en http://martinmelin.se/rewrite-rule-tester/

¿Cómo puedo conseguir la redirección a ejecutar antes de la advertencia del navegador?

Answer 1

La redirección de https://example.com a https://www.example.com solo puede suceder después de que el cliente haya realizado una solicitud inicial exitosa al https://example.com.

Esto se debe a que HTTPS es HTTP sobre TLS/SSL (ver RFC 2818), que primero establece la conexión SSL/TLS antes de enviar cualquier tráfico HTTP. mod_rewrite siempre se aplicará después de que se establezca la conexión SSL/TLS. No hacerlo sería en realidad un problema de seguridad, ya que un atacante podría reescribir y redirigir al cliente antes de que se haya verificado el certificado. Incluso si la actualización de TLS estaba dentro de HTTP (RFC 2817, que prácticamente nunca se usa/se admite y no es https), aún desea que la redirección provenga de una entidad confiable.

Para esta conexión inicial al trabajo, el servidor en https://example.com debe tener un certificado válido para example.com; de lo contrario, esta conexión ni siquiera ocurrirá (y el servidor no enviará una respuesta de redirección).

para lograr su objetivo, es necesario solicitudes de https://example.com presentar un certificado válido para example.com y las solicitudes de https://www.example.com presentar un certificado válido para www.example.com.

hay dos soluciones:

• El uso de dos certificados distintos para cada uno de los ejércitos, ya sea mediante el uso de distintas direcciones IP o mediante el uso de Servidor de Nombres de indicación. La desventaja aquí es que no todos los clientes admiten SNI, incluso si se está volviendo más común.
• Usando un único certificado que es válido para example.com y www.example.com. Esto se puede lograr obteniendo un certificado con múltiples entradas DNS de Nombre Alternativo del Sujeto (SAN) (no funcionará con solo *.example.com ya que el punto no es parte del patrón comodín).

La última es sin duda la solución más fácil. Es bastante común que las CA emitan certificados que tengan entradas de SAN para example.com y www.example.com cuando solicite una u otra opción, a veces sin cargo adicional.

Answer 2

This post direcciones de su problema, y ​​proporciona la siguiente respuesta:

que necesitará un CERT para example.com si se quiere evitar el problema CERT válido. Por razones de seguridad, los redireccionamientos previos a la autenticación no están permitidos.

Otra opción podría ser la de obtener un certificado de comodín, lo que permite igualar para *.example.com. (Al parecer, esto no funcionará. Gracias @Giel)

Se podría hacer http://example.com/ redirigir a https://www.example.com/, pero eso no te puede ayudar si ya tiene los usuarios que visitan https://example.com/.