Мы (моя компания) недавно переключили наши серверы имен с GoDaddy на Amazon. Наши сайты по-прежнему размещаются на GoDaddy. До переключения серверов имен все работало нормально.
У нас есть сайт, https://example.com что перенаправит на https если он изначально был введен как http. У нас есть второй сайт, расположенный по адресу example.com/second и разрешается в https://second.com. Это работает так же, как и первый сайт, который перенаправляет на https из http Запросы.
Теперь, когда мы поменяли серверы имен, https больше не разрешается. Если я пойду в http://second.com/non-http-part это не требует перенаправления, это работает. Но переход к индексу, в который выполняется перенаправление, приводит к тому, что страница вообще не загружается. Все https://example.com тоже не загружается.
Мы связались с Amazon, и они пришли к выводу, что проблема связана с .htaccess файлы. Мне это кажется странным, потому что это больше похоже на проблему с DNS, но это не моя область знаний, поэтому я могу полностью ошибаться.
Ниже наш .htaccess файл.
rewriteengine on
rewritecond %{HTTPS} off
rewritecond %{HTTP_HOST} ^www.example.com$ [OR]
rewritecond %{HTTP_HOST} ^example.com$
rewriterule ^(.*)$ "https\:\/\/example\.com\/$1" [R=301,L]
#---[SITE PASSWORD PROECTION]
#AuthName "Restricted Area"
#AuthType Basic
#AuthUserFile /home/some_user/public_html/example/includes/security/.htpasswd
#AuthGroupFile /dev/null
#require valid-user
#---[CENTRALIZED REQUESTED]
<IfModule mod_rewrite.c>
RewriteBase /
</IfModule>
#---[OPTIONS AND ERROR DOCUMENT HANDLING]
Options -Indexes
IndexIgnore *
Options +FollowSymLinks
ErrorDocument 400 /index.php
ErrorDocument 401 /index.php
ErrorDocument 402 /index.php
ErrorDocument 403 /index.php
ErrorDocument 404 /index.php
#---[DENY ACCESS TO SPECIFIC FILES]
<FilesMatch "^(config\.php|\.htaccess|\.htpasswd|\.log|php\.ini|php5\.ini|readme\.html)">
Deny from all
Allow from 127.0.0.1
</FilesMatch>
rewritecond %{REQUEST_FILENAME} !-f
rewritecond %{REQUEST_FILENAME} !-d
rewriterule . /index.php [L]
Даже несмотря на то, что ваш сценарий может показаться простым (в конце концов, это всего лишь проблема с доступом к HTTPS-сайту), все немного сложнее. Я собираюсь дать вам некоторую (надеюсь, подробную) помощь в процессе устранения неполадок.
Начнем с этого: "... Если я пойду в http://second.com/non-http-part который не требует перенаправления, он работает ..."
Это говорит о том, что разрешение DNS для "second.com" работает нормально. В любом случае, я бы проверил это напрямую, с помощью такой утилиты, как хозяин или копать землю. Это необходимо для гарантии того, что ваша система не полагаясь на какой-то файл "hosts", который может указывать на адреса, отличные от DNS. Кроме того, он полностью обходит проблемы с локальным кешем DNS.
Ниже вы можете увидеть пример:
verzulli@tablet-damiano:~$ host serverfault.com
serverfault.com has address 190.93.246.183
serverfault.com has address 190.93.247.183
verzulli@tablet-damiano:~$ dig serverfault.com
[...]
;; QUESTION SECTION:
;serverfault.com. IN A
;; ANSWER SECTION:
serverfault.com. 194 IN A 190.93.247.183
serverfault.com. 194 IN A 190.93.246.183
;; AUTHORITY SECTION:
serverfault.com. 90428 IN NS cf-dns02.serverfault.com.
serverfault.com. 90428 IN NS cf-dns01.serverfault.com.
[...]
;; Query time: 63 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun 6 09:15:13 2015
;; MSG SIZE rcvd: 199
verzulli@tablet-damiano:~$
Итак, теперь мы уверены, что DNS, на который полагается ваша локальная система, разрешается правильно.
Теперь я бы проверил путь HTTP, чтобы убедиться, что ничто между вашей локальной системой и удаленным веб-сервером не искажает HTTP-соединение. Это может быть типично в прозрачные прокси контексты. Обратите внимание: я предполагаю, что ваш браузер имеет прямой доступ к Интернету, без явной настройки прокси. Если это не так, просьба сообщить подробности.
Поэтому я бы проверил, есть ли внешний IP-адрес вашей системы (тот, который вы можете увидеть, открыв в своем браузере такие сайты, как этот) совпадает с тем, что указано в журнале доступа (правильно работающего) сервера apache. В моем случае я получаю:
aaa.bbb.ccc.dddaaa.bbb.ccc.ddd - - [06/Jun/2015:09:36:35 +0200] "GET / HTTP/1.1" 200 3650 "-" "[...]"Итак, теперь мы знаем, что при доступе к HTTP-сайту мы переходим прямо к веб-серверу (или, что еще лучше, с нелегко обнаруживаемыми промежуточными искажениями).
Теперь можно приступить к тесту HTTPS. Я не знаю, есть ли у вас интерактивный доступ к вашей удаленной системе, поэтому я не уверен, что вы сможете запустить tcpdump на нем, так что давайте продолжим проверку журнала (поскольку я уверен, что у вас есть доступ к файлам журнала). Мне бы:
Если в журналах ничего не отображается, то - предположим, ваш HTTPS-сервер ведет журнал правильно - мы можем предположить, что существует проблема в SSL-соединении между вашим браузером и вашим сервером.
Если присутствует строка LOG, то мы можем утверждать, что ваш браузер правильно подключился к HTTPS-серверу.
В обоих случаях дополнительную помощь можно получить с помощью «Инструмента разработчика» вашего браузера (в Chrome / Chromium и Firefox он встроен и может быть запущен с помощью CTRL-SHIFT-I). Инструмент разработчика может отслеживать всю сетевую активность, зарегистрированную браузером (см. ВКЛАДКУ «Сеть»), включая запросы HTTP / HTTPS и соответствующие ответы. С его помощью вы также должны увидеть REDIRECT в ответе HTTP, указывающий на URL-адрес HTTPS, определенный в вашем .htaccess правила.
Последнее замечание: в тех случаях, когда у вашего браузера возникают проблемы с установкой HTTPS-соединения с HTTPS-сервером (и, как таковая, из инструментов разработчика ничего не выходит), вы можете попробовать низкоуровневую проверку с помощью openssl c_client утилита, например:
openssl s_client -connect your.remote.https.site:443
Вышеупомянутая команда покажет все рукопожатия SSL, включая все подробности о сертификате сервера, и должна привести вас к невидимому запросу, ожидающему ваших общих методов HTTP (GET, POST и т. Д., Как в «GET /»).
К сожалению, я не могу сообщить вам более подробную информацию. Если проблемы не исчезнут, предоставьте информацию о результатах вышеуказанных проверок.
По моему опыту, когда мы переносим наш хостинг, нам нужно перенести и наш SSL. Просто получите ключ .pfx и настройте его на новом хостинг-провайдере. Если мы не настроим SSL на новом сервере, https не будет работать.