Как настроить работу https

Настройка сайта для работы по HTTPS

После установки SSL-сертификата необходимо настроить перенаправление всех запросов с протокола HTTP на HTTPS. Сделать это можно в настройках вашей CMS и с помощью директив в файле .htaccess.

Специалисты RU-CENTER могут провести все необходимые операции для корректной установки SSL-сертификата на сайт за вас: оставьте заявку на оказание услуги «Настройка SSL-сертификата».

Чтобы настроить перенаправление c HTTP на HTTPS на хостинге RU-CENTER:

1. Перейдите в раздел Файловый менеджер панели управления хостингом.

2. Выберите папку с названием сайта, на который вы установили SSL-сертификат, и перейдите в папку docs (корневой каталог).

3. На панели инструментов нажмите Создать файл и укажите название .htaccess.

4. Нажмите на созданный файл для редактирования и добавьте в него следующие директивы:

Для корректной работы должен быть включен модуль headers_module в разделе Управление веб-сервером панели управления хостингом.

Если файл .htaccess на вашем сайте уже существует, откройте файл и добавьте указанные выше строки в его начало.

5. Сохраните изменения и проверьте работу сайта. Сайт должен открываться по HTTPS. Если сайт отображается корректно и отображается в адресной строке значок защищенного соединения, то настройка произведена корректно.

Если после настройки перенаправления сайт отображается некорректно, то это может быть связано с наличием смешанного контента (Mixed Content). В этом случае часть содержимого загружается на страницу сайта по небезопасному протоколу HTTP вместо HTTPS, что не позволяет считать страницу сайта полностью безопасной. Как правило, это можно исправить методом замены абсолютных ссылок на относительные, т.е. в каждом файле проекта поменять ссылки вида — https://site.ru/content/ на относительные— /content/, а для внешних ссылок указать в адресе протокол https://.

6. Если на вашем сайте установлена CMS, вам необходимо произвести дополнительные действия по настройке HTTPS-соединения и оповестить поисковики об изменениях.

Рекомендуем вам обратиться к документации по CMS и выполнить следующие действия:

• для сайта на WordPress: необходимо изменить протокол сайта с HTTP на HTTPS. Изменить основной протокол сайта с HTTP на HTTPS можно в разделе Настройки → Общие настройки в панели администрирования WordPress;

• для сайта на Joomla: в панели управления CMS перейдите в раздел Общие настройки → Сервер → Включить SSL;

• для сайта на Drupal: настройте переадресацию и отредактируйте ссылки, как это описано в пунктах 1-5 этой инструкции.

• для сайта на Opencart: в панели управления CMS-сайта перейдите в раздел Сервер → Безопасность и включите опцию Использовать SSL и добавьте ключ шифрования конфиденциальной информации при обработке заказа.

• для сайта на MODX: в панели управления сайта перейдите в раздел Системные настройки → Система и сервер, найдите тип сервера и измените протокол на HTTPS.

7. Если настройки для SEO уже сделаны, нужно произвести дополнительные действия по настройке HTTPS-соединения.

Для этого отредактируйте файл robots.txt, указав протокол HTTPS в директивах Host и sitemap :

Host : https://www.site.ru
sitemap : https://www.site.ru/sitemap.xml

8. Оповестите поисковые системы об изменениях на вашем сайте после завершения настройки HTTPS-соединения:

• перейдите в Яндекс.Вебмастер в раздел Индексирование → Переезд сайта и установите отметку в поле Добавить HTTPS.

• зайдите в Google Search Console и добавьте версию сайта с HTTPS.

Туториал: Как установить SSL-сертификат на сайт?

Источник

Настройка HTTP и HTTPS

Службы и клиенты WCF могут взаимодействовать по протоколам HTTP и HTTPS. Параметры HTTP/HTTPS задаются с помощью служб IIS или посредством использования средства командной строки. Когда служба WCF размещается в службах IIS, параметры HTTP или HTTPS можно задать в службах IIS (с помощью средства inetmgr.exe). Если служба WCF является резидентной, параметры HTTP или HTTPS задаются с помощью средства командной строки.

Как минимум необходимо настроить регистрацию URL-адресов и добавить исключение брандмауэра для URL-адреса, который будет использоваться службой. Эти параметры можно настроить с помощью средства Netsh.exe.

Настройка резервирования пространства имен

Резервирование пространства имен назначает права на часть пространства имен URL-адреса HTTP определенной группе пользователей. Резервирование предоставляет этим пользователям право создавать службы, которые ожидают передачи данных в указанной части пространства имен. Резервирования — это префиксы URL-адресов. Это означает, что резервирование охватывает все вложенные пути пути резервирования. Резервирования пространства имен позволяют использовать подстановочные знаки двумя способами. В документации по API HTTP-сервера описывается Порядок разрешения между утверждениями пространства имен, которые используют подстановочные знаки.

