Перенаправить https на другой https

Я гуглил по этому вопросу, и по иронии судьбы я не могу найти конкретный ответ. Я сам отвечал на этот вопрос в прошлом, и теперь я не могу вспомнить собственное объяснение.

Несколько раз в год кто-то будет просить меня сделать это. Я хотел бы указать им на какую-то респектабельную статью, которая объясняет это.

Я хочу взять URL-адрес по адресу https://www.example.com/ и перенаправить трафик на https://www.example2.com/ .

Я считаю, что это должно быть технически возможно, но нежелательно. Что не так с этим методом? Будут ли браузеры получать всплывающее окно безопасности, поскольку я перенаправляю их на другой сайт? Кто-нибудь может предоставить ссылку на некоторую респектабельную документацию, которая объясняет это?

Вы можете сделать это, оба сайта должны иметь действительный сертификат SSL. Таким образом, браузеры не будут отображать всплывающие окна. Однако, если оба сайта существуют на одном и том же сервере, оба домена должны размещаться с разных IP-адресов.

Веб-сервер просматривает заголовок «Host» в HTTP-запросе, чтобы увидеть, какой сайт ему нужно обслуживать. Согласование SSL происходит перед отправкой HTTP-запроса, поэтому в этот момент веб-сервер не может определить, какой веб-сайт будет отображаться. Он всегда будет отправлять один и тот же сертификат в браузер.

Есть два способа обойти это:

• Имейте подстановочный сертификат для * .example.com, чтобы все дочерние домены могли использовать один и тот же сертификат.
• Запустите каждый сайт SSL с другим IP-адресом. Таким образом, веб-сервер знает, какой SSL-сертификат он может отправить браузеру, проверив IP-адрес, который получил входящее соединение.

Обратите внимание, что вполне возможно подключить несколько IP-адресов к одному сетевому адаптеру, просто вам нужен второй IP-адрес, доступный в вашем пространстве IP-адресов.

Обновление: в настоящее время вы можете запустить несколько сайтов SSL на одном IP. Чтобы включить это, настройте поддержку SNI на вашем веб-сервере. Большинство современных браузеров (за исключением Windows XP и Android 2) поддерживают это.

Я никогда не пробовал это, поэтому я не говорю из конкретного опыта, но это должно работать. Вам понадобится действительный SSL-сертификат для https://www.example.com, так как имя хоста зашифровано внутри заголовка HTTP, поэтому ваш сервер не будет знать о перенаправлении, пока он не расшифрован. После этого он должен перенаправить как обычный HTTP-запрос.

Почему это было бы нежелательно?

Например, Big Bank и Little Bank используют сайты на https, чтобы обеспечить клиентам ощущение безопасности. Большой Банк покупает Маленький Банк. В какой-то момент ИТ-специалисты установят перенаправление для https://www.littlebank.com на https://www.bigbank.com . Это законная причина для перенаправления с https на https.

Это должно работать нормально.

Единственное несоответствие, которое, я думаю, присутствует в текущих ответах, которые могут возникнуть для вас, заключается в том, что при любом из этих обстоятельств истинное перенаправление (т. Е. Браузер переназначается на www.example2.com) будет хорошо, но если вы замаскируете это так что браузер все еще думает, что он указывает на www.example.com, когда на самом деле вы отправили его на www.example2.com, именно здесь вы увидите предупреждения безопасности именно потому, что пытаетесь обмануть пользователя.

Короткая версия нормального перенаправления должна быть в порядке, маскировка адресов, вероятно, оставит вам много объяснений.

Как видите, эту проблему можно решить на транспортном уровне. Допустим, у вас есть запись DNS A для example.com, указывающая на 192.168.0.1. Когда вы набираете https://example.com в браузере, ваш компьютер устанавливает TCP-соединение с сервером с IP 192.168.0.1, где какой-то процесс прослушивает порт 443. Что если одновременно сервер (который не пытается получить подробную информацию о данных, отправляемых через этот сеанс TCP, например, при запуске согласования SSL), устанавливает TCP-соединение с 192.168.0.2 (другой сервер с DNS указывает на него example2.com. Устанавливаемость HA proxy linux, установленная на первом сервере, может решить эту проблему с помощью такой конфиг:

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

Но это приведет к ошибке SSL-сертификата, если ваш веб-сервер example2.com не покажет SSL-сертификат, например, с CN = example2.com и SAN = example.com.

Или вы можете настроить DNS slpit horizon, когда от пользователей perstective example.com и example2.com перейдут к 192.168.0.1.