Разное

С https на http: Редирект с HTTPS на HTTP | REG.RU

12.02.1970

Содержание

Чем отличается HTTP от HTTPS

Возможно, вы замечали, что одни ссылки начинаются с HTTP, а другие — с HTTPS. В этой статье я объясню, что означают эти буквы и чем они отличаются друг от друга.


Содержание

Любая веб-страница хранится на сервере — компьютере, который постоянно подключен к интернету. Когда вы переходите по ссылке или вводите доменное имя в адресной строке, браузер находит нужный сервер и скачивает у него содержимое страницы.

То же самое происходит и в обратном направлении. Вы вводите на сайте логин и пароль от своего аккаунта, нажимаете «Войти», и браузер отправляет эту информацию на сервер. Сервер проверяет детали и отправляет браузеру страницу с открытым аккаунтом.

Браузер и сервер обмениваются данными, когда вы включаете видео на Ютубе, переходите по ссылке в статье на Википедии, заходите на Фейсбук, открываете письмо в почте или вводите данные банковской карты, чтобы оплатить покупку в интернете. В разных направлениях постоянно передаются какие-то данные.

Что такое HTTP

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

HTTPS — это тот же протокол, но с надстройкой безопасности.

Выбрать SSL для сайта

В чём разница между HTTP и HTTPS

По HTTP информация передаётся в обычном виде, а по HTTPS — в зашифрованном. Шифровать данные нужно, чтобы хакеры не смогли ничего прочитать, если перехватят их.

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

Скорее всего, хакеров не интересуют ваши ответы на опрос. Но перехватить можно любую информацию. Например, ваши пароли или номер банковской карты.

Чтобы этого не произошло, HTTP-протокол решили усовершенствовать.

К существующей технологии добавили шифрование и получился HTTPS — безопасный протокол передачи данных.

Когда вы вводите что-то на сайте, который работает по HTTPS, перед отправкой данных на сервер браузер зашифровывает информацию. Чтобы расшифровать и прочитать её, нужен специальный ключ, который хранится только на сервере. Такое шифрование называется криптографическим. Если даже мошенник перехватит информацию, он не сможет её прочитать. На то чтобы подобрать ключ к шифру, уйдут годы непрерывного перебора.

Разница между HTTP и HTTPS при передаче данных:

HTTP передает незашифрованные данные

HTTPS шифрует данные и хакер не может их перехватить

Как подключить HTTPS на сайте

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

Когда владелец сайта устанавливает SSL-сертификат, в адресной строке браузера появляется значок замка и HTTP меняется на HTTPS. Это значит, что на сайте безопасно вводить личную информацию.

Отличие HTTP от HTTPS в адресной строке браузера

Выбрать SSL для сайта

как перевести сайт на HTTPS без потери позиций?

С тех пор, как Google объявил о своем решении использовать HTTPS-шифрование как важный фактор SEO ранжирования, спрос на SSL сертификаты для безопасного соединения значительно вырос. Многие веб-разработчики и владельцы веб-сайтов, тем не менее, все еще в замешательстве относительно вопроса, как же правильно перевести сайт на HTTPS, чтобы это не навредило уже имеющимся позициям сайта. В этой статье мы поможем вам разобраться, что нужно для перехода на HTTPS, как правильно подготовить сайт и настроить перенос с HTTP на HTTPS.

1. Приобрести SSL сертификат

Как известно, защищенное HTTPS-соединение активируется путем установки SSL сертификата на сервер. Приобрести его можно в нашем Интернет-магазине SSL сертификатов. Для заказа вам следует выбрать подходящий SSL сертификат (в их различиях поможет разобраться наша статья о видах SSL сертификатов), далее следует определиться со сроком действия сертификата и оформить заказ. В зависимости от типа SSL сертификата центр сертификации проведет проверку вашего домена и в некоторых случаях компании, после чего выдаст ваш SSL сертификат.

2. Переход c HTTP на HTTPS: подготовка сайта

Чтобы в дальнейшем избежать проблем с отображение содержимого сайта через протокол HTTPS, следует изменить все внутренние ссылки на относительные. Например, если ранее внутренние ссылки указывались в формате http://domain.ru/page1/ , то следует заменить их на /page1/. То же касается и использования внешних медиафайлов (изображения, видео-записи, презентации и т.д.) – они должны открываться по защищенному протоколу HTTPS. Если источник имеет HTTPS версию, вы можете просто заменить ссылки на соответствующий контент.

Если же нет, то мы рекомендуем загрузить медиафайлы на свой сервер и открывать их по защищенному протоколу. Это поможет в дальнейшем избежать ошибки со смешанным содержимым. Кроме того, все внешние скрипты, например, библиотеки javascript и jQuery, а также скрипты сервисов Яндекса (например, Метрика и Директ), а также Google (Analytics) и прочие, следует открывать через относительные URL-адреса.

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

3. Установить SSL сертификат