Запущенное приложение может создать аналогичный запрос для добавления регистраций пространства имен. Регистрации и резервирования конкурируют за части пространства имен. Резервирование может иметь приоритет над регистрацией в соответствии с порядком разрешения, указанным в порядке разрешения между утверждениями пространства имен, которые используют подстановочные знаки. В этом случае резервирование не позволяет запущенному приложению получать запросы.

В следующем примере используется средство Netsh.exe:

Эта команда добавляет резервирование URL-адресов для указанного пространства имен URL-адреса для учетной записи DOMAIN\user. Для получения дополнительных сведений об использовании команды netsh введите netsh http add urlacl /? в командной строке и нажмите клавишу ВВОД.

Настройка исключения брандмауэра

При резидентном размещении службы WCF, которая осуществляет взаимодействие по протоколу HTTP, необходимо добавить исключение в конфигурацию брандмауэра, чтобы входящие соединения могли использовать определенный URL-адрес.

Настройка SSL-сертификатов

Протокол SSL использует сертификаты в клиенте и службе для хранения ключей шифрования. Сервер предоставляет свой SSL-сертификат при подключении, чтобы клиент мог проверить удостоверение сервера. Для обеспечения взаимной проверки на обеих сторонах подключения сервер также запрашивает сертификат у клиента.

Сертификаты хранятся в централизованном хранилище в соответствии с IP-адресом и номером порта подключения. Специальный IP-адрес 0.0.0.0 соответствует любому IP-адресу локального компьютера. Обратите внимание, что хранилище сертификатов не различает URL-адреса в зависимости от пути. Службы с одним и тем же сочетанием IP-адреса и порта должны иметь общие сертификаты, даже если их пути в URL-адресе различаются.

Настройка списка ожидания передачи данных по протоколу IP

API HTTP-сервера привязывается к IP-адресу и порту только после регистрации URL-адреса пользователем. По умолчанию API HTTP-сервера привязывается к порту в URL-адресе для всех IP-адресов компьютера. Конфликт возникает, если приложение, которое не использует API сервера HTTP, было ранее привязано к этому сочетанию IP-адреса и порта. Список прослушивания IP-адресов позволяет службам WCF сосуществовать с приложениями, которые используют порт для некоторых IP-адресов компьютера. Если в списке ожидания передачи данных по протоколу IP содержатся какие-либо записи, API HTTP-сервера привязывается только к IP-адресам, указанным в списке. Для изменения списка ожидания передачи данных по протоколу IP требуются привилегии администратора.

Используйте средство Netsh для изменения списка прослушивания IP-адресов, как показано в следующем примере:

Другие параметры конфигурации

При работе с привязкой WSDualHttpBinding клиентское соединение использует значения по умолчанию, совместимые с резервированием пространства имен и брандмауэром Windows. При необходимости настроить базовый адрес клиента для двустороннего соединения, необходимо, кроме того, настроить эти параметры HTTP в клиенте так, чтобы они соответствовали новому адресу.

Источник

Мигрируем на HTTPS

В переводе этого документа описываются шаги, которые необходимо предпринять для перевода вашего сайта с HTTP на HTTPS. Шаги можно выполнять с любой скоростью – либо всё за день, либо один шаг за месяц. Главное, делать это последовательно.

Каждый шаг улучшает ваш сервер и важен сам по себе. Однако, сделать их все – обязательно для того, чтобы гарантировать безопасность вашим посетителям.

Для кого предназначена эта инструкция?

Администраторы, разработчики и их менеджеры – те, кто обслуживает сайты, в данный момент использующие только HTTP-соединение. При этом они желают мигрировать, или хотя бы поддерживать, HTTPS.

1: Получение и установка сертификатов

Если вы ещё не получили сертификаты – необходимо выбрать поставщика, и купить сертификат. Сейчас есть пара возможностей даже получить сертификаты бесплатно – например, их выдаёт контора RapidSSL. Кроме того, в 2015 году Mozilla обещают сделать бесплатную выдачу сертификатов.

Скопируйте полученные сертификаты на ваши фронтенд-сервера куда-нибудь в /etc/ssl (Linux / Unix) или в приемлемое место для IIS (Windows).

2: Включение HTTPS на сервере

Здесь надо определиться:

— либо использовать хостинг по IP, когда у каждого хоста свой IP
— либо отказаться от поддержки пользователей, которые используют IE на Windows XP или Android с версией менее 2.3

На большинстве сайтов настроен виртуальный хостинг, который работает с доменными именами (name-based) – это экономит IP-адреса и вообще более удобно. Проблема в том, что IE и древний Android не понимают Server Name Indication (SNI), а это критично для работы HTTPS при name-based хостинге.

Когда-нибудь все эти клиенты вымрут. Вы можете отслеживать количество таких клиентов и решить, нужно их поддерживать или нет.

Далее настройте поддержку сертификатов, которые вы получили, в вашем веб-сервере. Конфигурацию сервера можно создать через Mozilla configuration generator или SSLMate.

