Веб-сайт https не может быть загружен без прокси - PullRequest
Новая
       43

Веб-сайт https не может быть загружен без прокси

0 голосов
/ 19 мая 2018

У меня есть сайт, на главной странице которого есть форумы (созданные с помощью Xenforo).Я недавно поставил HTTPS с Давайте зашифруем (я включил его на стороне сервера с помощью cPanel).Сайт работал нормально с HTTP.

Теперь, когда у меня HTTPS, у меня возникли проблемы, потому что некоторые люди могут получить доступ к сайту как всегда, а другие нет.Те, кто не может открыть мой сайт, должны использовать прокси, а затем сайт загружается.

Эта ошибка начала появляться после того, как я отредактировал строку в моем файле .htaccess: 

#   Mod_security can interfere with uploading of content such as attachments. If you
#   cannot attach files, remove the "#" from the lines below.
<IfModule mod_security.c>
    SecFilterEngine Off
    SecFilterScanPOST Off
</IfModule>

ErrorDocument 401 default
ErrorDocument 403 default
ErrorDocument 404 default
ErrorDocument 405 default
ErrorDocument 406 default
ErrorDocument 500 default
ErrorDocument 501 default
ErrorDocument 503 default

<IfModule mod_rewrite.c>
    RewriteEngine On

    # I HAVE ADDED THESE 2 NEW LINES
    RewriteCond %{SERVER_PORT} 80
    RewriteRule ^(.*)$ https://forums.example.com/$1 [R,L]

    #   If you are having problems with the rewrite rules, remove the "#" from the
    #   line that begins "RewriteBase" below. You will also have to change the path
    #   of the rewrite to reflect the path to your XenForo installation.
    #RewriteBase /xenforo

    #   This line may be needed to enable WebDAV editing with PHP as a CGI.
    #RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -l [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^.*$ - [NC,L]
    RewriteRule ^(data/|js/|styles/|install/|favicon\.ico|crossdomain\.xml|robots\.txt) - [NC,L]
    RewriteRule ^.*$ /index.php [NC,L]

</IfModule>

Я добавил эти 2 строки: 

RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://forums.example.com/$1 [R,L]

И теперь у меня возникла странная проблема: некоторые люди могут получить доступ к моему веб-сайту, другие не могут и им нужно использовать прокси!

Я добавил эти правила, потому что мне нужно перенаправить все http на https, поэтому http://forums.example.com/ должно стать https://forums.example.com/.У меня никогда не было этой проблемы раньше.Есть идеи?

1 Ответ

0 голосов
/ 20 мая 2018

Первый

Какое конкретное сообщение об ошибке получают эти люди?

Когда я строил Гринлок Я столкнулся с подобной проблемой, и оказалось, чтоэтот сертификат загружался некорректно, поэтому я предполагаю, что это ошибка TLS в браузерах, а не проблема DNS или HTTP.

Далее

Я незнаком с cPanel, но я очень хорошо знаком со стандартом ACME и клиентами.

Greenlock , certbot и многие другие клиенты Let's Encrypt используют соглашение об именовании файлов сертификатов, например:

  • privkey.pem
  • cert.pem
  • chain.pem
  • fullchain.pem (cert.pem + chain.pem)

У некоторых также есть bundle.pem (fullchain.pem + privkey.pem).

Многие веб-серверы требуют CRT и KEY в своей документации.Интуитивно вы можете подумать, что CRT будет cert.pem, а KEY privkey.pem.

Обычно это неверно.

CRT - это fullchain.pem

Если ваш сайт настроен на использование cert.pem в качестве CRT вместо fullchain.pem, у вас будетпроблема, которую вы описываете.

Причина в том, что любой, кто посетил любой сайт, который должным образом использует тот же промежуточный орган , поскольку вы увидите страницу, как и предполагалось - необходимыйchain.pem уже будет существовать в кеше браузера.

Однако любой, у кого браузер, у которого этого недостающего фрагмента нет в кеше, получит ошибку безопасности.

Зачемработать через прокси?

Это зависит от типа "прокси" - потому что это может означать разные вещи для разных людей.

Я предполагаю, что прокси используется для большего количества сайтов, чембраузер этого человека (особенно множество небольших сайтов-любителей, использующих эту же цепочку), и, возможно, прокси-сервер фактически загружает сайт, расшифровывает его, а затем передает его, или, возможно, проксиy каким-то образом дополняет цепочку сертификатов собственным кэшем.

Возможное решение для ошибки конфиденциальности браузера

Ваша проблема может полностью отличаться от проблемы, с которой я столкнулся.Это может быть совпадением, что симптомы кажутся такими похожими.

Я не хочу увести вас в кроличью нору, которая вас никуда не приведет, но я думаю, что проверка ваших настроек, чтобы убедиться, что вы 'Использование fullchain.pem, а не cert.pem - важный первый шаг.

Возможное решение для перенаправлений .htaccess

Проблема с перенаправлениями звучит для меня случайно.Я сомневаюсь, что это связано.

Скорее всего, после того, как ваш сайт вызвал https, все больше посетителей с браузерами, у которых не было промежуточных сертификатов Let's Encrypt в их кешах, внезапно начали замечать проблему, потому что теперь они затронуты.

Однако, если вы можете отменить эти изменения и подтвердить, что HTTPS (с поддержкой SSL) работает для этих пользователей, тогда я бы предложил вместо того, чтобы делать перенаправления, вы попытаетесь добавить заголовки, которые будут делать то же самое:

...