Redireccionar https a otro https

He estado buscando en Google esta pregunta e, irónicamente, no puedo encontrar una respuesta concreta. He respondido esta pregunta yo mismo en el pasado, y ahora no puedo recordar mi propia explicación.

Varias veces al año, alguien me pedirá que haga esto. Me gustaría señalarles algún tipo de artículo respetable que explique esto.

Quiero tomar la URL en https://www.example.com/ y redirigir el tráfico a https://www.example2.com/ .

Creo que esto debería ser técnicamente posible, pero no es deseado. ¿Qué tiene de malo este método? ¿Los navegadores obtendrán una ventana emergente de seguridad ya que los estoy redirigiendo a otro sitio? ¿Alguien puede proporcionar un enlace a alguna documentación respetable que explique esto?

Puede hacer esto, ambos sitios deben tener un certificado SSL válido. De esta forma, los navegadores no mostrarán una ventana emergente de seguridad. Sin embargo, si ambos sitios existen en el mismo servidor, ambos dominios deben estar alojados desde diferentes direcciones IP.

Un servidor web mira el encabezado "Host" en la solicitud HTTP para ver qué sitio necesita servir. La negociación SSL ocurre antes de que se envíe la solicitud HTTP, por lo que en ese momento el servidor web no puede decir qué sitio web mostrará. Siempre enviará el mismo certificado al navegador.

Hay dos formas de solucionar esto:

• Tenga un certificado comodín para * .example.com, de modo que todos los subdominios puedan compartir el mismo certificado.
• Ejecute cada sitio SSL en una dirección IP diferente. De esta manera, el servidor web sabe qué certificado SSL puede enviar al navegador al inspeccionar la dirección IP que recibió la conexión entrante.

Tenga en cuenta que es perfectamente posible conectar varias direcciones IP al mismo adaptador de red, es solo que necesita una segunda dirección IP disponible en su espacio de direcciones IP.

Actualización: hoy en día, puede ejecutar múltiples sitios SSL en una sola IP. Para habilitar esto, configure el soporte SNI en su servidor web. La mayoría de los navegadores modernos (excepto Windows XP y Android 2) lo admiten.

Nunca he intentado esto, así que no hablo por experiencia concreta, pero debería funcionar. Deberá tener un certificado SSL válido para https://www.example.com ya que el nombre de host está encriptado dentro del encabezado HTTP para que su servidor no sepa redirigir hasta que se desencripte. Después de eso, debe redirigirse como lo haría con una solicitud HTTP normal.

¿Por qué sería esto no deseado?

Como ejemplo, Big Bank y Little Bank administran sitios en https para brindar a los clientes una sensación de seguridad y felicidad. Big Bank compra Little Bank. En algún momento, la gente de TI establecerá una redirección para https://www.littlebank.com a https://www.bigbank.com . Esta es una razón legítima para redirigir de https a https.

Esto debería funcionar bien.

La única desconexión que creo que está presente en las respuestas actuales que pueden surgir para usted es que, en cualquiera de estas circunstancias, una redirección verdadera (es decir, el navegador se redirige a www.example2.com) estará bien, pero si enmascara esto de modo que el navegador todavía piense que está apuntando a www.example.com cuando en realidad lo ha enviado a www.example2.com, aquí es donde verá advertencias de seguridad precisamente porque podría estar tratando de engañar al usuario.

La versión corta es una redirección normal que debería estar bien, el enmascaramiento de direcciones probablemente te dejará con muchas explicaciones que hacer.

Como se ve, este problema se puede resolver en una capa de transporte. Digamos que tiene un registro DNS A para example.com que apunta a 192.168.0.1. Cuando escribe https://example.com en un navegador, su PC estableció una conexión TCP a un servidor con IP 192.168.0.1, donde algún proceso escucha en el puerto 443. ¿Qué sucede si al mismo tiempo el servidor (que no está intentando entrar en detalles de los datos enviados a través de esta sesión TCP, como comenzar la negociación SSL) establece una conexión TCP a 192.168.0.2 (otro servidor con DNS A example2.com apuntando a él. La utilidad de Linux proxy HA instalada en el primer servidor podría resolver esto con una configuración como esa:

defaults
        log    global
        mode    tcp
        retries 2
        option redispatch
        option tcplog
        option tcpka
        option clitcpka
        option srvtcpka
        timeout connect 5s      
        timeout client  24h     #timeout client->haproxy(frontend)
        timeout server  60m

listen front443 192.168.0.1:443
    server back443 192.168.0.2:443

Pero esto causará un error de certificado SSL a menos que su servidor web example2.com muestre un certificado SSL con CN = example2.com y SAN = example.com, por ejemplo.

O puede configurar un horizonte slpit DNS cuando los usuarios perspective example.com y example2.com resuelven 192.168.0.1.