Если у вас много хостов и поддоменов – кажды из них потребует установки подходящего сертификата. Для поддоменов лучше использовать сертификаты с маской типа *.domain.ru

В идеале, вам необходимо переадресовывать все запросы к HTTP на HTTPS и использовать Strict Transport Security (см. шаги 4 и 5)

После этого проверьте работу сайта с новыми настройками при помощи инструмента Qualys SSL Server Test. Добейтесь того, чтобы сайт заслуживал оценки A или A+.

3: Сделайте все внутренние ссылки относительными

Теперь, когда ваш сайт работает и на HTTP и на HTTPS, вам нужно добиться его работы вне зависимости от протокола. Может возникнуть проблема смешанных протоколов – когда на странице, которую грузят через HTTPS, указаны ресурсы, доступные по HTTP. В этом случае браузер предупредит пользователя, что защита, предоставляемая HTTPS, перестала работать на 100%.

По умолчанию многие браузеры вообще не будут загружать смешанный контент. Если это будут скрипты или стили, страница перестанет работать. К слову, включать в страницу, загруженную по HTTP, контент, доступный через HTTPS, можно без проблем.

Проблема эта решается заменой полных линков на относительные. Вместо такого:

надо сделать такое:

Все линки должны быть относительными, и чем относительнее, тем лучше. По возможности надо убрать протокол (//example.com) или домен (/jquery.js).

Лучше делать это при помощи скриптов, и не забыть про контент, который может находиться в базах данных, скриптах, стилях, правилах редиректа, тегах link. Проверить сайт на наличие смешанного контента можно скриптом от Bram van Damme.

Естественно, в ссылках на другие сайты протоколы менять не нужно.

Если в вашем сайте используются скрипты и другие ресурсы от третьих лиц, например CDN, jquery.com, у вас есть 2 варианта:

— также использовать URL без указания протокола
— скопируйте эти ресурсы к себе на сервер. Это в любом случае надёжнее

4: Переадресация с HTTP на HTTPS

на ваших страницах. Это поможет поисковым системам лучше ориентироваться у вас.

Большинство веб-серверов предлагают простые решения для редиректа. Инструкции для Apache и для nginx. Используйте код 301 (Moved Permanently).

5: Включите Strict Transport Security и Secure Cookies

На этом шаге вы уже ограничиваете доступ к сайту только для HTTPS. Strict Transport Security сообщает клиентам, что им надо соединяться с сайтом только по HTTPS, даже если ссылка идёт на http:// . Это помогает против атак типа SSL Stripping и экономит время на переадресациях из четвёртого шага.

Убедитесь, что ваши TLS-настройки реально работают – например, сертификат не просрочен. На этом шаге любая ошибка будет блокировать доступ к сайту.

Включите HTTP Strict Transport Security посредством заголовка Strict-Transport-Security. На этой странице есть ссылки на инструкции для разных серверов.

Примечание: max-age измеряется в секундах. Начните с небольших величин и по мере роста уверенности в работе сайта увеличивайте их.

Для того, чтобы клиенты всегда отправляли куки по защищённому каналу, включите флаг Secure для куков. На этой странице есть инструкция для этого.

Проблемы с миграцией

Позиция в поисковой выдаче

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

Когда сервер работает нормально, траты на TLS обычно малы. По поводу их оптимизации читайте High Performance Browser Networking by Ilya Grigorik и Ivan Ristic’s OpenSSL Cookbook и Bulletproof SSL And TLS.

В некоторых случаях TLS может увеличить быстродействие – это справедливо в случае использования HTTP/2.

Клиентские программы не отправляют Referer, когда пользователи переходят по ссылкам с вашего HTTPS-сайта на другие HTTP-сайты. Если вам это не нравится:

— другие сайты тоже должны мигрировать на HTTPS. Предложите им эту инструкцию. Если они дойдут хотя бы до 2 шага, то ситуация выправится
— вы можете использовать новый стандарт Referrer Policy, решающий проблемы с этими заголовками

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

Клиент НЕ ДОЛЖЕН включать заголовок Referer в небезопасный HTTP-запрос, если ссылающаяся страница получена по безопасному протоколу.

Если на вашем сайте крутятся объявления рекламной сети, может возникнуть проблема –iframe с HTTP не будут работать на странице с HTTPS. Пока все рекламодатели не перейдут на HTTPS, операторы не могут перейти на HTTPS, не теряя рекламных доходов. Но пока операторы не мигрируют на HTTPS, у рекламодателей нет мотивации для миграции.

Рекламодатели должны хотя бы предлагать вариант своих сервисов с поддержкой HTTPS (достаточно дойти до 2 шага этой инструкции). Многие так и делают. Вам, возможно, придётся отложить 4-й шаг до тех пор, пока большинство из них не станут нормально поддерживать этот протокол.

Источник