ssl — Не получается сделать редирект с https на http в nginx
Задать вопрос
Вопрос задан
Изменён 3 года 7 месяцев назад
Просмотрен 301 раз
Всем привет. Купил домен, который ранее принадлежал другому человеку. От старого домена в индексе google присутствуют страницы с https. Сайт, который хочу залить на этот домен работает на http, поэтому мне нужно сделать редирект при заходе на страницу с https на http. Перерыл интернет, перепробовал кучу вариантов — не работает.
Вот мой конфиг nginx:
user nginx; worker_processes auto; error_log /var/log/nginx/error.log; pid /run/nginx.pid; events { worker_connections 1024; } http { access_log off; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; client_max_body_size 10M; include /etc/nginx/mime./index.php last; break; } } location ~ \.php$ { root /home/site12; try_files $uri =404; fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include /etc/nginx/fastcgi_params; } } }
Добавил
if ($scheme = https) { return 301 http://$host$request_uri; }
как мне кажется самый логичный вариант, но не работает… Помогите сделать редирект с http на https
- nginx
- ssl
3
Без валидного сертификата сделать редирект никак не получится. Редирект сработает только после установки https соединения.
LetsEncrypt никто ещё не отменял.
Зарегистрируйтесь или войдите
Регистрация через Google
Регистрация через Facebook
Отправить без регистрации
Почта
Необходима, но никому не показывается
Отправить без регистрации
Почта
Необходима, но никому не показывается
Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки
.
- php
- .htaccess
- http-status-code-404
- сайты
- error404
2
Зарегистрируйтесь или войдите
Регистрация через Google
Регистрация через Facebook
Регистрация через почту
Отправить без регистрации
Почта
Необходима, но никому не показывается
Отправить без регистрации
Почта
Необходима, но никому не показывается
Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки
Перенаправить https на другой https
спросил
Изменено 4 года, 5 месяцев назад
Просмотрено 91к раз
Я гуглил этот вопрос и, по иронии судьбы, не смог найти конкретного ответа. Я сам отвечал на этот вопрос в прошлом, и теперь я не могу вспомнить собственное объяснение.
Несколько раз в год кто-нибудь будет просить меня сделать это. Я хотел бы указать им на какую-то респектабельную статью, которая объясняет это.
Я хочу взять URL-адрес https://www.example.com/ и перенаправить трафик на https://www.example2.com/ .
Я считаю, что это технически возможно, но нежелательно. Что не так с этим методом? Появятся ли в браузерах всплывающие окна безопасности, если я перенаправляю их на другой сайт? Может ли кто-нибудь дать ссылку на какую-нибудь респектабельную документацию, которая объясняет это?
3
Вы можете сделать это, оба сайта должны иметь действующий сертификат SSL. Таким образом, браузеры не будут показывать всплывающее окно безопасности. Однако если оба сайта существуют на одном сервере, оба домена должны размещаться с разных IP-адресов.
Веб-сервер просматривает заголовок «Host» в HTTP-запросе, чтобы определить, какой сайт ему нужно обслуживать. Согласование SSL происходит до отправки HTTP-запроса, поэтому в этот момент веб-сервер не может сказать, какой веб-сайт он будет отображать. Он всегда будет отправлять один и тот же сертификат в браузер.
Есть два способа обойти это:
- Иметь групповой сертификат для *.example.com, чтобы все поддомены могли использовать один и тот же сертификат.
- Запускайте каждый сайт SSL с другого IP-адреса. Таким образом, веб-сервер знает, какой SSL-сертификат он может отправить в браузер, проверяя IP-адрес, с которого было получено входящее соединение.
Обратите внимание, что вполне возможно подключить несколько IP-адресов к одному и тому же сетевому адаптеру, просто вам нужен второй IP-адрес, доступный в вашем пространстве IP-адресов.
Обновление: В настоящее время вы можете запускать несколько сайтов SSL на одном IP-адресе. Чтобы включить это, настройте поддержку SNI на своем веб-сервере. Большинство современных браузеров (кроме Windows XP и Android 2) поддерживают это.
2
Я никогда не пробовал это, поэтому я не говорю о конкретном опыте, но это должно работать. Вам потребуется действующий SSL-сертификат для https://www.example.com, так как имя хоста зашифровано внутри заголовка HTTP, поэтому ваш сервер не будет знать о перенаправлении, пока оно не будет расшифровано. После этого он должен перенаправить, как обычный HTTP-запрос.
Почему это нежелательно?
Например, Big Bank и Little Bank используют сайты на https, чтобы клиенты чувствовали себя в безопасности. Большой банк покупает Маленький банк. В какой-то момент ИТ-специалисты настроят перенаправление с https://www.littlebank.com на https://www.bigbank.com. Это уважительная причина для перенаправления с https на https.
Это должно работать нормально.
1
Единственное отключение, которое, как я думаю, присутствует в текущих ответах, которые могут появиться для вас, заключается в том, что в любом из этих обстоятельств истинное перенаправление (т. е. браузер перенаправляется на www.example2.com) будет в порядке, но если вы замаскируйте это так, чтобы браузер все еще думал, что он указывает на www.example.com, хотя на самом деле вы отправили его на www.example2.com,
Краткая версия: нормальное перенаправление должно подойти, маскировка адреса, вероятно, оставит вам много объяснений.
1
Как видите, эту проблему можно решить на транспортном уровне. Допустим, у вас есть запись DNS A, например example.com, указывающая на 192.168.0.1. Когда вы вводите https://example.com в браузере, ваш компьютер устанавливает TCP-соединение с сервером с IP 19.2.168.0.1, где какой-то процесс прослушивает порт 443. Что, если в то же время сервер (который не пытается получить подробную информацию о данных, отправленных через этот TCP-сеанс, например, запуская согласование SSL) устанавливает TCP-соединение с 192.
по умолчанию журнал глобальный режим TCP повторяет 2 опция повторной отправки опция tcplog опция tcpka вариант кличка опция srvtcpka тайм-аут соединения 5s клиент тайм-аута 24 часа # клиент тайм-аута-> haproxy (интерфейс) таймаут сервера 60м слушать фронт443 192.168.0.1:443 сервер back443 192.168.0.2:443
Но это вызовет ошибку сертификата SSL, если только ваш веб-сервер example2.com не покажет сертификат SSL с CN=example2.com и SAN=example.com, например.
Или вы можете установить горизонт DNS slpit, когда пользователи persective example.com и example2.com разрешаются в 192.168.0.1.
Зарегистрируйтесь или войдите в систему
Зарегистрируйтесь с помощью Google
Зарегистрироваться через Facebook
Зарегистрируйтесь, используя электронную почту и пароль
Опубликовать как гость
Электронная почта
Требуется, но не отображается
Опубликовать как гость
Электронная почта
Требуется, но не отображается
Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie
Как видно из закомментированных строк, я пробовал несколько подходов.
файл2:
NameVirtualHost 123.45.67.890:443 <Виртуальный хост 123.45.67.890:443> DocumentRoot "/opt/www/example-docroot" Имя сервера example.com DirectoryIndex index.html SSLEngine включен SSLCipherSuite ВСЕ:!ADH:!EXPORT56:RC4+RSA:+ВЫСОКИЙ:+СРЕДНИЙ:+НИЗКИЙ:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/httpd/conf.d/ssl/example.com/csr.example.2011.pem.blade SSLCertificateKeyFile /etc/httpd/conf.d/ssl/example.com/nokey.example.2011.pem SSLCACertificateFile /etc/httpd/conf.d/ssl/example.com/CA.blade.2011.csr <Файлы ~ "\.(cgi|shtml|phtml|php3?)$">SSLOptions +StdEnvVars файлы> <Каталог "/etc/httpd/cgi-bin"> SSLOptions +StdEnvVars Каталог> виртуальный хост>
Кое-что удалено для простоты, имена изменены, чтобы защитить невиновных.
Я обновляю эти файлы на сервере /etc/httpd/vhosts
затем запускаю
перезапуск apachectl
Что дает мне эти предупреждения:
[предупреждение] NameVirtualHost 123.45.67.890:80 не имеет VirtualHosts [предупреждать] NameVirtualHost 123.45.67.890:80 не имеет виртуальных хостов
С этого сервера работает множество виртуальных хостов. Приведенные выше конфигурации кажутся выровненными, поэтому я не думаю, что эти предупреждения здесь применимы. Может быть, неправильно.
При обновлении страницы 80 (http) по умолчанию в моем браузере всегда отображается страница http по умолчанию.
Любые предложения о том, как заставить перенаправление работать?
- apache-2.2
- https
- виртуальный хост
3
Многие примеры работают на определенных конфигурациях. Это всегда работает, независимо от того, какую конфигурацию использует ваш сервер Apache:
RewriteEngine On RewriteCond %{SERVER_PORT} !443 Правило перезаписи ^(/(. *))?$ https://%{HTTP_HOST}/$1 [R=301,L] 9(.*)$ https://www.site.com$1 виртуальный хост>
Это работает как шарм, и вам не нужна никакая конфигурация где-либо еще или какой-либо дополнительный модуль.
3
Для этого лучше использовать .htaccess
(если возможно), не нужно возиться с конфигурационными файлами апача.
Добавьте эти строки в начало вашего .htaccess
.
RewriteEngine вкл. RewriteCond %{HTTPS} выкл. Правило перезаписи (.*) https://%{HTTP_HOST}%{REQUEST_URI}
4
У меня была такая же проблема с apache 2.4 на centos 7, и исправление, которое сработало для меня без использования RewriteEngine, состояло в том, чтобы добавить :443 к директиве ServerName в VirtualHost для https.
<Виртуальный хост 123.45.67.890:443> DocumentRoot "/opt/www/example-docroot" Имя_сервера example. com:443
Наша проблема заключалась в приоритете файла конфигурации. Короче говоря, HTTP VirtualHost в 000-default.conf
переопределял настройки, которые мы создали в нашем собственном файле конфигурации.
Это сбивает с толку любого, кто знает значение слова «по умолчанию», которое означает что-то, что используется только в том случае, если оно не определено где-либо еще. Мы по глупости предположили, что 000-default.conf
предоставит конфигурацию только в том случае, если она не определена в другом файле конфигурации.
Мы ошибались. Apache просто использует конфигурацию в первом файле, который он встречает, на основе имени файла в алфавитно-цифровом порядке. Он переходит к следующему файлу, если не может найти соответствующий VirtualHost в этом файле, что вызывает забавную путаницу, если вы не знаете, как это работает, но довольно аккуратно, как только вы это сделаете.
1
Я думаю, что в прошлый раз, когда это случилось со мной, возможно, это было что-то странное, например, NameVirtualHost *:80
/ NameVirtualHost *:443
и/или Listen 80
/ Listen 443
были где-то кроме ports. conf для апач2.
Вот что у меня есть в VirtualHost для перенаправления на https для всех страниц, кроме прессы (было видео, которое нельзя было обслуживать через https, поэтому пришлось перенаправить обратно на http, иначе люди получили бы уродливые предупреждения о том, что страница небезопасна): 9.*$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NC] виртуальный хост>
Проблема устранена очисткой кеша моего браузера.
Я использую wamp-сервер в Windows (Apache/2.4.41 (Win64) OpenSSL/1.1.1c PHP/7.3.12). Я успешно установил сертификаты SSL. Теперь https работает без проблем. Но перенаправление http не работает.
<Виртуальный хост *:80> имя_сервера test.com Псевдоним сервера www.test.com Редирект постоянный / https://test.com/ виртуальный хост> <Виртуальный хост *:443> имя_сервера test.com Псевдоним сервера www.test.com DocumentRoot "C:/wamp64/www/test" <Каталог "C:/wamp64/www/"> Опции +Индексы +Включает +FollowSymLinks +MultiViews Разрешить переопределить все Требовать все предоставленные Каталог> SSLEngine включен SSLCertificateFile "C:/wamp64/bin/apache/apache2.