После прохождения проверки со стороны центра сертификации вы получите файлы вашего SSL сертификата. Вам следует установить их на сервер и сконфигурировать его. Вы можете сделать это либо самостоятельно, воспользовавшись нашими инструкциями по установке SSL, либо отправить файлы SSL сертификата вашему провайдеру хостинга – очень часто техническая поддержка хостинга производит установку SSL сертификатов вместо клиентов.
3.1. Проверить правильность установки SSL
Далее Вам следует проверить, правильно ли установлен ваш SSL сертификат. В этом может помочь, например, сервис от SSL Labs (https://www.ssllabs.com/ssltest/) , где вам следует вписать ваше доменное имя и нажать кнопку Submit. Система выдаст оценку настройки защищенного соединения с вашим сервером и подскажет, какие проблемы следует решить.
Пример проведенного теста на SSL Labs показан на картинке ниже:

Соответственно, если сервис нашел проблемы в конфигурации сервера или показал, что вы не установили промежуточные и корневые сертификаты, лучше как можно быстрее решить эти проблемы.

4. Настроить 301-й редирект с HTTP на HTTPS

Так как поисковые системы Google и Яндекс воспринимают сайты http://domen.ru и https://domen.ru как два абсолютно разных ресурса, после установки SSL сертификата обязательно нужно настроить переадресацию каждой HTTP-страницы на соответствующую ей HTTPS-страницу. Эта процедура соответствует переносу сайта на другой домен. Переадресация должна быть прямой и не включать промежуточных документов, иначе образуются цепочки редиректов, которые только запутают поисковых роботов и негативно повлияют на восприятие сайта в целом.

Как вариант, вы можете осуществить переадресацию с HTTP на HTTPS с помощью .htaccess, если ваш сайт размещен на сервере Apache или же, если на вашем сервере имеется соответствующая утилита. Кроме того, если ваш сайт создан на каком-либо языке программирования, настроить переадресацию можно прямо в коде сайта.

4.1. Настроить внутреннюю перелинковку сайта

Замените URL-адреса с HTTP на HTTPS во всех внутренних ссылках, изображениях, JavaScrip, CSS и прочих элементах. Все внутренние ссылки должны по умолчанию начинаться с HTTPS. Это поможет избежать проблемы смешанного содержимого. Тем не менее, этого шага можно избежать, если вы правильно подготовили сайт к переходу на HTTPS.

4.2. Проверьте работу внешних скриптов и изображений

Внимательно проверьте, все ли внешние скрипты и изображения правильно работают через HTTPS. Если вы обнаружили какие-либо проблемы, лучше загрузить такие файлы на сервер, чтобы они гарантированно загружались по протоколу HTTPS.

5. Сообщите поисковым системам о переходе на HTTPS

5.1. Убедитесь, что все теги “rel=canonical” в HTML-коде указывают на страницы с HTTPS.

5.2. Обновите файл с директивами для поискового робота robots.

txt и карту сайта sitemap.xml, включив в них соответствующие страницы с HTTPS.

5.3. Обновите URL-адрес вашего сайта в социальных сетях и в системах отслеживания трафика, таких как Google Analytics и Yandex Metrika.

5.4. Создайте новую запись для ресурса с HTTPS в Google Webmaster Tools. Помните, что сервис Google Webmaster Tools рассматривает версии сайта с HTTP и HTTPS как два разных ресурса.

5.5. По возможности обновите важные внешние ссылки на ваш веб-сайт, чтобы они вели на URL-адрес с HTTPS расширением.

5.6. Убедитесь, что поисковые системы могут индексировать и предоставлять содержимое вашего ресурса по новому URL-адресу.

5.7. Ежедневно отслеживайте сайт с HTTPS в Google Webmaster Tools и в Google Analytics, чтобы предупредить возможные проблемы с индексацией и отображением вашего сайта.

Помните, что переход с HTTP на HTTPS может вызвать колебания в объемах трафика и в позициях сайта, так как 301-й редирект передает от 90 до 99% веса ссылки. Потеря внешних ссылок, которые ранее вели на HTTP версию вашего ресурса, также может временно спровоцировать падение трафика и позиции. Тем не менее, многие примеры показывают, что позиции и трафик восстанавливаются уже через несколько месяцев после того, как перейти с HTTP на HTTPS.

HTTPS и HTTP — Что это такое? Чем отличается HTTP и HTTPS протокол сайта — Wiki HOSTiQ.ua

HTTP (от англ. HyperText Transfer Protocol — протокол передачи гипертекста) — это прикладной протокол передачи данных в сети. На текущий момент используется для получения информации с веб-сайтов. Протокол HTTP основан на использовании технологии «клиент-сервер»: клиент, отправляющий запрос, является инициатором соединения; сервер, получающий запрос, выполняет его и отправляет клиенту результат.

HTTPS (от англ. HyperText Transfer Protocol Secure — безопасный протокол передачи гипертекста) — это расширение протокола HTTP, поддерживающее шифрование посредством криптографических протоколов SSL и TLS.

Чем отличаются HTTP от HTTPS

  • HTTPS не является отдельным протоколом передачи данных, а представляет собой расширение протокола HTTP с надстройкой шифрования;
  • передаваемые по протоколу HTTP данные не защищены, HTTPS обеспечивает конфиденциальность информации путем ее шифрования;
  • HTTP использует порт 80, HTTPS — порт 443.

Использование HTTPS

Обеспечение безопасной передачи данных необходимо на сайтах, где вводится и передается конфиденциальная информация (личные данные пользователей, детали доступа, реквизиты платежных карт) — на любых сайтах с авторизацией, взаимодействием с платежными системами, почтовыми сервисами. Шифрование таких данных позволит предотвратить их получение и использование третьими лицами.

Для реализации передачи данных посредством HTTPS на веб-сервере, обрабатывающем запросы от клиентов, должен быть установлен специальный SSL-сертификат. Есть сертификаты, защищающие только один домен. А есть сертификаты, которые обеспечивают защиту информации на всех поддоменах, и это Wildcard SSL. Также, если вы решили купить VPS для серьезного бизнес-проекта, то, вероятно, вам понадобится TrueBusinessID with EV сертификат, обеспечивающий высший уровень безопасности вашего домена и добавляющий зеленую строку в окне браузера. Шифрование происходит в обе стороны — как данных, полученных клиентом, так и данных, отправленных на сервер.

Наличие SSL-сертификата является одним из факторов ранжирования Google, поэтому переход на протокол HTTPS повышает позиции в поисковой выдаче Google. Хотя на текущий момент этот фактор не имеет основополагающего значения, его влияние на поисковой результат может увеличиваться в будущем.

SSL-сертификаты для любых сайтов

У нас вы найдёте сертификаты от популярных провайдеров Comodo, GeoTrust, Thawte и VeriSign — для защиты одного или нескольких доменов, а также домена и всех его субдоменов.

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

Выбрать SSL

Читайте также:

Чем http отличается от https

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

Чем отличается HTTP и HTTPS

Рассмотрим детально, чем отличается протокол HTTPS от HTTP.

HTTP — аббревиатура английского словосочетания HyperText Transfer Protocol, в переводе означающего «протокол передачи гипертекста». В этом протоколе используется технология «клиент-сервер» — интернет-пользователь (клиент) отправляет запрос, становясь при этом инициатором соединения. Сервер получает и выполняет данный запрос, а затем отправляет в ответ результат. 

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

При открытии сайтов с HTTP-протоколом браузер Google Chrome отображает информацию о небезопасном подключении:

Данное сообщение о небезопасности может насторожить пользователей и заставить покинуть сайт с протоколом HTTP, поэтому для любых проектов предпочтительнее 

применять HTTPS.В аббревиатуре HTTPS добавляется буква «S» — Secure, обозначающая, что указанный протокол передачи гипертекста безопасный. В HTTPS используется шифрование с помощью криптографических протоколов — SSL и TLS. Фактически этот тот же протокол передачи данных, что и HTTP, но с добавлением надстройки шифрования. При открытии ресурсов с HTTPS в адресной строке Chrome отображается информация о безопасности подключения:

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

Проекты, на которых обязательно использование SSL-сертификата:

  1. Сайты с онлайн-платежами — интернет-магазины, ресурсы для бронирования билетов и отелей, перевода денег, пополнения счета и т.д.
  2. Почтовые сервисы.
  3. Любые сайты, на которых пользователи вводят или получают финансовую и конфиденциальную информацию.

Отличия HTTP и HTTPS

  1. В протоколах используются разные порты: в HTTP применяется порт 80, в HTTPS — 443.
  2. В HTTPS применяется шифрование данных, которые затем расшифровываются с помощью ключей на сервере.
  3. HTTPS обеспечивает сохранность данных. Если произойдет какое-то изменение передаваемых сведений, это будет зафиксировано.
  4. Безопасный протокол гарантирует аутентификацию — попадание пользователей именно на тот ресурс, который необходим, это обеспечивает борьбу с мошенническими вмешательствами.
  5. Специалисты Google рекомендуют использовать на любых сайтах HTTPS, это положительно влияет на позиции проекта в поисковой выдаче. (.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

    Альтернативный вариант — установить переадресацию в настройках хостинг-провайдера:

    1. Для поисковиков сайт, который ранее использовал протокол HTTP, а затем перешел на HTTPS — это уже другой ресурс. Если неправильно осуществить переход на безопасный протокол, то позиции сайта временно понизятся. Чтобы проинформировать поисковые системы об изменении протокола, внесите соответствующие настройки.

    Добавьте в Яндекс.Вебмастер и Search Console название домена с HTTPS и укажите, что это основная версия сайта. Нажмите «Добавить ресурс»:

    Пропишите адрес:

    1. Специалисты Google рекомендуют для сайтов с безопасным протоколом также использовать дополнительно технологию HSTS.
    2. Укажите в файле robots.txt в директиве HOST адрес сайта с HTTPS.

    Распространенные проблемы при использовании HTTPS

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

    Период действия сертификата:

    1. Невозможность просканировать или проиндексировать сайт. Проверьте, нет ли метатега noindex. Также запрет индексации сайта может быть прописан в файле robots.txt с помощью команды Disallow.
    2. Смешанное содержимое. На проекте с HTTPS должны отсутствовать страницы, доступные по стандартному протоколу HTTP, даже простые картинки. Наличие HTTP-контента делает сайт уязвимым.
    • Некорректное указание названия ресурса в сертификате. При получении сертификата должны учитываться все варианты написания домена, как с префиксом «www», так и без него.
    • Различное содержание на страницах с безопасным и обычным протоколом. Контент сайта с протоколом HTTPS должен полностью совпадать с содержимым соответствующих HTTP-страниц.
    • Устаревшая версия протокола. Необходимо использовать новые версии протокола TLS, обеспечивающие надежную защиту данных.

    Запомнить

    1. Резюмируем, чем отличается протокол HTTPS от HTTP — криптошифрованием, обеспечивающим безопасность ресурса.
    2. Специалисты Google рекомендуют использовать протокол HTTPS независимо от вида контента, представленного на проекте.
    3. Настройка переадресации с HTTP на HTTPS доступна в панели управления хостинг-провайдера либо в файле .htaccess. 

    Настройка HTTPS-серверов

    Настройка HTTPS-серверов

    Чтобы настроить HTTPS-сервер, необходимо включить параметр ssl на слушающих сокетах в блоке server, а также указать местоположение файлов с сертификатом сервера и секретным ключом:

    server {
        listen              443 ssl;
        server_name         www.example.com;
        ssl_certificate     www.example.com.crt;
        ssl_certificate_key www.example. com.key;
        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers         HIGH:!aNULL:!MD5;
        ...
    }
    

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

        ssl_certificate     www.example.com.cert;
        ssl_certificate_key www.example.com.cert;
    

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

    С помощью директив ssl_protocols и ssl_ciphers можно ограничить соединения использованием только “сильных” версий и шифров SSL/TLS. По умолчанию nginx использует “ssl_protocols TLSv1 TLSv1.1 TLSv1.2” и “ssl_ciphers HIGH:!aNULL:!MD5”, поэтому их явная настройка в общем случае не требуется. Следует отметить, что значения по умолчанию этих директив несколько раз менялись.

    Оптимизация HTTPS-сервера

    SSL-операции потребляют дополнительные ресурсы процессора. На мультипроцессорных системах следует запускать несколько рабочих процессов, не меньше числа доступных процессорных ядер. Наиболее ресурсоёмкой для процессора является операция SSL handshake, в рамках которой формируются криптографические параметры сессии. Существует два способа уменьшения числа этих операций, производимых для каждого клиента: использование постоянных (keepalive) соединений, позволяющих в рамках одного соединения обрабатывать сразу несколько запросов, и повторное использование параметров SSL-сессии для предотвращения необходимости выполнения SSL handshake для параллельных и последующих соединений. Сессии хранятся в кэше SSL-сессий, разделяемом между рабочими процессами и настраиваемом директивой ssl_session_cache. В 1 мегабайт кэша помещается около 4000 сессий. Таймаут кэша по умолчанию равен 5 минутам. Он может быть увеличен с помощью директивы ssl_session_timeout. Вот пример конфигурации, оптимизированной под многоядерную систему с 10-мегабайтным разделяемым кэшем сессий:

    worker_processes auto;
    
    http {
        ssl_session_cache   shared:SSL:10m;
        ssl_session_timeout 10m;
    
        server {
            listen              443 ssl;
            server_name         www.example.com;
            keepalive_timeout   70;
    
            ssl_certificate     www.example.com.crt;
            ssl_certificate_key www.example.com.key;
            ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
            ssl_ciphers         HIGH:!aNULL:!MD5;
            ...
    
    Цепочки SSL-сертификатов

    Некоторые браузеры могут выдавать предупреждение о сертификате, подписанном общеизвестным центром сертификации, в то время как другие браузеры без проблем принимают этот же сертификат. Так происходит потому, что центр, выдавший сертификат, подписал его промежуточным сертификатом, которого нет в базе данных сертификатов общеизвестных доверенных центров сертификации, распространяемой вместе с браузером. В подобном случае центр сертификации предоставляет “связку” сертификатов, которую следует присоединить к сертификату сервера. Сертификат сервера следует разместить перед связкой сертификатов в скомбинированном файле:

    $ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
    

    Полученный файл следует указать в директиве ssl_certificate:

    server {
        listen              443 ssl;
        server_name         www.example.com;
        ssl_certificate     www.example.com.chained.crt;
        ssl_certificate_key www.example.com.key;
        ...
    }
    

    Если сертификат сервера и связка сертификатов были соединены в неправильном порядке, nginx откажется запускаться и выдаст сообщение об ошибке:

    SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
       (SSL: error:0B080074:x509 certificate routines:
        X509_check_private_key:key values mismatch)
    

    поскольку nginx попытается использовать секретный ключ с первым сертификатом из связки вместо сертификата сервера.

    Браузеры обычно сохраняют полученные промежуточные сертификаты, подписанные доверенными центрами сертификации, поэтому активно используемые браузеры уже могут иметь требуемые промежуточные сертификаты и не выдать предупреждение о сертификате, присланном без связанной с ним цепочки сертификатов. Убедиться в том, что сервер присылает полную цепочку сертификатов, можно при помощи утилиты командной строки openssl, например:

    $ openssl s_client -connect www.godaddy.com:443
    ...
    Certificate chain
     0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
         /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
         /OU=MIS Department/CN=www.GoDaddy.com
         /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
       i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
         /OU=http://certificates.godaddy.com/repository
         /CN=Go Daddy Secure Certification Authority
         /serialNumber=07969287
     1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. 
         /OU=http://certificates.godaddy.com/repository
         /CN=Go Daddy Secure Certification Authority
         /serialNumber=07969287
       i:/C=US/O=The Go Daddy Group, Inc.
         /OU=Go Daddy Class 2 Certification Authority
     2 s:/C=US/O=The Go Daddy Group, Inc.
         /OU=Go Daddy Class 2 Certification Authority
       i:/L=ValiCert Validation Network/O=ValiCert, Inc.
         /OU=ValiCert Class 2 Policy Validation Authority
         /CN=http://www.valicert.com//[email protected]
    ...
    
    При тестировании конфигураций с SNI необходимо указывать опцию -servername, так как openssl по умолчанию не использует SNI.

    В этом примере субъект (“s”) сертификата №0 сервера www.GoDaddy.com подписан издателем (“i”), который в свою очередь является субъектом сертификата №1, подписанного издателем, который в свою очередь является субъектом сертификата №2, подписанного общеизвестным издателем ValiCert, Inc. , чей сертификат хранится во встроенной в браузеры базе данных сертификатов (которая в тёмном чулане хранится в доме, который построил Джек).

    Если связку сертификатов не добавили, будет показан только сертификат сервера №0.

    Единый HTTP/HTTPS сервер

    Можно настроить единый сервер, который обслуживает как HTTP-, так и HTTPS-запросы:

    server {
        listen              80;
        listen              443 ssl;
        server_name         www.example.com;
        ssl_certificate     www.example.com.crt;
        ssl_certificate_key www.example.com.key;
        ...
    }
    
    До версии 0.7.14 SSL нельзя было включить выборочно для отдельных слущающих сокетов, как показано выше. SSL можно было включить только для всего сервера целиком, с помощью директивы ssl, что не позволяло настроить единый HTTP/HTTPS сервер. Для решения этой задачи был добавлен параметр ssl директивы listen. Поэтому использование директивы ssl в современных версиях не рекомендуется.
    Выбор HTTPS-сервера по имени

    Типичная проблема возникает при настройке двух и более серверов HTTPS, слушающих на одном и том же IP-адресе:

    server {
        listen          443 ssl;
        server_name     www.example.com;
        ssl_certificate www.example.com.crt;
        ...
    }
    
    server {
        listen          443 ssl;
        server_name     www.example.org;
        ssl_certificate www.example.org.crt;
        ...
    }
    

    В такой конфигурации браузер получит сертификат сервера по умолчанию, т.е. www.example.com, независимо от запрашиваемого имени сервера. Это связано с поведением протокола SSL. SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос, и nginx не знает имени запрашиваемого сервера. Следовательно, он лишь может предложить сертификат сервера по умолчанию.

    Наиболее старым и надёжным способом решения этой проблемы является назначение каждому HTTPS-серверу своего IP-адреса:

    server {
        listen          192. 168.1.1:443 ssl;
        server_name     www.example.com;
        ssl_certificate www.example.com.crt;
        ...
    }
    
    server {
        listen          192.168.1.2:443 ssl;
        server_name     www.example.org;
        ssl_certificate www.example.org.crt;
        ...
    }
    
    SSL-сертификат с несколькими именами

    Существуют и другие способы, которые позволяют использовать один и тот же IP-адрес сразу для нескольких HTTPS-серверов. Все они, однако, имеют свои недостатки. Одним из таких способов является использование сертификата с несколькими именами в поле SubjectAltName сертификата, например www.example.com и www.example.org. Однако, длина поля SubjectAltName ограничена.

    Другим способом является использование wildcard-сертификата, например *.example.org. Такой сертификат защищает все поддомены указанного домена, но только на заданном уровне. Под такой сертификат подходит www.example.org, но не подходят example.org и www. sub.example.org. Два вышеуказанных способа можно комбинировать. Сертификат может одновременно содержать и точное, и wildcard имена в поле SubjectAltName, например example.org и *.example.org.

    Лучше поместить сведения о файле сертификата с несколькими именами и файле с его секретным ключом на уровне конфигурации http, чтобы все серверы унаследовали их единственную копию в памяти:

    ssl_certificate     common.crt;
    ssl_certificate_key common.key;
    
    server {
        listen          443 ssl;
        server_name     www.example.com;
        ...
    }
    
    server {
        listen          443 ssl;
        server_name     www.example.org;
        ...
    }
    
    Указание имени сервера

    Более общее решение для работы нескольких HTTPS-серверов на одном IP-адресе — расширение Server Name Indication протокола TLS (SNI, RFC 6066), которое позволяет браузеру передать запрашиваемое имя сервера во время SSL handshake, а значит сервер будет знать, какой сертификат ему следует использовать для соединения. Сейчас SNI поддерживается большинством современных браузеров, однако может не использоваться некоторыми старыми или специализированными клиентами.

    В SNI можно передавать только доменные имена, однако некоторые браузеры могут ошибочно передавать IP-адрес сервера в качестве его имени, если в запросе указан IP-адрес. Полагаться на это не следует.

    Чтобы использовать SNI в nginx, соответствующая поддержка должна присутствовать как в библиотеке OpenSSL, использованной при сборке бинарного файла nginx, так и в библиотеке, подгружаемой в момент работы. OpenSSL поддерживает SNI начиная с версии 0.9.8f, если она была собрана с опцией конфигурации “—enable-tlsext”. Начиная с OpenSSL 0.9.8j эта опция включена по умолчанию. Если nginx был собран с поддержкой SNI, то при запуске nginx с ключом “-V” об этом сообщается:

    $ nginx -V
    ...
    TLS SNI support enabled
    ...
    

    Однако если nginx, собранный с поддержкой SNI, в процессе работы подгружает библиотеку OpenSSL, в которой нет поддержки SNI, nginx выдаёт предупреждение:

    nginx was built with SNI support, however, now it is linked
    dynamically to an OpenSSL library which has no tlsext support,
    therefore SNI is not available
    
    Совместимость
    • Статус поддержки SNI отображается по ключу “-V” начиная с версий 0. 8.21 и 0.7.62.
    • Параметр ssl директивы listen поддерживается начиная с версии 0.7.14. До версии 0.8.21 его можно было указывать только совместно с параметром default.
    • SNI поддерживается начиная с версии 0.5.23.
    • Разделяемый кэш SSL-сессий поддерживается начиная с версии 0.5.6.
    • Версия 1.9.1 и более поздние: протоколами SSL по умолчанию являются TLSv1, TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).
    • Версия 0.7.65, 0.8.19 и более поздние: протоколами SSL по умолчанию являются SSLv3, TLSv1, TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).
    • Версия 0.7.64, 0.8.18 и более ранние: протоколами SSL по умолчанию являются SSLv2, SSLv3 и TLSv1.
    • Версия 1.0.5 и более поздние: шифрами SSL по умолчанию являются “HIGH:!aNULL:!MD5”.
    • Версия 0.7.65, 0.8.20 и более поздние: шифрами SSL по умолчанию являются “HIGH:!ADH:!MD5”.
    • Версия 0.8.19: шифрами SSL по умолчанию являются “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM”.
    • Версия 0.7.64, 0.8.18 и более ранние: шифрами SSL по умолчанию являются
      ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP”.
    автор: Игорь Сысоев
    редактор: Brian Mercer

    Ошибочный редирект с https на http://$host:443

    Ошибка неверного порта при отдельных переходах по страницам характерна не только для Виртуальной Машины, а и многих самостоятельных конфигураций с Nginx. Однако, данная ошибка присутствует во всех VM Bitrix на протяжении последних лет.

    Как проявляется баг?

    Самыми частыми симптомами появления проблемы являются появившиеся ошибки в отчетах поисковых краулеров Google и Яндекс. В один прекрасный день после перехода на https протокол в отчетах начинают попадаться ошибочные страницы с urlhttp://host. com:443/page или наоборот https://host.com:80/page

    Простым взглядом на строки легко понять, что проблема кроется в том, что страница «находящаяся» на https пытается быть открытой по протоколу http или в «иную сторону».

    Зачастую найти точки входа ботов на ошибочные страницы довольно сложно. Это могут быть результаты поиска, переход после авторизации, результаты форм и что угодно еще. Радует то, что по-большому счету искать причину и не нужно. Главное устранить эти «нелогичные» редиректы на уровне сервера.

    Отдельным случаем проявления данной проблемы является открытие страницы с <i>ошибкой 400</i>. На данной странице красуется сообщение: The plain HTTP request was sent to HTTPS port

    Правим конфиги «Виртуалки»

    /etc/httpd/bx/conf/bx_ext_fgstockstudio.com.conf

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

    /etc/httpd/bx/conf/default. conf
    

    и над ServerAdmin [email protected] вставляем

    ServerName  https://YOUR_SITE
    

    При многосайтовой конфигурация виртуалки делаем тоже самое, но в файле нужного сайта bx_ext_YOUR_SITE.conf

    Альтернативный способ

    Иногда описанного выше недостаточно. Приходится идти глубже и править директивы связанные с страницами ошибок. Ищем файл отвечающий за конфиг nginx нашего ssl домена

    /etc/nginx/bx/site_avaliable/ssl.s1.conf
    

    Добавляем error_page 497 https://$host$request_uri;. Получим нечто похожее на:

    # Default SSL certificate enabled website
    	server {
    		listen	443 default_server http2;
    		server_name _;
    
    		# Enable SSL connection
    		server_name_in_redirect	off;
    
                    proxy_set_header	Host	$host;
    		proxy_set_header	X-Real-IP	$remote_addr;
    		proxy_set_header	X-Forwarded-For	$proxy_add_x_forwarded_for;
    		proxy_set_header	Host		$host:443;
    		proxy_set_header	HTTPS	YES;
    
    		set $proxyserver	"http://127. 0.0.1:8888";
    		set $docroot		"/home/bitrix/www";
    
    		index index.php;
    		root /home/bitrix/www;
    
    		include bx/conf/bitrix.conf;
    
    		# Include server monitoring API's
    		include bx/server_monitor.conf;
    
                    error_page 497 https://$host$request_uri; 
    	}
    

    Проблема должна исчезнуть. Если вам известны иные методы напишите нам в комментариях.

    Решение наверняка 🙂

    Если не помогло все вышеописанное и ошибка остается — то причина в файле настроек nginx :

    /etc/nginx/bx/site_avaliable/bx_ext_s1.conf
    

    Нужен именно файл обычного протокола http (bx_ext_), а не https (bx_ext_ssl)

    Добавляем return 301 https:/YourDomain.com$request_uri;. Получим нечто похожее на:

    # Ansible managed
    # Additional website http
    server {
    		listen 80 ;
    		server_name YourDomain.com www.YourDomain.com;
    		return 301 https://YourDomain. com$request_uri;
    ... 
    ...
    		error_page 497 https://$host$request_uri;
    }
    

    В 2020 году кроме коронавируса появилось еще что-то новое … и иногда нужно колдовать совсем не с nginx, а с http. Альтернативное решение описали тут.

    		
    	

    Как перевести сайт на https самостоятельно: подробная инструкция

    Если ваш сайт до сих пор работает на HTTP, «Пингвин» идет к вам! Ладно-ладно. Вы можете справиться своими силами. Для этого мы подготовили обширную инструкцию (даже скриншоты прикрепили), как перевести сайт на https самостоятельно.   

    Зачем переходить на https?

    Впервые о переносе сайтов с http на https заговорили в, казалось бы, уже далеком 2014-ом году, когда Google заявил, что безопасность пользователей — главный приоритет компании. Тогда поисковик пообещал всем, кто начнет использовать защищенный протокол, бонусы при ранжировании. Но вознаграждение пришло не сразу. Рост https-ресурсов в топе выдачи по поисковым запросом начался в конце 2016-ого, когда на первой странице в Google доля сайтов, которые используют шифрование, достигла 40%. В то время, как еще в начале года эта цифра была равна 25 процентам.

    В 2017-ом рост продолжился. Сейчас, согласно статистике MozCast на 9 января 2018 г., доля сайтов с https среди топ-10 выдачи составляет рекордные 75,4%. Только за последний месяц эта цифра увеличилась на 2 процента.

    Кроме того, браузер Google Chrome теперь помечает http-ресурсы как небезопасные. Если сейчас отметка «Не защищено» отмечена серым цветом, то поисковик обещает сделать ее более заметной в ближайшее время.

    Google Chrome сейчас, согласно статистике w3counter, — самый популярный браузер в мире. Им пользуется 58,8% юзеров. В рунете он также занимает лидирующую позицию — его используют 51,11%.

    А что Яндекс?

    Официально Яндекс заявляет, что сайты с http и https участвуют в индексации на равных условиях. То есть наличие SSL-сертификата не является самостоятельным фактором ранжирования и никаких бонусов не предоставляет.

    Тем не менее, судя по статистике, доля сайтов с https в ТОП-10 выдачи с 1 января 2017 года выросла более чем на 13%.

    Каким поисковиком пользуются белорусы? Согласно статистике Liveinternet.ru, 63,4% пользуются Google и только 31,4% все еще отдают предпочтение поисковику от Яндекс.

    Время переводить свой сайт на защищенное соединение наступило!

    Алгоритм самостоятельного перехода на протокол HTTPS

    Если сейчас покупка SSL-сертификата обязательна,  в первую очередь, для ресурсов, которые хранят пользовательские данные, (если, конечно, они не хотят потерять клиентов), то в перспективе перейти на безопасное шифрование придется всем сайтам. Перенести сайт с http на https можно самостоятельно. Главное, учесть нюансы и делать все последовательно.

    Важно понимать, что процедура переноса зависит от архитектуры/CMS, поэтому этот процесс может отличаться в каждом конкретном случае. Мы постарались написать для вас наиболее типовой универсальный алгоритм. Но не забывайте учитывать особенности реализации именно вашего сайта. Так, например, в ряде систем есть расширения/функции, которые значительно упрощают переход на защищенное соединение. Дальше представляем наш алгоритм. Удачи!

    1. Выбор и приобретение SSL-сертификата

    Чтобы сэкономить время на ожидании сертификата, рекомендуем выбрать и купить его сразу, а потом переходить к подготовке сайта.

    Не советуем использовать бесплатные сертификаты. Это небезопасно, так как браузер даже после его установки может выдать ошибку о том, что сайт не проверен. Но решать вам: сейчас можно найти множество различных предложений, в том числе и бесплатных. Иногда хостинг-провайдеры предлагают SSL-сертификаты в подарок за покупку хостинга и домена.

    По функциональности сертификаты разделяют на:

    Подходят как для физических, так и для юридических лиц. Самый бюджетный вариант.

    Его приобретают, если у ресурса есть поддомены.

    Этот сертификат можно использовать для нескольких доменов.

    Необходим для кириллических доменов.

    По степени защиты сертификаты делятся на:

    Самый распространенный тип. Он выдается только на один домен. Самый бюджетный вариант.

    Этот тип подтверждает не только домен, но и организацию. При его покупке у вас могут запросить свидетельство о государственной регистрации.

    Это сертификат, выдачу которого осуществят лишь после проверки адреса, свидетельства о регистрации, торговой марки. Покупка сертификата статуса «Extended Validation» позволяет получить зеленую строчку в браузерной строке.

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

    Вы можете прочитать подробную инструкцию по покупке SSL-сертификата от Hoster.by.

    2. Подготовка сайта

    Чтобы избежать возникновения ошибки смешанного содержания «Mixed Content» после смены протокола, мы рекомендуем проверить все ссылки на вашем ресурсе.

    Для проверки можно воспользоваться инструментом браузера «Инспектор кода» (вкладка »Безопасность»).

    Должно быть так:

    Не должно быть так:

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

    Например, вместо такого http://penguin.by/styles/main.css в текстах должно быть или такое /styles/main.css, или такое  //penguin.by/styles/main.css.

    SEO-специалисты рекомендуют использовать третий тип ссылок (но основной критерий здесь, все же, сохранение работоспособности кода).

    Где и как менять ссылки?

    На этот вопрос нет универсального ответа. В каждом конкретном случае нужно действовать по-разному. Часть ссылок будут прописаны в исходных кодах вашего сайта (php, html и прочих файлах). Чтобы поменять такие ссылки, вам нужно будет найти все файлы, в которых есть проблема, скачать их с сервера, внести изменения и загрузить обратно через ФТП-соединение. Часть ссылок будут находиться в контенте (например, в тексте статьи на сайте) — такие ссылки можно менять вручную через админку. Обратите внимание, что на этом шаге идет речь только о ссылках типа <a href=”..”>..</a> внутри вашего сайта. Если вы замените ссылку на чужой сайт, указав протокол https, а чужой сайт еще не перешел на безопасное соединение, ваши посетители при переходе по данной ссылке обнаружат ошибку.

    Иногда внутренних ссылок на сайте очень много и заменить их вручную через админку не представляется возможным. В этом случае вы можете сделать эту операцию автоматически через базу данных одним махом. О том, как заменить ссылки на сайте для перехода на https с помощью phpMyAdmin, читайте в отдельной инструкции.

    3. Подключение сертификата

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

    Крупнейшие хостинг-провайдеры предоставляют к выдаваемому сертификату инструкцию по их установке. Также мануал можно найти на официальных сайтах. На свой сайт мы установили сертификат, который купили у hoster.by. Вот инструкция по его установке.

    После вам нужно проконтролировать правильность установки. Корректность проверяется следующим образом:

    • Зайдите на свой сайт по двум протоколам — http и https. И в том, и в другом случае он должен быть доступен;

    • Проведите анализ с помощью специального сервиса. Например, ssllabs.com.

    Если все настроено правильно, то результат будет выглядеть так:

    Это значит, что все страницы сайта автоматически станут доступны по двум url-адресам.

    4. Сообщение поисковикам о переносе сайта

    И Google, и Яндекс воспринимают ресурсы с разными протоколами как разные сайты. Поэтому при установке протокола, как и при переезде ресурса на новый домен, позиции сайта в выдаче поисковика и посещаемость может снизиться. Чтобы минимизировать риски, необходимо правильно настроить сайт после переноса своего сайта на безопасный протокол. Для этого необходимо учитывать рекомендации от Яндекс и Google.

    Шаг 1. Сообщение поисковым роботам

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

    Также добавьте сайт с указанием протокола https в Google Search Console.

    Яндекс и Google просят подтвердить право собственности на сайт любым удобным способом.

    Шаг 2. Выберите адрес главного зеркала в Яндекс.Вебмастере

    Далее укажите адрес главного зеркала вашего сайта. Сделать это можно, внеся изменения в файле robots.txt. О том, как добавить директиву Host, читайте в справочной информации поисковика.

    Шаг 3. Сообщите роботу об изменении главного зеркала

    Сообщите Яндекс-роботу, что у вас изменилось главное зеркало сайта. Для этого зайдите в вебмастер на страницу «Настройки индексирования» и выберите «Переезд сайта».

    Шаг 4. Обновите Sitemap в Search Console

    Не забудьте обновить XML-карту. Ее можно загрузить в подразделе «Файлы Sitemap» раздела «Сканирование» Search Console.

    Шаг 5. Ожидание

     Сейчас у вас есть два вариант развития событий:

    • Ждать, пока поисковик определит https-версию главным зеркалом вашего ресурса. Это может занять от трех дней до целого месяца. Зато, выбрав этот вариант, меньше рисков, что сайт снизит позиции в выдаче.

    • Принять риски и приступить к следующему шагу.

    Шаг 6. Настройка 301 редиректа

    Будем считать, что вы дождались, когда хотя бы 90% страниц вашего ресурса уже проиндексировались (или приняли возможные риски, тут уж вам решать). Теперь можно приступить к следующему, последнему шагу — настройке 301 редиректа с неглавного зеркала.

    Эта процедура проходит по-разному в зависимости от установленной системы управления содержимым (CMS).(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

    Шаг 7 (заключительный). Проверить, как работает сайт

    На этом этапе необходимо посмотреть, как работают настройки сайта, которые вы делали еще до установки сертификата.

     

    Как видите, https перевод — не такое уж простое дело. Но, если вы отважны и полны веры в себя, у вас все обязательно получится! Будьте внимательны, чтобы не допустить ошибок. Ведь их исправление может оказаться дороже, чем оплата услуги по переводу сайта на https.

     

    Как изменить свой сайт с HTTPS на HTTP

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

    Предупреждение: поисковые системы теперь размещают предупреждения на сайтах, которые не используют https .

    Как изменить свой сайт с HTTPS на HTTP на хостинге, отличном от WP

    Общий

    VPS

    Выделенный

    1. Вход в ACC
    2. Щелкните Домены на левой боковой панели
    3. Щелкните Управление доменными именами в раскрывающемся списке
    4. Щелкните имя домена, который вы хотите изменить на HTTP
    5. Найдите Изменить параметр отображения сайта без SSL и щелкните ее
    6. Рядом с При доступе к [URL-адрес домена] щелкните поле и выберите Отображать сайт в обычном режиме
    7. Нажмите кнопку Обновить кнопку

    Ваш сайт теперь будет обслуживаться через HTTP вместо HTTPS .Если вы хотите изменить значение по умолчанию в любое время, вы можете повторить эти шаги, но выберите Redirect to https://domain.com .

    Как изменить свой сайт с HTTPS на HTTP на хостинге WP

    WP Enthusiast

    WP Professional

    WP Professional Plus

    1. Вход в ACC
    2. Нажмите WordPress на левой боковой панели
    3. Щелкните Управление доменами в раскрывающемся списке
    4. Щелкните URL-адрес своего домена в столбце Домен
    5. Прокрутите вниз до раздела Параметр отображения сайта без SSL раздел
    6. Рядом с При доступе к домену http: //.com: щелкните поле и выберите Отображать сайт в обычном режиме
    7. Щелкните Обновить прямо под полем параметров отображения

    Ваш сайт теперь будет обслуживаться через HTTP вместо HTTPS . Если вы хотите изменить значение по умолчанию в любое время, вы можете повторить эти шаги, но выберите Redirect to https://domain.com .

    Как вернуться с HTTPS на HTTP-сайт без SSL

    2017 год был годом, когда веб-мастера, наконец, совершили миграцию с небезопасного HTTP-сайта на безопасный HTTPS-сайт.Основным стимулом было постоянное стремление Google к обеспечению безопасности, а также все массовые и крупномасштабные взломы, которые происходили в течение года. Конечно, SSL был фактором ранжирования поиска с 2014 года, хотя и второстепенным.

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

    Причины, по которым вы можете захотеть отменить изменение

    Существует множество различных причин, по которым вы можете захотеть отменить переход с HTTP на HTTPS. Давайте поговорим о них немного. Бьюсь об заклад, по крайней мере, некоторые из вас бросают вызов или, по крайней мере, принимают поспешное решение.

    # 1: Мой рейтинг упал! Это, безусловно, вызывает беспокойство, особенно когда единственная причина, по которой вы вносите изменение, в первую очередь, заключается в том, что Google утверждает, что это фактор ранжирования. Таким образом, ваш рейтинг должен повыситься, не так ли?

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

    Теперь, как правило, вы видите небольшое снижение рейтинга в течение нескольких дней или недель после перехода на SSL, после чего Google распознает изменение, которое было раньше, и стабилизируется. Как правило, вы стабилизируетесь на том же уровне или выше, на котором вы были раньше.Единственная возможная причина более продолжительной проблемы — неправильная конфигурация. Если у вас есть версии страницы как HTTP, так и HTTPS, это может вызвать проблемы с дублированием контента. Если ваш SSL сломан и предупреждает пользователей о небезопасной странице, вы можете быть оштрафованы.

    # 2: Я не заметил никаких улучшений в рейтинге. Против этого действительно сложно спорить. Дело в том, что некоторые сайты просто не увидят разницы в переходе на SSL.

    Если вы думаете, что все факторы ранжирования в поиске имеют значение в баллах, я могу привести вам аналогию.Представьте на мгновение, что наличие хороших метаописаний — это модификатор +20 очков. Наполнение ключевых слов — модификатор -20 пунктов. Дублированный контент поражает вас на -100, пока вы его не исправите. Регулярно публикуемый высококачественный контент добавляет +5 за каждую новую публикацию. Вы уловили идею.

    В этом сценарии переключение всего сайта на SSL даст вам что-то вроде бонуса +1 балл по всем направлениям. Это бонус! Это заставляет ваше число расти! Но если разница между вашим сайтом и сайтом над вами в рейтинге поиска составляет 50 баллов, переход на SSL не имеет значения.

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

    Может быть неприятно терпеть танец Google и временно заниженные рейтинги только для того, чтобы обнаружить, что вы снова вернулись туда, где вы были.Кажется, много усилий напрасно.

    Согласен с вами, правда. Дело в том, действительно ли лучше удалить SSL и повторить все это снова или просто оставить? Google обещает, что со временем SSL будет становиться все более и более важным. Мы уже видели, как важность безопасности возрастает за последние несколько лет. Просто разумнее предпринять небольшое повышение в SEO сейчас, с обещанием большего повышения позже, чем упускать шанс на это повышение из-за проделанной работы.

    № 3: У меня проблемы с внедрением межсайтового контента. Это, пожалуй, одна из немногих действительно законных проблем с SSL, с которыми я столкнулся. Полный сайт на SSL подойдет, если вы пытаетесь встроить контент в окно iframe, Flash или из небезопасной сети CDN. Встраивание небезопасного носителя вызовет ошибку, и пользователь никогда ее не увидит.

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

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

    Другой вариант — использовать плагин для решения большинства проблем за вас. Что-то вроде SSL Insecure Content Fixer исправит большинство ваших источников данных и поможет устранить остальные.

    # 4: SSL для моего сайта стоит дорого и мало ценится. Эта проблема — еще одна проблема, в которой может помочь терпение. Да, SSL стоит дорого, но это не всегда так. Если ваш вопрос касается стоимости этих расходов, вы должны учитывать доверие, которое оказывают вам и пользователи, и Google.Вы должны учитывать совершенные покупки, которые в противном случае не были бы совершены, репутацию, которую вы приобретаете, и растущую ценность SSL для SEO в ближайшие годы. Я не удивлюсь, если в следующие пять лет значение SSL станет все более важным.

    Перед тем, как начать

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

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

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

    В-третьих, если вам больше не нужен сертификат SSL, убедитесь, что вы действительно отменили сертификат. Нет смысла платить, если ты им не пользуешься, правда?

    Простой вариант

    Если у вас есть сайт WordPress, у вас есть простой вариант для отказа от сайта SSL.Этот простой способ — плагин Force Non-SSL.

    Чтобы использовать этот плагин, вам сначала нужно подготовить свой сайт. Просмотрите существующие плагины и убедитесь, что если какой-либо из них сам реализует или требует SSL, вы отключите и удалите их. Убедитесь, что это ничего не сломает на вашем сайте, хотя вы, вероятно, сразу увидите много ошибок безопасности. Затем удалите любой код, который вы вручную добавили в файл .htaccess. Обычно здесь вы помещаете инструкции сервера для ссылки на SSL и перенаправления всего сайта, поэтому удалите их, если у вас есть добавленный код.

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

    Те из вас, кто какое-то время следил за этим сайтом, знают, что я не рекомендую плагины, которые не обновлялись более года, не говоря уже о более чем четырехлетнем, как этот.Я могу рекомендовать это по двум причинам. Прежде всего, использование старых плагинов позволяет открыть дыры в безопасности на вашем сайте. Любой, кто заботится о безопасности, должен стремиться поддерживать свои плагины в актуальном состоянии. Однако с помощью этого плагина вы явно снимаете защиту. Все дело в том, чтобы открыть брешь в безопасности, так почему бы не пойти ва-банк? Я не говорю, что этот плагин сделает ваш сайт менее безопасным, чем простое удаление SSL вручную, но безопасность не является вашей главной заботой, если вы ищете такого рода инструкции.

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

    The Manual Way

    Если вы не используете WordPress или не хотите использовать этот плагин для выполнения работы за вас, вам придется действовать вручную.

    Прежде всего, как указано выше, поищите на своем сайте любые плагины или активные скрипты, которые заставляют URL-адрес HTTPS быть загруженным URL-адресом. Удалите эти плагины и скрипты.

    Затем найдите файл .htaccess и удалите весь код, относящийся к принудительному использованию SSL-URL-адресов в качестве действительных URL-адресов. Обычно вам нужно добавить запись для реализации SSL; в идеале вы можете просто сослаться на документацию по сертификату, чтобы узнать, что это было, и отключить его, если вы его не помните. В некоторых случаях вы можете просто очистить или удалить свой.htaccess и попросите сервер переделать его, но для некоторых сайтов это рискованно. Никогда не удаляйте файл напрямую; сначала сохраните локальную копию на случай, если при удалении ваш сайт сломается.

    Далее вам нужно будет реализовать код для перенаправления с HTTPS на HTTP. Тот факт, что вы удаляете SSL, не означает, что вы можете нарушать все правила Google; используйте правильную переадресацию 301, иначе вы определенно сильно потеряете рейтинг. Вы можете узнать больше об этом здесь, просто переверните код, чтобы выполнить перенаправление в другом направлении.

    Затем вы захотите использовать такой инструмент, как Screaming Frog , чтобы просканировать ваш сайт и найти все внутренние ссылки. Убедитесь, что они указывают на вашу версию HTTP, а не на версию HTTPS, чтобы пользователям не приходилось выполнять перенаправление каждый раз, когда они нажимают внутреннюю ссылку.

    Вы можете реализовать канонизированные URL-адреса , если вы еще этого не сделали. Это сообщит Google, что любые устаревшие HTTPS-версии страниц, которые все еще доступны, должны быть версиями HTTP, и соответствующим образом скорректировать их индекс.

    Наконец, выполните очистку . Убедитесь, что ваши перенаправления работают, протестировав URL-адрес HTTPS. Обязательно отмените подписку на сертификат SSL. Удалите любой другой устаревший код, который не может обрабатывать ссылки, отличные от SSL.

    Да, и вы можете добавить в закладки несколько руководств «как правильно внедрить SSL» на год или два, когда вы решите, что это обновление, которое вам действительно стоит придерживаться, и вы захотите сделать это снова. Убедитесь, что вы делаете это правильно!

    Как перенаправить HTTP на HTTPS с помощью.htaccess

    Chrome и Firefox начали показывать небезопасные предупреждения на сайтах без сертификатов SSL. Без SSL ваш сайт будет небезопасен для посетителей. Следовательно, необходимо использовать соединение с шифрованием SSL в целях безопасности, доступности или соответствия требованиям PCI. Очень важно перенаправить с HTTP на HTTPS.

    Что такое SSL?

    SSL (Secure Sockets Layer) — это стандартный протокол безопасности для установления зашифрованных соединений между веб-сервером и браузером при онлайн-обмене данными.

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

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

    Подробнее: Почему SSL так важен?

    Чтобы заставить ваш веб-трафик использовать HTTPS, отредактируйте коды в .htaccess файл.

    Прежде чем мы перейдем к перенаправлению HTTP на HTTPS, вот как вы можете отредактировать файл .htaccess. Если вы уже знаете, переходите к этапам перенаправления.

    Редактирование файла .htaccess

    В файле .htaccess есть инструкции / директивы, которые сообщают серверу, как действовать в определенных сценариях и напрямую влияют на работу вашего веб-сайта. Общие директивы в файле .htaccess:

    Способы редактирования файла .htaccess:

    1. Отредактируйте файл на своем компьютере и загрузите его на сервер с помощью FTP.
    2. Используйте режим «Редактировать» в программе FTP, который позволяет редактировать файл удаленно.
    3. Используйте текстовый редактор и SSH для редактирования файла.
    4. Используйте диспетчер файлов в cPanel для редактирования файла.

    Редактирование .htaccess в файловом менеджере cPanel

    Примечание: Сделайте резервную копию вашего веб-сайта на случай, если что-то пойдет не так.

    1. Войдите в cPanel
    2. Файлы> Диспетчер файлов> Корень документа для:
    3. Теперь выберите имя домена, к которому вы хотите получить доступ.
    4. Установите флажок «Показать скрытые файлы (файлы точек)»
    5. Нажмите «Перейти»
    6. После нового откроется вкладка или окно, найдите.htaccess файл.
    7. Щелкните правой кнопкой мыши файл .htaccess и выберите в меню «Редактировать код».
    8. Может появиться диалоговое окно с вопросом о кодировании. Нажмите кнопку «Редактировать», чтобы продолжить.
    9. Отредактируйте файл
    10. «Сохраните изменения», когда закончите.
    11. Проверьте свой веб-сайт, чтобы убедиться, что он выполнен правильно. В случае ошибки восстановите предыдущую версию и попробуйте еще раз.
    12. По завершении нажмите «Закрыть», чтобы закрыть окно.

    Перенаправление HTTP на HTTPS

    1.(. *) $ https://www.yourdomain.com/folder/$1 [R, L]

    Примечание. При необходимости замените «yourdomain» на свое фактическое доменное имя. Кроме того, в случае папки замените / папка фактическим именем папки.

    Думаете, это было полезно? Поделитесь этой статьей, чтобы помочь другим перейти на HTTPS.

    Включение HTTPS на серверах | Основы Интернета | Разработчики Google

    Крис — инженер по безопасности в группе безопасности Chrome, специализирующийся на безопасном использовании.

    Мэтт является соавтором Web Fundamentals

    TL; DR

    • Создайте 2048-битную пару открытого и закрытого ключей RSA.
    • Сгенерируйте запрос на подпись сертификата (CSR), который включает ваш открытый ключ.
    • Поделитесь своим CSR с центром сертификации (CA), чтобы получить окончательный сертификат или цепочка сертификатов.
    • Установите окончательный сертификат в недоступном для Интернета месте, например / etc / ssl (Linux и Unix) или там, где этого требует IIS (Windows).

    Создание ключей и запросов на подпись сертификатов

    В этом разделе используется программа командной строки openssl, которая поставляется с большинством Системы Linux, BSD и Mac OS X для генерации закрытых / открытых ключей и CSR.

    Создать пару открытого / закрытого ключей

    Начнем с создания пары ключей RSA длиной 2048 бит. Ключ меньшего размера, такой как 1024 бита, недостаточно устойчив к атакам методом перебора. А ключ большего размера, такой как 4096 бит, является излишним. Со временем размеры ключей увеличиваются по мере компьютерная обработка становится дешевле.2048 — это лучшая точка на данный момент.

    Команда для генерации пары ключей RSA:

      openssl genrsa -out www.example.com.key 2048
      

    Это дает следующий результат:

      Создание закрытого ключа RSA, модуль длиной 2048 бит
    . +++
    .................................................. ..................................... +++
    е - 65537 (0x10001)
      

    Создать запрос на подпись сертификата

    На этом этапе вы вставляете свой открытый ключ и информацию о своей организации. и ваш веб-сайт в запрос на подпись сертификата или CSR. openssl команда интерактивно запрашивает у вас необходимые метаданные.

    Выполнение следующей команды:

      openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
      

    Выводит следующее:

      Вас попросят ввести информацию, которая будет включена
    в ваш запрос на сертификат
    
    То, что вы собираетесь ввести, называется отличительным именем или DN.
    Поля довольно много, но вы можете оставить поле пустым.
    Для некоторых полей будет значение по умолчанию,
    Если вы введете '.', поле останется пустым.
    -----
    Название страны (двухбуквенный код) [AU]: CA
    Название штата или провинции (полное название) [Some-State]: Калифорния
    Название населенного пункта (например, город) []: Mountain View.
    Название организации (например, компания) [Internet Widgits Pty Ltd]: Example, Inc.
    Название организационной единицы (например, раздел) []: Пример Справочного центра для веб-мастеров
    Команда
    Общее имя (например, полное доменное имя сервера или ВАШЕ имя) []: www.example.com
    Адрес электронной почты []: [email protected]
    
    Пожалуйста, введите следующие "дополнительные" атрибуты
    для отправки с запросом на сертификат
    Пароль вызова []:
    Необязательное название компании []:
      

    Чтобы убедиться в действительности CSR, запустите эту команду:

      openssl req -text -in www.example.com.csr -noout
      

    И ответ должен выглядеть так:

      Запрос на сертификат:
        Данные:
            Версия: 0 (0x0)
            Тема: C = CA, ST = California, L = Mountain View, O = Google, Inc.,
    OU = Пример команды Справочного центра для веб-мастеров,
    CN=www.example.com/[email protected]
            Информация об открытом ключе субъекта:
                Алгоритм открытого ключа: rsaEncryption
                    Открытый ключ: (2048 бит)
                    Модуль:
                        00: ad: fc: 58: e0: da: f2: 0b: 73: 51: 93: 29: a5: d3: 9e:
                        f8: f1: 14: 13: 64: cc: e0: bc: be: 26: 5d: 04: e1: 58: dc:
                        ...
                    Показатель степени: 65537 (0x10001)
            Атрибуты:
                а0: 00
        Алгоритм подписи: sha256WithRSAEncryption
             5f: 05: f3: 71: d5: f7: b7: b6: dc: 17: cc: 88: 03: b8: 87: 29: f6: 87:
             2f: 7f: 00: 49: 08: 0a: 20: 41: 0b: 70: 03: 04: 7d: 94: af: 69: 3d: f4:
             ...
      

    Отправьте CSR в центр сертификации

    Разным центрам сертификации (ЦС) требуются разные методы отправки. им ваши CSR. Методы могут включать использование формы на их веб-сайте, отправку КСО по электронной почте или что-то еще.Некоторые центры сертификации (или их посредники) могут даже автоматизировать часть или весь процесс (включая, в некоторых случаях, пару ключей и CSR поколение).

    Отправьте CSR в свой центр сертификации и следуйте его инструкциям, чтобы получить окончательный сертификат или цепочка сертификатов.

    Различные центры сертификации взимают разную сумму денег за услугу поручительства. для вашего открытого ключа.

    Существуют также варианты сопоставления вашего ключа более чем с одним DNS-именем, включая несколько разных имен (например, all of example.com, www.example.com, example.net, и www.example.net) или имена с «подстановочными знаками», например * .example.com.

    Например, один центр сертификации в настоящее время предлагает следующие цены:

    • Стандарт: 16 долларов в год, действительно для example.com и www.example.com.
    • Wildcard: 150 долларов США в год, действительно для example.com и * .example.com.

    По этим ценам подстановочные сертификаты экономичны, если у вас более 9 поддомены; в противном случае вы можете просто купить один или несколько одноименных сертификатов.(Если у вас больше, скажем, пяти поддоменов, вы можете найти подстановочный сертификат удобнее, когда вы включаете HTTPS на своих серверах.)

    Примечание: Имейте в виду, что в сертификатах с подстановочными знаками подстановочный знак применяется только к одна метка DNS. Сертификат, подходящий для * .example.com, будет работать для foo.example.com и bar.example.com, но , а не для foo.bar.example.com.

    Скопируйте сертификаты на все серверы переднего плана в недоступную для Интернета поместите, например, / etc / ssl (Linux и Unix) или там, где требуется IIS (Windows) их.

    Включите HTTPS на своих серверах

    Включение HTTPS на ваших серверах — важный шаг в обеспечении безопасности для ваши веб-страницы.

    • Используйте инструмент Mozilla Server Configuration, чтобы настроить сервер для поддержки HTTPS.
    • Регулярно тестируйте свой сайт с помощью удобного теста SSL-сервера Qualys и убедитесь, что вы получите как минимум пятёрку или пятёрку +.

    На этом этапе вы должны принять важное операционное решение. Выберите один из следующее:

    • Выделите отдельный IP-адрес для каждого имени хоста, который ваш веб-сервер обслуживает контент из.
    • Используйте виртуальный хостинг на основе имени.

    Если вы использовали разные IP-адреса для каждого имени хоста, вы можете легко поддерживать как HTTP, так и HTTPS для всех клиентов.

    Однако большинство операторов сайтов используют виртуальный хостинг на основе имен для сохранения IP-адресов. адреса и потому что в целом удобнее. Проблема с IE на Windows XP и Android ранее, чем 2.3, заключается в том, что они не понимают Server Название Индикация (SNI), что имеет решающее значение для виртуального хостинга на основе имен HTTPS.

    Когда-нибудь — надеюсь, скоро — клиенты, не поддерживающие SNI, будут заменены с современным программным обеспечением. Следите за строкой пользовательского агента в журналах запросов, чтобы знать когда достаточное количество пользователей перешло на современное программное обеспечение. (Ты можешь решить, какой у вас порог; возможно <5% или <1%.)

    Если у вас еще нет службы HTTPS на ваших серверах, включите ее сейчас (без перенаправления HTTP на HTTPS; см. ниже). Настройте свой веб-сервер для использования купленные и установленные вами сертификаты.Вам может пригодиться Mozilla конфигурация генератор полезный.

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

    Предупреждение: Если вы уже выполнили эти шаги, но используете HTTPS для единственная цель перенаправления клиентов обратно на HTTP, прекратите делать это сейчас. Увидеть следующий раздел, чтобы убедиться, что HTTPS и HTTP работают без сбоев. Примечание: В конечном итоге вы должны перенаправить HTTP-запросы на HTTPS и использовать HTTP. Строгая транспортная безопасность (HSTS).Однако это не тот этап в процесс миграции для этого; см. «Перенаправление HTTP на HTTPS» и «Включите строгую транспортную безопасность и безопасные файлы cookie».

    Теперь и на протяжении всего срока службы вашего сайта проверяйте конфигурацию HTTPS с помощью Удобный тест SSL-сервера от Qualys. Ваш сайт должен получить оценку A или A +; относиться ко всему, что вызывает более низкую оценку, как Жук. (Сегодняшний A — это завтрашний B, потому что атаки на алгоритмы и протоколы всегда улучшаются!)

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

    Теперь, когда вы обслуживаете свой сайт как по HTTP, так и по HTTPS, все должно работать как максимально плавно, независимо от протокола.Важным фактором является использование относительные URL-адреса для внутрисайтовых ссылок.

    Убедитесь, что внутрисайтовые и внешние URL-адреса не зависят от протокола; это, убедитесь, что вы используете относительные пути или опустите протокол, например //example.com/something.js .

    Проблема возникает, когда вы обслуживаете страницу через HTTPS, который включает HTTP ресурсы, известные как смешанное содержание. Браузеры предупреждают пользователей, что HTTPS полностью утрачен. По факту, в случае активного смешанного контента (скрипт, плагины, CSS, фреймы), браузеры часто просто не загружает или не выполняет контент вообще, что приводит к битая страница.И помните, что вполне нормально включать ресурсы HTTPS в HTTP-страница.

    Ключевой момент: См. Исправление смешанного содержимого для получения дополнительных сведений о способах исправления и предотвращения смешанного содержимого.

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

    Эти проблемы возникают, когда на ваших страницах есть полностью определенные внутрисайтовые URL. которые используют схему http: // .

    Не рекомендуется — мы рекомендуем избегать с использованием полностью определенных внутрисайтовых URL.

    Добро пожаловать на Example.com

    ;

    новая статья о кошках!

    Другими словами, сделайте внутрисайтовые URL-адреса как можно более относительными: либо относительный к протоколу (отсутствует протокол, начиная с // example.com ) или относительно хоста (начиная с пути, например /jquery.js ).

    Рекомендуется — Мы рекомендуем вам использовать относительные внутрисайтовые URL.

    Добро пожаловать на Example.com

    ;

    новая статья о кошках!

    Рекомендуется — Или вы можете использовать внутрисайтовые URL-адреса, зависящие от протокола.

    Добро пожаловать на Example.com

    ;

    новая статья о кошках!

    Рекомендуется — Мы рекомендуем вам использовать HTTP S URL-адреса для межсайтовых URL-адресов (где это возможно).

    Добро пожаловать на Example.com

    ;

    Новая статья о кошках!

    Посетите этот другой интересный сайт.

    Сделайте это с помощью сценария, а не вручную. Если содержание вашего сайта находится в базе данных, протестируйте свой сценарий на разрабатываемой копии вашей базы данных.Если содержание вашего сайта состоит из простых файлов, проверьте свой сценарий на развернутую копию файлов. Отправляйте изменения в производство только после того, как изменения проходят проверку качества, как обычно. Вы можете использовать Bram van Damme’s сценарий или что-то подобное обнаруживать смешанный контент на вашем сайте.

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

    Успех: Чтобы облегчить миграцию больших сайтов, мы рекомендуем URL-адреса, относящиеся к протоколу.Если вы не уверены, сможете ли вы полностью развернуть HTTPS пока что, принуждение вашего сайта использовать HTTPS для всех подресурсов может иметь неприятные последствия. Вероятно, будет период времени, когда HTTPS станет новым и странным для вы и сайт HTTP должны по-прежнему работать как никогда. Со временем ты завершите миграцию и заблокируйте HTTPS (см. следующие два раздела).

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

    • Используйте для этих ресурсов URL-адреса, зависящие от протокола.Если третья сторона не обслуживайте HTTPS, попросите их. Большинство уже делают, включая jquery.com.
    • Обслуживать ресурсы с сервера, который вы контролируете и который предлагает оба протокола HTTP. и HTTPS. В любом случае это часто бывает хорошей идеей, потому что тогда у вас будет лучше контроль над внешним видом, производительностью и безопасностью вашего сайта. Кроме того, вам не нужно доверять третьей стороне, что всегда приятно.
    Примечание: Имейте в виду, что вам также необходимо изменить внутрисайтовые URL-адреса в вашем таблицы стилей, JavaScript, правила перенаправления, теги и объявления CSP, не только на HTML-страницах.

    Перенаправить HTTP на HTTPS

    Нужно поставить каноническую ссылку в заголовке страницы, чтобы сообщить поисковым системам, что HTTPS — лучший способ попасть на ваш сайт.

    Установите тегов на свои страницы. Этот помогает поисковым системам определить лучший способ попасть на ваш сайт.

    Включите строгую транспортную безопасность и безопасные файлы cookie

    На этом этапе вы готовы «заблокировать» использование HTTPS.

    • Используйте HTTP Strict Transport Security (HSTS), чтобы избежать затрат на перенаправление 301.
    • Всегда устанавливайте флаг безопасности для файлов cookie.

    Сначала используйте строгую транспортную безопасность чтобы сообщить клиентам, что они всегда должны подключаться к вашему серверу через HTTPS, даже при переходе по ссылке http: // . Это побеждает такие атаки, как Удаление SSL, а также позволяет избежать затрат на возврат 301 редиректа , который мы включили в Перенаправить HTTP на HTTPS.

    Примечание. клиентов, которые отметили ваш сайт как известный хост HSTS, скорее всего, отказоустойчивый если на вашем сайте когда-либо возникала ошибка в конфигурации TLS (например, сертификат с истекшим сроком действия).HSTS специально разработан таким образом, чтобы гарантировать, что сетевые злоумышленники не могут обманом заставить клиентов получить доступ к сайту без HTTPS. Не включайте HSTS, пока не убедитесь, что ваш сайт работает нормально. достаточно, чтобы избежать развертывания HTTPS с ошибками проверки сертификатов.

    Включите HTTP Strict Transport Security (HSTS), установив Strict-Transport-Security заголовок. На странице HSTS OWASP есть ссылки на инструкции для различного серверного ПО.

    Большинство веб-серверов предлагают аналогичную возможность добавлять собственные заголовки.

    Примечание: max-age измеряется в секундах. Вы можете начать с низких значений и постепенно увеличивайте max-age по мере того, как вам станет удобнее работать сайт только с HTTPS.

    Также важно убедиться, что клиенты никогда не отправляют файлы cookie (например, для аутентификации или предпочтений сайта) через HTTP. Например, если пользователь файл cookie аутентификации должен был быть представлен в виде простого текста, гарантия безопасности весь их сеанс будет уничтожен, даже если вы сделали все остальное верно!

    Поэтому измените свое веб-приложение, чтобы всегда устанавливать флаг безопасности для файлов cookie. что он устанавливает.На этой странице OWASP объясняется, как установить безопасный флаг в нескольких приложениях каркасы. У каждой платформы приложения есть способ установить флаг.

    Большинство веб-серверов предлагают простую функцию перенаправления. Используйте 301 (перемещено навсегда) чтобы указать поисковым системам и браузерам, что версия HTTPS является канонической, и перенаправьте пользователей на HTTPS-версию вашего сайта с HTTP.

    Поисковый рейтинг

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

    Производительность

    Когда уровни контента и приложения хорошо настроены (см. Книги Стива Содерса для великих совет), оставшиеся проблемы с производительностью TLS, как правило, небольшие, относительные к общей стоимости заявки. Кроме того, вы можете уменьшить и амортизировать эти затраты. (Полезные советы по оптимизации TLS и в целом см. Высокопроизводительная браузерная сеть. Автор Илья Григорик.) См. Также OpenSSL Ивана Ристича Поваренная книга и Пуленепробиваемый SSL и TLS.

    В некоторых случаях TLS может улучшить производительность , в основном за счет HTTP / 2 возможно. Крис Палмер рассказал о производительности HTTPS и HTTP / 2 на Саммит разработчиков Chrome, 2014 г.

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

    • Остальные сайты должны перейти на HTTPS.Если сайты рефери могут заполнить Включите HTTPS на своих серверах в разделе в этом руководстве вы можете изменить ссылки на своем сайте на свои с http: // на https: // , или вы можете использовать ссылки, относящиеся к протоколу.
    • Чтобы обойти различные проблемы с заголовками Referer, используйте новый Стандарт политики реферера.

    Поскольку поисковые системы переходят на HTTPS, в будущем вы, вероятно, чтобы увидеть еще заголовков Referer при переходе на HTTPS.

    Внимание: Согласно HTTP RFC, клиентам НЕ СЛЕДУЕТ включать поле заголовка Referer в (незащищенном) HTTP запросить, передается ли ссылающаяся страница по безопасному протоколу.

    Доход от рекламы

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