Как сделать подключение защищенным
Перейти к содержимому

Как сделать подключение защищенным

  • автор:

Как настроить HTTPS для сайта на WordPress

В статье мы расскажем, зачем переводить свой сайт на HTTPS, как подключить SSL на WordPress и как настроить редирект с HTTP на HTTPS.

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

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

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

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

Как настроить HTTPS для WordPress

Для сайта, созданного на WordPress, переход с HTTP на HTTPS состоит из трёх этапов:

  1. заказ, активация и установка SSL-сертификата на хостинг;
  2. перевод сайта с HTTP на HTTPS в WordPress;
  3. переадресация с HTTP на HTTPS.

Рассмотрим каждый из этапов подробнее.

1 этап. Заказ, активация и установка SSL-сертификата

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

  • Как купить SSL-сертификат;
  • Как заказать бесплатный SSL-сертификат. Вы можете заказать SSL бесплатно на 6 месяцев, если у вас есть домен или хостинг в Рег.ру (например, WordPress hosting или бесплатный хостинг для сайтов WordPress).

После оплаты заказа вам на почту придёт письмо с данными для активации SSL. Следуйте одной из инструкций: Как активировать сертификаты: OrganizationSSL и ExtendedSSL и Как активировать сертификаты: AlphaSSL и DomainSSL.

Если вы установили SSL-сертификат на хостинг, переходите к настройке сайта на HTTPS в WordPress.

2 этап. Перевод сайта на HTTPS

Чтобы ваш сайт открывался по защищённому протоколу, переведите его с HTTP на HTTPS в админ-панели WordPress. Для этого поменяйте две основные ссылки в базе данных сайта.

 HTTPS для сайта на WordPress 1

Перейдите в раздел Настройки. На странице «Общие настройки» в строках «Адрес WordPress (URL)» и «Адрес сайта (URL)» замените префикс http:// на https://. Затем нажмите Сохранить изменения.

Готово, теперь ваш сайт доступен по протоколу HTTPS. Однако все ссылки на сайте и в административной панели продолжат работать по протоколу HTTP.

Чтобы перевести все ссылки на HTTPS, переходите к следующему шагу.

3 этап. Настройка переадресации с HTTP на HTTPS

На этом этапе нужно настроить 301 редирект — он перенаправит все ссылки вашего сайта со старого URL-адреса (http://) на новый (https://). Без редиректа на сайте вместо зелёного замка в строке браузера будет отображаться ошибка смешанного содержимого — «Mixed Content». Также 301 редирект позволит не потерять SEO-позиции сайта.

Настроить редирект с HTTP на HTTPS можно двумя способами:

  • на хостинге: в панели управления ispmanager или в конфигурационном файле .htaccess через панели cPanel и Plesk по инструкции Редирект с http на https для Linux;
  • установить плагин Really Simple SSL на WordPress по инструкции ниже.

Мы рекомендуем использовать плагин. Он позволяет настроить редирект на уровне PHP и меняет все ссылки в базе данных сайта автоматически.

Как настроить редирект с помощью плагина Really Simple SSL

Иногда при замене ссылок плагин может повредить содержимое сайта. Чтобы избежать потери данных, перед настройкой плагина сделайте бэкап: Как скачать резервную копию (бэкап) сайта?

Чтобы настроить редирект с помощью плагина:

HTTPS для сайта на WordPress 2

Перейдите в раздел «Плагины». Нажмите кнопку Добавить новый и в строке поиска введите «Really simple ssl». Затем нажмите Установить:

HTTPS для сайта на WordPress 3

После установки нажмите Активировать:

HTTPS для сайта на WordPress 4

Чтобы подтвердить активацию, нажмите Активировать SSL:

HTTPS для сайта на WordPress 5

Чтобы завершить активацию, нажмите Go to Dashboard:

HTTPS для сайта на WordPress 6

Готово, вы активировали плагин Really Simple SSL. Если вы хотите скорректировать действие плагина, во вкладке Настройки пролистайте до блока «Общее», затем укажите нужные параметры и нажмите Сохранить:

Если после активации и настройки плагина на вашем сайте по-прежнему отображается ошибка «Mixed Content», проверьте все ссылки на внешние ресурсы. Если они ведут на сайты с протоколом HTTP — замените их. Если это не поможет, обратитесь в службу поддержки.

Теперь ваш сайт в WordPress будет работать по защищённому протоколу HTTPS. Посетители не будут беспокоиться о сохранности своих данных при работе с вашим сайтом.

Как настроить HTTPS для плагина Elementor

Если вы используете плагин Elementor, то ссылки можно заменить в разделе «Инструменты». Для этого:

 HTTPS для сайта на WordPress 6

Перейдите в раздел Elementor — Инструменты. Выберите вкладку Сменить URL:

  • http://old-url.com — укажите ссылку на ваш сайт с протоколом HTTP,
  • http://new-url.com — укажите такую же ссылку, но с протоколом HTTPS.

 HTTPS для сайта на WordPress 7

Затем кликните Сменить URL:

Готово, вы настроили HTTPS.

Как исправить ошибку «Ваше подключение не защищено»

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

  • ваше подключение не защищено,
  • это соединение является недоверенным,
  • подключение не защищено,
  • подключение к сайту не защищено.

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

Что такое защищённое соединение

Когда появился интернет, проблем с мошенниками не было. Разработчикам было важно наладить сам процесс передачи данных. Одной из важных разработок для интернета стал протокол передачи данных – HTTP (HyperText Transfer Protocol). С его помощью браузер получает информацию от сервера и показывает пользователю контент.

Со временем проблема утечки персональных данных стала очень острой, и на смену HTTP пришёл HTTPS. HTTPS (HyperText Transfer Protocol Secure) ― защищённый протокол передачи данных в интернете. Это тот же протокол HTTP, но защищённый SSL-сертификатом, который выдаётся центром сертификации после проверки сайта и его владельца. Владелец ресурса должен приобрести SSL и установить HTTPS-соединение, чтобы пользователи могли безопасно заходить на его сайт. Подробнее о работе протокола читайте в статье Что такое протокол HTTPS и принципы его работы.

Если раньше защищённое соединение было необязательным, то сейчас браузеры оповещают пользователей о незащищённых сайтах. Они могут это делать в URL-строке или показывать сообщение вида «Ваше подключение не защищено» на весь экран.

Сообщение «Ваше подключение не защищено»: как исправить

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

Кроме этой причины, есть ещё несколько как на стороне пользователя, так и на стороне владельца.

Подключение не защищено в Google Chrome и других браузерах: как исправить ошибку владельцу

Чаще всего на стороне владельца проблемы возникают по следующим причинам:

  • Установлен самоподписанный SSL-сертификат. SSL-сертификат можно купить или выпустить самому. Самоподписанный бесплатный сертификат обеспечивает такую же защиту передаваемых данных, как и заверенный платный сертификат. Однако браузер не доверяет самовыпущенным SSL, так как они не верифицированы сторонней компанией. Заверенные платные сертификаты, помимо защиты передачи данных, гарантируют, что информация о домене и его владельце была проверена независимым источником. Если владельцем домена является юридическое лицо, сертификат гарантирует, что такая компания действительно существует и её деятельность законна. Поэтому, если вы пользуетесь самоподписанным SSL, пользователи будут часто встречаться с таким предупреждением на вашем сайте.
  • Закончился срок действия SSL-сертификата. Сертификат приобретается на 1 год. Если вы зашли на привычный сайт и увидели ошибку, достаточно подождать, когда владелец продлит SSL. Тогда защищённое соединение будет восстановлено. Если вы владелец ресурса и покупали сертификат в Рег.ру, установите функцию автопродления в личном кабинете. Так вы не забудете продлить услугу, и данные ваших посетителей будут надёжно защищены.
  • Сайт не настроен для работы по HTTPS. Кроме покупки и установки сертификата, нужно настроить переадресацию сайта на HTTPS. Если владелец веб-сайта этого не сделал, браузер будет выдавать ошибку.
  • Подключение к сайту защищено не полностью. Даже если владелец установил SSL и сделал переадресацию ресурса на HTTPS, внутри сайта могут находиться ссылки на внутренние страницы и файлы (CSS-стили, изображения, видео и т. д.), которые работают по HTTP. В такой ситуации поисковые системы будут считать ресурс небезопасным и в браузере будут появляться уведомления об этом. Чтобы исправить ошибку, нужно найти все HTTP-ссылки и изменить их на HTTPS. Если вы работаете с WordPress, можно использовать плагины, например Easy HTTPS Redirection и Really Simple SSL. Подробнее о том, как пользоваться этими плагинами, читайте в статье.

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

Подключение не защищено в Google Chrome и других браузерах: как отключить ошибку пользователю

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

  • На устройстве установлена неправильная дата и время. Для установки соединения между браузером и сайтом важно, чтобы дата и время на обоих устройствах совпадали. Если они не совпадают, может возникнуть ошибка SSL-подключения. Необязательно, чтобы всё было выверено до секунды. Достаточно, чтобы совпадал день и час. Многие браузеры уже научились определять проблему неправильного времени, поэтому можно увидеть сообщение «Часы отстают» или «Часы спешат».
  • Мешают кэш и куки. Если даже спустя некоторое время веб-ресурс так и не открылся, попробуйте почистить временные данные. Во-первых, в них могла сохраниться старая версия сайта с ошибкой. В этом случае сайт уже может работать по HTTPS, но кэш не даст вам перейти на обновлённую версию веб-ресурса. Во-вторых, переполненная память кеша и cookies влияет на работу браузера и может вызывать ошибки.
  • Мешают расширения. Если вы недавно установили новые расширения для браузера, попробуйте отключить их или удалить. Иногда они могут нарушать его работу.
  • Антивирус и брандмауэр мешают соединению. Бывает, что антивирус или брандмауэр блокируют подозрительные сайты. Если вы уверены в безопасности страницы, можете попробовать отключить защиту на некоторое время и попытаться перейти на сайт снова. Однако, программы-защитники редко ошибаются.
  • Обновите браузер. Старые версии со временем теряют свою работоспособность. Если у вас старый браузер, обновите его.
  • Проверьте файл hosts. Мошенники умеют проникать в файл hosts на вашем устройстве и менять IP-адреса сайтов. Таким образом можно попасть на сайт-двойник, который сделали злоумышленники. Браузер или антивирус может заподозрить подмену и сообщить о мошеннических действиях. Откройте файл и проверьте его настройки. Если там есть посторонние записи, удалите их. О том, что такое hosts и как им пользоваться читайте в наших инструкциях для разных ОС:
    • Windows 10,
    • Windows 7,
    • macOS,
    • Linux,
    • Android.

    Что делать, если сообщение о небезопасности наблюдается при переходе в панель управления

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

    Как подключиться по небезопасному соединению

    Ниже мы дадим инструкцию, как подключиться по HTTP к сайту при появлении ошибки «подключение не защищено» в браузерах Google Chrome, Mozilla Firefox и Safari.

    Google Chrome
    Mozilla Firefox

    Как зайти по незащищенному соединению 1

    Нажмите Дополнительные: Подключение не защищено в Google: как убрать блокировку доступа

    Как зайти по незащищенному соединению 2

    Нажмите на ссылку Перейти на сайт 123.123.123.123 (небезопасно):

    Как зайти по незащищенному соединению 3

    Нажмите Дополнительно:

    Как зайти по незащищенному соединению 4

    Нажмите Принять риск и продолжить:

    Как зайти по незащищенному соединению 5

    Нажмите Подробнее:

    Как зайти по незащищенному соединению 6

    Нажмите на ссылку посетить этот веб-сайт:

    Готово, вы зашли на страницу по HTTP-протоколу.

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

    Помогла ли вам статья?

    Спасибо за оценку. Рады помочь ��

    Перевод сайта на защищенный протокол. Пошаговое руководство

    Материал рассчитан на начинающих специалистов в области оптимизации сайтов, вебмастеров, администраторов и владельцев ресурсов Автор: Константин Гайдук, независимый специалист по продвижению сайтов. В SEO с 2010 года. Работает в Москве. С июля 2018 года абсолютно все сайты, использующие обычный незащищенный протокол http, начали помечаться в Гугл Хроме, одном из самых популярных браузеров, как ненадежные. Именно поэтому переход на https сейчас наиболее актуален.

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

    Какие бывают виды сертификатов?

    Классификация сертификатов, их возможности и отличия, уже много раз освещались. С практической точки зрения можно отметить только, что для большинства пользователей важно деление на платные и бесплатные. Самый популярный из бесплатных — Let’s Encrypt. Установка такого сертификата обычно требует минимальных усилий (несколько кликов в панели управления хостингом) и обычно предоставляется хостингами и регистраторами бесплатно. Let’s Encrypt можно выписать не только для домена, но и для поддоменов сайта. В процессе работы было сделано интересное наблюдение: Let’s Encrypt предлагают наиболее качественные хостинги с ценником выше среднего по рынку. В более дешевых можно установить, как правило, только платные сертификаты.

    Перевод сайта на защищенный протокол по шагам

    1. Выпуск SSL-сертификата осуществляется либо через хостинг, либо через регистратора домена (если домен зарегистрирован через хостинговую компанию, только через хостинг). 2. Адреса внутренних ссылок в контенте сайта меняем на новые (в том числе адреса изображений). Там, где было http://site/url, должно стать https://site/url. Если страниц очень много, есть смысл изучить структуру базы данных с целью поиска возможности массовой замены. Например, типовой случай для Вордпресса:

    UPDATE `wp_posts` SET `guid` = REPLACE(`guid`, 

    'http://site.ru', 'https://site.ru');

    UPDATE `wp_posts` SET `post_content` = REPLACE(`post_content`,

    'http://site.ru', 'https://site.ru');

    • во всех меню сайта,
    • сквозных блоках,
    • ссылки в разделе head страницы на файлы стилей, скрипты, шрифты.

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

    Например, шрифты Гугл доступны по двум адресам:

    Необходимо указать адрес с сертификатом.

    Если внешний ресурс доступен только по незащищенному протоколу, то адрес необходимо указать так:

    //site.ru 

    5. Проверка в Браузерах

    • Открываем каждую страницу сайта в Mozilla Firefox и проверяем не высвечивается ли ошибка рядом с адресом сайта:

    Если страниц на сайте много, проверяем выборочно.

    • Открываем каждую страницу сайта в Google Chrome и проверяем, не высвечивается ли ошибка рядом с адресом сайта (если страниц много, также проверяем выборочно). При проверке в этом браузере страницы необходимо обновлять каждый раз при открытии.Также в Гугл Хроме нужно следить за появлением иконки справа от адреса:

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

    Если на сайте есть скрипт, ссылающийся на незащищенный ресурс, Гугл Хром по умолчанию его не загрузит. На сайте, например, может перестать работать форма обратной связи или что-то другое.

    Идентифицировать проблемный скрипт можно, вызвав в Гугл Хроме «Инструменты разработчика» (сочетание клавиш Ctrl + Shift + I) и открыв вкладку «Console»:

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

    В ряде случаев протокол может задаваться в файле конфигураций. Для Вордпресса это wp-config.php:

    define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST']); 

    define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST']);

    или

    define('WP_HOME','https://site.com');

    define('WP_SITEURL','https://site.com');

    if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' == $_SERVER['HTTP_X_FORWARDED_PROTO'] )

    $_SERVER['HTTPS'] = 'on';

    >

    7. Устанавливаем в файле .htaccess 301 редирект со всех http-адресов страниц на соответствующие новые адреса с https.

    В некоторых случаях необходимо прописать такое выражение:

    RewriteEngine On 

    RewriteCond % !^443$

    RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]

    В некоторых:

    RewriteCond % off 

    RewriteCond % !https

    RewriteRule ^(.*)$ https://%% [L,R=301]

    8. Устанавливаем 301 редирект на новую версию сайта с других (неглавных зеркал), если таковые имеются.

    Например, если ранее редирект с неглавного зеркала:

    http://site.ru/ стоял на http://www.site.ru/

    То теперь нужно проставить редиректы с обоих зеркал на https://site.ru/

    Тоже самое относится и к редиректам http://oldsite.ru/ https://newsite.ru/

    9. Если в файле .htaccess были редиректы с одного раздела на другой (с одной страницы на другую и т.д.), то необходимо поправить, чтобы стояли прямые редиректы на страницу/раздел с защищенным протоколом.

    10. Сканируя весь сайт, проверяем, не осталось ли ссылок с редиректами. Исправляем на прямые ссылки.

    11. Создаем новую карту сайта sitemap.xml и загружаем на сервер.

    12. В файле robots прописываем новый адрес карты сайта.

    13. Добавляем сайт с защищенным протоколом в панель Яндекс.Вебмастера. В разделе «Переезд сайта» указываем новое главное зеркало. Загружаем обновленную карту сайта.

    14. Добавляем сайт с защищенным протоколом в панель Google Search Console. Загружаем обновленную карту сайта.

    Результаты переезда сайтов на защищенный протокол в чистом виде

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

    Сайт 1, Яндекс:

    Сайт 1, Google:

    Сайт 2, Яндекс:

    Сайт 2, Google:

    Таким образом подтверждаются известные истины о том, что https является фактором ранжирования в Гугле, и что, несмотря на внимание Янедкса этому вопросу и взаимодействие с пользователями, переезд в этой поисковой системе может привести к непредсказуемым результатам (как к спаду позиций на примере сайта1, так и к повышению на примере сайта 2).

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

    Вывод в топ-5 сайта доставки цветов или Цветы стоят ссылок

    О том, как за 4 месяца подготовить сайт к пику продаж и вывести его в топ-5 результатов выдачи по высокочастотным запросам, на примере бизнеса по доставке цветов

    Полное руководство по переходу с HTTP на HTTPS

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

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

    Сюда включены детальные инструкции для владельцев виртуального хостинга на cPanel, администраторов серверов Apache HTTP и nginx под Linux и Unix, а также Internet Information Server под Windows.

    Начнём с основ.

    HTTP, HTTPS, HTTP/2, SSL, TLS: где что?

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

    Hypertext Transfer Protocol (HTTP) — основной протокол связи, который должны поддерживать клиент и сервер, чтобы установить соединение. Он описывает такие понятия как запросы и ответы, сессии, кэширование, аутентификация и др. Работу над протоколом, а также над языком гипертекстовой разметки Hypertext Markup Language (HTML) начал в 1989 году сэр Тим Бернерс-Ли и его группа в ЦЕРН. Первая официальная версия протокола (HTTP 1.0) вышла в 1996 году, а вскоре в 1997 году появилась версия HTTP 1.1, которая широко используется сегодня.

    Протокол передаёт информацию между браузером и сервером в чистом тексте, позволяя видеть эту информацию в сети, через которую она проходит. Это проблема безопасности, поэтому был изобретён HTTP Secure (HTTPS), позволяющий клиенту и серверу устанавливать зашифрованный канал связи, а затем передавать сообщения чистым текстом по этому каналу, эффективно защищая их от прослушивания.

    Термины SSL и TLS часто используются как взаимозаменяемые, поскольку TLS 1.0 приходит на место SSL 3.0. Сам SSL был разработан в компании Netscape, а TLS — это стандарт IETF. На момент написания этой статьи все версии SSL (1.0, 2.0, 3.0) не рекомендуются для использования из-за различных проблем с безопасностью, и современные браузеры выводят предупреждения об этом. Из стандарта TLS используются версии 1.0, 1.1 и 1.2, а версия 1.3 сейчас на стадии черновика.

    Так что где-то между 1996 и 1997 годами мы получили текущую стабильную версию Интернета (HTTP 1.1 с или без SSL и TLS), которая по-прежнему поддерживается на большинстве современных веб-сайтов. Ранее HTTP использовался для несущественного трафика (например, чтения новостей), а HTTPS применяли для важного трафика (например, аутентификации и электронной коммерции): однако увеличение значения приватности привело к тому, что браузеры вроде Google Chrome сейчас помечают веб-сайты HTTP как «не конфиденциальные» и в будущем будут выводить новые предупреждения для них.

    В следующем обновлении протокола HTTP — HTTP/2 — которую поддерживает всё большее количество сайтов, реализованы новые функции (сжатие, мультиплексирование, приоритет разного трафика), чтобы уменьшить задержки и увеличить производительность и безопасность.

    В HTTP версии 1.1 безопасное соединение является необязательным (у вас может быть HTTP и/или HTTPS независимо друг от друга), в то время как в HTTP/2 оно на практике обязательно — даже хотя стандарт допускает HTTP/2 без TLS, но большинство разработчиков браузеров заявили, что они реализуют поддержку HTTP/2 только через TLS.

    Что даёт HTTPS?

    Почему в первую очередь стоит думать о HTTPS? Его внедряют по трём основным причинам:

    • Конфиденциальность
      В открытой среде, такой как Интернет, он защищает коммуникации между двумя сторонами. Например, в отсутствие HTTPS владелец точки доступа WiFi может видеть приватные данные, такие как кредитные карты, если пользователь этой точки доступа совершает покупки в онлайне.
    • Целостность
      Он гарантирует, что информация достигнет адресата в полном и нетронутом виде. Например, наш друг с точкой доступа WiFi может добавить дополнительную рекламу на наш сайт, снизить качество изображений для экономии трафика или изменить содержимое статей, которые мы читаем. HTTPS гарантирует, что веб-сайт не может быть изменён.
    • Подлинность
      Он гарантирует, что веб-сайт в реальности является тем, за кого себя выдаёт. Например, тот же самый владелец точки доступа WiFi мог бы отправлять браузеры на поддельный сайт. HTTPS гарантирует, что веб-сайт, который представляется как example.com , действительно является example.com . Некоторые сертификаты даже проверяют правовую идентичность владельца веб-сайта, так что вы знаете, что yourbank.com принадлежит YourBank, Inc.

    Криптография в основе

    Конфиденциальность, целостность и проверка подлинности не являются уникальными особенностями HTTPS: это ключевые концепции криптографии. Давайте посмотрим на них более внимательно.

    Конфиденциальность

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

    Чтобы две стороны могли общаться, они должны прийти к согласию по двум вопросам:

    1. Какой алгоритм (шифровальную функцию) использовать в коммуникации.
    2. Какие параметры, пароли или правила (то есть секрет) будут использоваться с выбранным методом.
    • симметричное
      Обе стороны владеют общим секретным ключом.
    • асимметричное
      Одна из сторон владеет парой из публичного и секретного ключей, представляя основу инфраструктуры публичных ключей (public key infrastructure, PKI).

    Симметричное шифрование (см. большую версию)

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

    Итак, как это работает? Предположим, что у нас есть две стороны, которые желают безопасно общаться друг с другом — Алиса и Боб (в каждом учебнике всегда используются такие имена вымышленных персонажей, в справочниках по безопасности и прочих, мы уважаем эту традицию). У каждого из них есть своя пара ключей: один секретный, а один публичный. Секретные ключи известны только их соответствующим владельцам; публичные ключи открыты для всех.

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

    Если Боб хочет отправить сообщение Алисе, он должен раздобыть её публичный ключ, зашифровать открытый текст и отправить ей шифротекст. Она затем использует свой секретный ключ для расшифровки.

    Асимметричное шифрование (см. большую версию)

    Когда мы используем симметричное, а когда асимметричное шифрование?

    Асимметричное шифрование используется для обмена секретом между клиентом и сервером. В реальной жизни нам обычно не нужна двусторонняя асимметричная коммуникация — достаточно, если одна из сторон (назовём её сервер для простоты) владеет набором ключей, так что она может получать зашифрованные сообщения. В реальности это защищает информацию только в одном направлении — от клиента к серверу, потому что информация, зашифрованная публичным ключом, может быть расшифрована только с помощью парного ему секретного ключа: значит, только сервер может её расшифровать. Другое направление не защищено — информация, зашифрованная секретным ключом сервера, может быть расшифрована его публичным ключом, который открыт для всех. Другая сторона (также для простоты назовём её клиент) начинает коммуникацию с шифрования случайно сгенерированного секрета сессии публичным ключом сервера, затем отправляет шифротекст обратно на сервер, который, в свою очередь, расшифровывает его с помощью своего секретного ключа, и теперь владеет секретом.

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

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

    Целостность

    Другая проблема, которую решает HTTPS — это целостность данных: 1) гарантия, что вся информация доставляется целиком; 2) гарантия, что никто не изменяет информацию при её передаче. Для обеспечения целостной передачи информации используются алгоритмы дайджеста сообщения. Вычисление кодов аутентификации сообщений (MAC) для каждого сообщения при обмене — это процесс криптографического хеширования. Например, для получения MAC (иногда он называется тегом) используется метод, который гарантирует практическую невозможность (иногда используется термин невыполнимость) осуществить следующее:

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

    Проверка подлинности

    Что насчёт аутентичности? Проблема с реальными приложениями публичной инфраструктуры ключей состоит в том, что ни у одной стороны нет способа узнать, кем на самом деле является вторая сторона — они физически разделены друг от друга. Чтобы доказать свою аутентичность второй стороне, вовлекается третья сторона, имеющая взаимное доверие — центр сертификации (CA). Этот CA выпускает сертификат с подтверждением того, что доменное имя example.com (уникальный идентификатор) связано с публичным ключом XXX . В некоторых случаях (с сертификатами EV и OV — см. ниже) CA также проверяет, что конкретная компания контролирует этот домен. Эта информация гарантирована (то есть сертифицирована) центром сертификации Х, и эта гарантия действует не раньше, чем дата Y (то есть сертификат начинает действовать с этой даты), и не позже чем дата Z (то есть сертификат заканчивает своё действие в эту дату). Вся эта информация включена в один документ, который называется сертификат HTTPS. Чтобы привести легко понимаемую аналогию — это как ID или паспорт, который выдаёт правительство страны (то есть третья сторона, которой все доверяют) — и все, кто доверяют правительству, будут также доверять сертификату (паспорту) его владельца и самому владельцу. Предполагается, конечно, что паспорт не поддельный, но подделка сертификатов выходит за рамки данной статьи.

    Центры сертификации — это организации, которым доверяют подпись сертификатов. В операционных системах, таких как Windows, macOS, iOS и Android, а также в браузере Firefox есть список доверенных сертификатов.

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

    • Firefox
      “Options” → “Advanced” → “Certificates” → “View Certificates” → “Authorities”
    • Windows
      “Control Panel” → “Internet Options” → “Content” — “Certificates” → “Trusted Root Certification Authorities / Intermediate Certification Authorities”
    • Mac
      “Applications” → “Utilities” → “Keychain Access.” В “Category” выберите “Certificates”

    Цепочка доверия (см. большую версию)

    Вы можете добавить дополнительные центры сертификации, что полезно при работе с самоподписанными сертификатами (которые мы обсудим позже).

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

    Типы сертификатов HTTPS

    Существует несколько типов сертификатов HTTPS. Их можно классифицировать по следующим критериям.

    1. Проверка подлинности

    1. Подтверждённый домен (DV)
      Самый распространённый тип сертификатов DV подтверждает, что домен соответствует определённому публичному ключу. Браузер устанавливает безопасное соединение с сервером и демонстрирует значок закрытого замка. Нажатие по значку выводит сообщение «Этот веб-сайт не предоставил информации о владельце». Для получения этого сертификата не выдвигается никаких дополнительных требований, кроме владения доменом — сертификат DV просто гарантирует, что для этого домена предъявлен правильный публичный ключ. Браузер не показывает название юридического лица. Сертификаты DV часто дёшевы ($10 в год) или бесплатны — см. разделы о Let’s Encrypt и Cloudflare ниже.
    2. Расширенное подтверждение (EV)
      Сертификаты EV подтверждают юридическое лицо, которому принадлежит веб-сайт. Это самый заслуживающий доверия тип сертификатов. Его выдают после того, как центр сертификации проверит юридическое лицо, которое контролирует домен. Юридическое лицо проверяется по нескольким условиям:

    • управление доменом (наличие сертификата DV);
    • государственный реестр для проверки, что компания зарегистрирована и действительна;
    • независимые бизнес-справочники, такие как Dunn и Bradstreet, connect.data.com от Salesforce, Yellow Pages и др.;
    • проверочный телефонный звонок;
    • проверка всех доменных имён в сертификате (подстановочные символы явно запрещены в сертификатах EV).

    2. Количество покрываемых доменов

    В давние времена сертификаты HTTPS обычно содержали в поле CN единственный домен. Позже было добавлено «альтернативное имя субъекта» (SAN), чтобы один сертификат покрывал и дополнительные домены. В наши дни все сертификаты HTTPS создаются одинаково: даже в сертификате на единственный домен будет поле SAN для этого единственного домена (и второе поле SAN для версии www этого домена). Однако многие продавцы по историческим причинам по-прежнему продают сертификаты HTTPS на один и несколько доменов.

    1. Один домен
      Это самый распространённый тип сертификата, действительный для доменных имён example.com и www.example.com .
    2. Несколько доменов (UCC/SAN)
      Этот тип сертификата, также известный как сертификат Unified Communications Certificate (UCC) или Subject Alternative Names (SAN), может покрывать список доменов (до определённого предела). Он не ограничен единственным доменом — вы можете указать различные домены и поддомены. Стоимость обычно включает в себя определённое количество доменов (от трёх до пяти) с возможностью добавить больше (до определённого предела) за дополнительную плату. Рекомендуется использовать его только с родственными сайтами, потому что клиент при проверке сертификата на любом веб-сайте увидит основной домен, а также все дополнительные.
    3. Поддомены (wildcard)
      Этот тип сертификата покрывает основной домен, а также неограниченное количество поддоменов ( *.example.com ) — например, example.com , www.example.com , mail.example.com , ftp.example.com и т. д. Ограничение в том, что он покрывает только поддомены основного домена.
    Тип сертификата Подтверждённый домен (DV) Подтверждённая организация (OV) Расширенное подтверждение (EV)
    HTTPS HTTPS
    Проверенный правообладатель
    HTTPS
    Проверенный правообладатель
    Информация о владельце отображается в браузере
    Один домен example.com, www.example.com
    Несколько доменов example.com , www.example.com , mail.example.com , example.net , example.org и др.
    Определённый заранее список, до некоторого лимита (обычно 100)
    Поддомены *.example.com
    Подходит для любого поддомена
    Недоступно — все имена должны быть явно включены в сертификат и проверены центром сертификации

    Конфигурация

    Чтобы подвести итог, четыре компонента HTTPS требуют шифрования:

    1. Первоначальный обмен ключами
      Используются асимметричные алгоритмы (секретный и публичный ключи).
    2. Сертификация идентичности (сертификат HTTPS, выданный центром сертификации)
      Используются асимметричные алгоритмы (секретный и публичный ключи).
    3. Реальное шифрование сообщений
      Используются симметричные алгоритмы (предварительно разделённый совместный секрет).
    4. Дайджест сообщений
      Используются алгоритмы криптографического хеширования

    Например, выбор ECDHE-RSA-AES256-GCM-SHA384 означает, что обмен ключами будет производиться по алгоритму Elliptic Curve Diffie-Hellman Ephemeral (ECDHE); центр сертификации подписал сертификат при помощи алгоритма Rivest-Shamir-Adleman (RSA); симметричное шифрование сообщений будет использовать шифр Advanced Encryption Standard (AES) с 256-битным ключом и будет работать в режиме GCM; целостность сообщений будет обеспечивать алгоритм безопасного хеширования SHA, с использованием 384-битных дайджестов. (Доступен полный список комбинаций алгоритмов).

    Итак, нужно сделать выбор некоторых конфигураций.

    Наборы шифров

    Выбор набора шифров для использования — это компромисс между совместимостью и безопасностью:

    • Для совместимости со старыми браузерами нужно, чтобы сервер поддерживал старые наборы шифров.
    • Однако многие старые наборы шифров больше не считаются безопасными.

    Википедия содержит исчерпывающий список алгоритмов для всех компонентов TLS и указывает их поддержку в разных версиях SSL и TLS.

    Mozilla SSL Configuration Generator — очень полезный и крайне рекомендуемый справочник, какие криптографические методы использовать на сервере. Мы позже будем использовать его в реальных серверных конфигурациях.

    Типы ключей

    Сертификаты Elliptic Curve Cryptography (ECC) быстрее обрабатываются и используют меньше CPU, чем сертификаты RSA, что особенно важно для мобильных клиентов. Однако некоторые сервисы, такие как Amazon, CloudFront и Heroku на момент написания этой статьи пока не поддерживают сертификаты ECC.

    256-битная длина ключа для ECC считается достаточной.

    Сертификаты Rivest Shamir Adleman (RSA) более медленные, но совместимы с большим разнообразием старых серверов. Ключи RSA больше по размеру, так что 2048-битный ключ RSA считается минимально допустимым. Сертификаты RSA с ключами 4096 бит и больше могут ухудшать производительность — к тому же, скорее всего, они подписаны 2048-битным ключом посредника, что по большей части подрывает дополнительную защиту!

    Вы могли заметить расплывчатость заявлений, сделанных выше, и отсутствие каких-либо чисел. То, что может нагрузить один сервер, не нагрузит другой сервер. Лучший способ определить влияние на производительность — это проверить загрузку на своём собственном сервере, с реальным веб-сайтом и реальными посетителями. И даже это изменится со временем.

    Процедуры

    Для получения сертификаты HTTPS выполните следующие шаги:

    1. Создайте пару из секретного и публичного ключей и подготовьте запрос на подпись сертификата (Certificate Signing Request, CSR), включающий информацию об организации и публичном ключе.
    2. Свяжитесь с центром сертификации и запросите сертификат HTTPS на основании CSR.
    3. Получите подписанный сертификат HTTPS и установите его на своём сервере.

    Для начала, есть два популярных формата хранения информации — DER и PEM. Первый из них (DER) бинарный, а второй (PEM) — это файл DER в кодировке base64 (текст). По умолчанию Windows напрямую использует формат DER, а мир свободных систем (Linux и UNIX) использует формат PEM. Существуют инструменты (OpenSSL) для конвертации файлов из одного формата в другой.

    В качестве примеров мы будем использовать такие файлы:

    • example.com.key
      Файл в формате PEM с секретным ключом. Расширение .key не является стандартом, так что кто-то может использовать его, а кто-то нет. Файл должен быть защищён и доступен только для суперпользователя.
    • example.com.pub
      Файл в формате PEM с публичным ключом. Вам на самом деле не нужен этот файл (и он никогда не будет явно присутствовать), потому что его можно сгенерировать из секретного ключа. Он включён сюда только для примера.
    • example.com.csr
      Это запрос на подпись сертификата. Файл в формате PEM содержит информацию об организации, а также публичный ключ сервера. Его нужно отправить в центр сертификации, выдающий сертификаты HTTPS.
    • example.com.crt
      Сертификат HTTPS, выданный центром сертификации. Это файл в формате PEM, который содержит публичный ключ сервера, информацию об организации, подпись центра сертификации, даты начала и окончания срока действия и др. Расширение .crt не является стандартом; часто используются другие расширения, в том числе .cert и .cer .

    Секретный ключ — это случайно сгенерированная строка определённой длины (мы используем 2048 бит), которая выглядит примерно так:

    ——BEGIN RSA PRIVATE KEY——
    MIIEowIBAAKCAQEAm+036O2PlUQbKbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9N
    i8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4E
    S17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWu
    Q30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnf
    b/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDil
    Tt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQgNQIDAQABAoIBAEAO2KVM02wTKsWb
    dZlXKEi5mrtofLhkbqvTgVE7fbOKnW8FJuqCl+2NMH31F1n03l765p4dNF4JmRhv
    /+ne4vCgOPHR/cFsH4z/0d5CpHMlC7JZQ5JjR4QDOYNOpUG51smVamPoZjkOlyih
    XGk/q72CxeU6F/gKIdLt6Dx03wBosIq9IAE8LwdMnioeuj18qaVg195OMeIOriIn
    tpWP4eFya5rTpIFfIdHdIxyXsd6hF/LrRc9BMWTY1/uOLrpYjTf7chbdNaxhwH7k
    buvKxBvCvmXmd6v/AeQQAXbUkdSnbTKDaB9B7IlUTcDJyPBJXvFS1IzzjN6vV+06
    XBwHx5ECgYEAyRZLzwnA3bw8Ep9mDw8JHDQoGuQkFEMLqRdRRoZ+hxnBD9V9M0T6
    HRiUFOizEVoXxf6zPtHm/T7cRD8AFqB+pA/Nv0ug6KpwUjA4Aihf5ADp0gem0DNw
    YlVkCA6Bu7c9IUlE0hwF7RLB7YrryJVJit9AymmUTUUHCQTWW2yBhC8CgYEAxoHS
    HGXthin5owOTNPwLwPfU2o7SybkDBKyW69uTi0KxAl3610DjyA/cV2mxIcFlPv1y
    HualGd9eNoeCMBy/AUtjzI0K77yeRpjj321rj6k8c8bYWPHH539SiBXLWTY/WQ0w
    pxfT3d/Z4QMh5d6p+p5f3UIrXESYQd+fAaG5tNsCgYEAksTdTB4YUT9EsWr6eN9G
    jPlclFQUKV3OMvq77bfYvg8EJORz32nnDDmWS7SUjoOtemwutBlMeWbaKk25aMp3
    5JNMXuV6apeMJ9Dd8GU7qBUqlIvVK31/96XPvzmnYzWZPqRVwO2HPcRFG3YcJmkg
    JmZQyexJvCQ3wFNxiYUm+y0CgYBXQSMhFnCUg4jWbbDcHlnwRT+LnjHrN2arPE3O
    eKLfGL6DotmqmjxFaStaRPv2MXMWgAMUsB8sQzG/WEsSaOBQaloAxJJlFIyhzXyE
    bi1UZXhMD8BzQDu1dxLI/IN4wE6SDykumVuocEfuDxlsWDZxEgJjWD2E/iXK9seG
    yRa+9wKBgEydVz+C1ECLI/dOWb20UC9nGQ+2dMa+3dsmvFwSJJatQv9NGaDUdxmU
    hRVzWgogZ8dZ9oH8IY3U0owNRfO65VGe0sN00sQtMoweEQi0SN0J6FePiVCnl7pf
    lvYBaemLrW2YI2B7zk5fTm6ng9BW/B1KfrH9Vm5wLQBchAN8Pjbu
    ——END RSA PRIVATE KEY——

    Держите ключ в секрете! Это значит, защитите его с помощью очень ограниченных разрешений (600) и никому не разглашайте.

    Его напарник — публичный ключ — выглядит примерно так:

    ——BEGIN PUBLIC KEY——
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQbKbSSs2ik
    6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5
    e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+H
    fBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTIN
    WniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBC
    eVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQg
    NQIDAQAB
    ——END PUBLIC KEY——

    Запрос на получение сертификата выглядит примерно так:

    ——BEGIN CERTIFICATE REQUEST——
    MIICzjCCAbYCAQAwgYgxFDASBgNVBAMMC2V4YW1wbGUuY29tMQswCQYDVQQLDAJJ
    VDEPMA0GA1UECAwGTG9uZG9uMRIwEAYDVQQKDAlBQ01FIEluYy4xIDAeBgkqhkiG
    9w0BCQEWEWFkbWluQGV4YW1wbGUuY29tMQswCQYDVQQGEwJHQjEPMA0GA1UEBwwG
    TG9uZG9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQb
    KbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3
    OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYO
    cfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wm
    wZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZ
    EUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2
    tjtp+LQgNQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAGIQVhXfuWdINNfceNPm
    CkAGv4yzpx88L34bhO1Dw4PYWnoS2f7ItuQA5zNk9EJhjkwK8gYspK7mPkvHDbFa
    Um7lPSWsm3gjd3pU7dIaHxQ+0AW9lOw5ukiBlO4t3qgt+jTVZ3EhMbR0jDSyjTrY
    kTgfuqQrGOQSmLb5XviEtCcN0rseWib3fKIl8DM69JiA2AALxyk7DCkS1BqLNChT
    pnbgvtlUhc4yFXNCtwPGskXIvLsCn2LRy+qdsPM776kDLgD36hK0Wu14Lpsoa/p+
    ZRuwKqTjdaV23o2aUMULyCRuITlghEEkRdJsaXadHXtNd5I5vDJOAAt46PIXcyEZ
    aQY=
    ——END CERTIFICATE REQUEST——

    Этот конкретный CSR содержит публичный ключ сервера и информацию о компании ACME Inc., которая находится в Лондоне, Великобритания, и владеет доменом example.com .

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

    ——BEGIN CERTIFICATE——
    MIIDjjCCAnYCCQCJdR6v1+W5RzANBgkqhkiG9w0BAQUFADCBiDEUMBIGA1UEAwwL
    ZXhhbXBsZS5jb20xCzAJBgNVBAsMAklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNV
    BAoMCUFDTUUgSW5jLjEgMB4GCSqGSIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20x
    CzAJBgNVBAYTAkdCMQ8wDQYDVQQHDAZMb25kb24wHhcNMTYwNDE5MTAzMjI1WhcN
    MTcwNDE5MTAzMjI1WjCBiDEUMBIGA1UEAwwLZXhhbXBsZS5jb20xCzAJBgNVBAsM
    AklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNVBAoMCUFDTUUgSW5jLjEgMB4GCSqG
    SIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20xCzAJBgNVBAYTAkdCMQ8wDQYDVQQH
    DAZMb25kb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCb7Tfo7Y+V
    RBsptJKzaKTo7pNjLr5mxqzmgCTcaKgYuXVFb02LyRqCp2cPr0S3b2bW+Xk4g+wG
    hbc5ZvVoFbl7cnTH2mtcjVb9+m+4/02ascFQ3gRLXtWWJGl9Ufdod88Lysqm/ca8
    dg5x86Yw34d8FmVR4okqzpzlaZJV2dkHRHhQBa5DfRocQFWq2uGAepgMGiRV7T8f
    jCbBkQhBMg1aeII4VHlSmEl/mc/yWMZuY/E1Od9v+IdL9yGNyMXtMYwbfp7sQGhC
    KNkRRCzkgEJ5V586cUsrmMvH4EL/9f4U3MHIOKVO36Xbwj/dk3W6OFqTvdgVtaOM
    tHa2O2n4tCA1AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBABwwkE7wX5gmZMRYugSS
    7peSx83Oac1ikLnUDMMOU8WmqxaLTTZQeuoq5W23xWQWgcTtfjP9vfV50jFzXwat
    5Ch3OQUS53d06hX5EiVrmTyDgybPVlfbq5147MBEC0ePGxG6uV+Ed+oUYX4OM/bB
    XiFa4z7eamG+Md2d/A1cB54R3LH6vECLuyJrF0+sCGJJAGumJGhjcOdpvUVt5gvD
    FIgT9B04VJnaBatEgWbn9x50EP4j41PNFGx/A0CCLgbTs8kZCdhE4QFMxU9T+T9t
    rXgaspIi7RA4xkSE7x7B8NbvSlgP79/qUe80Z7d8Oolva6dTZduByr0CejdfhLhi
    mNU=
    ——END CERTIFICATE——

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

    Мы проиллюстрируем этот процесс реальными шагами, которые нужно сделать в cPanel, Linux, FreeBSD и Windows. Это универсальный процесс, подходящий для всех типов сертификатов. Если вы хотите получить бесплатный сертификат DV, то следуйте другим процедурам, описанным в разделах Let’s Encrypt и Cloudflare.

    Шаг 1. Создать секретный ключ и запрос на получение сертификата

    В следующих примерах мы будем использовать 2048-битные сертификаты RSA, по причине их большей совместимости. Если ваш провайдер, у которого установлен сервер, поддерживает ECC (например, если вы не пользуетесь услугами Heroku или AWS), то можете предпочесть использовать ECC.

    cPanel

    1. Войдите в cPanel своего хоста.
    2. Прокрутите вниз до раздела “Security” и нажмите “SSL/TLS”.

    Раздел “Security” в cPanel (см. большую версию)

    Теперь вы в разделе “SSL/TLS Manager”. Нажмите “Private Keys (KEY)” для создания нового секретного ключа.

    “SSL/TLS Manager” в cPanel (см. большую версию)

    Управление секретным ключом (“Private Key”) в cPanel (см. большую версию)

    Подтверждение секретного ключа в cPanel (см. большую версию)

    Раздел “Private Keys” в cPanel с новым сгенерированным ключом (см. большую версию)

    Раздел “SSL/TLS Manager” в cPanel (см. большую версию)

    Форма “Create New Certificate Signing Request” в cPanel (см. большую версию)

    Подтверждение создания CSR в cPanel (см. большую версию)

    Раздел “Certificate Signing Request” в cPanel с новым сгенерированным CSR (см. большую версию)

    Linux, FreeBSD

    Убедитесь, что установлен OpenSSL. Вы можете проверить это:

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

    • Debian, Ubuntu и клоны
      sudo apt-get install openssl
    • Red Hat, CentOS и клоны
      sudo yum install openssl
    • FreeBSD
      make -C /usr/ports/security/openssl install clean

    openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr

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

    Generating a 2048 bit RSA private key
    . +++
    . +++
    writing new private key to ‘example.com.key’
    ——
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter ‘.’, the field will be left blank.

    Правильно ответьте на все вопросы (они будут открыты для просмотра в вашем подписанном сертификате!), особенное внимание уделите разделу “Common Name” (например, сервер FQDN или ВАШЕ имя), который должен в точности совпадать с доменным именем, для которого вы запрашиваете сертификат HTTPS. Включите туда только домен верхнего уровня ( example.com ); центр сертификации обычно сам добавляет поддомен www (то есть www.example.com ):

    Country Name (2 letter code) [AU]:GB
    State or Province Name (full name) [Some-State]:London
    Locality Name (eg, city) []:London
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:ACME Inc.
    Organizational Unit Name (eg, section) []:IT
    Common Name (e.g. server FQDN or YOUR name) []:example.com
    Email Address []:admin@example.com

    Please enter the following ‘extra’ attributes
    to be sent with your certificate request
    A challenge password []:
    An optional company name []:

    Internet Information Server под Windows

      Откройте “Start” → “Administrative Tools” → “Internet Information Services (IIS) Manager”. Нажмите на имя сервера. Двойным щелчком откройте “Server Certificates” в средней колонке:

    Откройте “Internet Information Services (IIS) Manager”. Двойным щелчком откройте “Server Certificates”. (см. большую версию)

    Нажмите “Create Certificate Request” в правой колонке. (см. большую версию)

    Введите информацию о своей организации. (см. большую версию)

    Установите “Bit length” на 2048 . (см. большую версию)

    Выберите место для сохранения сгенерированного CSR и нажмите “Finish”. (см. большую версию)

    Шаг 2. Приобретение сертификата HTTPS

    Чтобы получить сертификат для вашего веб-сайта, сначала купите кредит на сертификат HTTPS выбранного типа (DV, OV, EV, один сайт, несколько сайтов, поддомены — см. выше) у продавца сертификатов. По окончании процесса вам нужно будет отправить запрос на получение сертификата, который потратит купленный кредит для выбранного домена. Вас попросят предоставить (то есть вставить в поле для загрузки) весь текст CSR, включая строки ——BEGIN CERTIFICATE REQUEST—— и ——END CERTIFICATE REQUEST—— . Если вам нужен сертификат EV или OV, то нужно будет указать юридическое лицо, для которого вы запрашиваете сертификат. У вас также могут попросить дополнительные документы, подтверждающие тот факт, что вы представляете эту компанию. Затем регистратор сертификатов проверит ваш запрос (и все сопутствующие документы) и выдаст подписанный сертификат HTTPS.

    Получение сертификата HTTPS

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

    1. Найти продавца сертификатов HTTPS.
    2. Выбрать тип сертификата (DV, OV, EV, один сайт, несколько сайтов, поддомены) и добавить его в корзину. Выбрать предпочитаемый метод оплаты и совершить платёж.
    3. Активировать новый сертификат HTTPS для своего домена. Вы можете или вставить в форму, или загрузить файл с запросом на подпись сертификата. Система извлечёт информацию для сертификата из CSR.
    4. Вас попросят выбрать метод «утверждения контроля домена» (“Domain Control Validation”, DCV) — либо по электронной почте, либо загрузкой файла HTML (на основе HTML), либо путём добавления записи TXT к своему файлу доменной зоны (на основе DNS). Следуйте инструкциям по указанному методу DCV для утверждения.
    5. Подождите несколько минут, пока осуществляется утверждение и готовится сертификат HTTPS. Скачайте сертификат.

    Самоподписанные сертификаты

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

    Например, выше опубликован самоподписанный сертификат — вы можете использовать его для домена example.com , и он будет работать в течение своего срока действия.

    Можно создать самоподписанный сертификат на любой платформе, где есть OpenSSL.

    openssl x509 -signkey example.com.key -in example.com.csr -req -days 365 -out example.com.crt

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

    Шаг 3. Установка сертификата HTTPS для своего веб-сайта

    cPanel

      Вернитесь в “SSL/TLS Manager”. Нажмите “Certificates (CRT)” для импортирования нового сертификата.

    Раздел “SSL/TLS Manager” в cPanel (см. большую версию)

    Импорт нового сертификата HTTPS в cPanel (см. большую версию)

    Просмотр содержимого и подтверждение сертификата HTTPS в cPanel (см. большую версию)

    Подтверждение сертификата HTTPS в cPanel (см. большую версию)

    Страница “Certificates” в cPanel с новым сертификатом HTTPS. (см. большую версию)

    Раздел “SSL/TLS Manager” в cPanel. (см. большую версию)

    Форма “Install an SSL Website” в cPanel. (см. большую версию)

    Если файл .htaccess уже существует, то вставьте только строчки RewriteCond и RewriteRule сразу после существующей директивы RewriteEngine On .

    Linux, FreeBSD

    Разместите в соответствующих директориях сгенерированный секретный ключ ( example.com.key ), запрос на подпись сертификата ( example.com.csr ) и действительный сертификат HTTPS ( example.com.crt ):

    • Debian, Ubuntu и клоны, FreeBSD
      cp example.com.crt /etc/ssl/certs/
      cp example.com.key /etc/ssl/private/
      cp example.com.csr /etc/ssl/private/
    • Red Hat, CentOS и клоны
      cp example.com.crt /etc/pki/tls/certs/
      cp example.com.key /etc/pki/tls/private/
      cp example.com.csr /etc/pki/tls/private/
      restorecon -RvF /etc/pki
    • Debian, Ubuntu и клоны
      chown -R root. /etc/ssl/certs /etc/ssl/private
      chmod -R 0600 /etc/ssl/certs /etc/ssl/private
    • Red Hat, CentOS и клоны
      chown -R root. /etc/pki/tls/certs /etc/pki/tls/private
      chmod -R 0600 /etc/pki/tls/certs /etc/pki/tls/private
    • FreeBSD
      chown -R root:wheel /etc/ssl/certs /etc/ssl/private
      chmod -R 0600 /etc/ssl/certs /etc/ssl/private

    Apache

    Чтобы активировать HTTPS на своём сайте, нужно сделать следующее:

    • убедиться, что на сервере установлен mod_ssl,
    • загрузить на сервер файл полученного сертификата HTTPS ( .crt ),
    • отредактировать файлы конфигурации сервера Apache.

    apache2 -M | grep ssl
    или
    httpd -M | grep ssl

    Если mod_ssl установлен, то вы получите такой ответ…

    ssl_module (shared)
    Syntax OK

    … или нечто похожее.

    Если он не установлен или не работает, то попробуйте это:

    • Debian, Ubuntu и клоны
      sudo a2enmod ssl
      sudo service apache2 restart
    • Red Hat, CentOS и клоны
      sudo yum install mod_ssl
      sudo service httpd restart
    • FreeBSD
      make -C /usr/ports/www/apache24 config install clean
      apachectl restart
    • Debian, Ubuntu
      /etc/apache2/apache2.conf
    • Red Hat, CentOS
      /etc/httpd/conf/httpd.conf
    • FreeBSD
      /usr/local/etc/apache2x/httpd.conf
    Listen 80 Listen 443 ServerName example.com ServerAlias www.example.com Redirect 301 / https://www.example.com/ ServerName example.com Redirect 301 / https://www.example.com/ ServerName www.example.com . SSLEngine on SSLCertificateFile/path/to/signed_certificate_followed_by_intermediate_certs SSLCertificateKeyFile /path/to/private/key # Uncomment the following directive when using client certificate authentication #SSLCACertificateFile /path/to/ca_certs_for_client_authentication # HSTS (mod_headers is required) (15768000 seconds = 6 months) Header always set Strict-Transport-Security "max-age=15768000" . # intermediate configuration, tweak to your needs SSLProtocol all -SSLv3 SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS SSLHonorCipherOrder on SSLCompression off SSLSessionTickets off # OCSP Stapling, only in httpd 2.3.3 and later SSLUseStapling on SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb:/var/run/ocsp(128000)

    Эта конфигурация была сгенерирована с помощью упомянутого ранее Mozilla SSL Configuration Generator. С его помощью проверьте актуальность конфигурации. Отредактируйте правильные пути для сертификата и секретного ключа. Показанная здесь конфигурация сгенерирована с промежуточными настройками — прочитайте об ограничениях и конфигурациях браузера для каждой настройки, прежде чем выбрать наиболее подходящую для себя.

    В коде были сделаны некоторые изменения, чтобы обрабатывать редиректы с HTTP на HTTPS, а также с не- www на домен с www (полезно для задач SEO).

    Nginx

    Отредактируйте файл конфигурации nginx ( nginx.conf ):

    • Debian, Ubuntu, Red Hat, CentOS
      /etc/nginx/nginx.conf
    • FreeBSD
      /usr/local/etc/nginx/nginx.conf

    server < listen 80 default_server; listen [::]:80 default_server; # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response. return 301 https://$host$request_uri; >server < listen 443 ssl http2; listen [::]:443 ssl http2; # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate ssl_certificate /path/to/signed_cert_plus_intermediates; ssl_certificate_key /path/to/private_key; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits ssl_dhparam /path/to/dhparam.pem; # intermediate configuration. tweak to your needs. ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS'; ssl_prefer_server_ciphers on; # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months) add_header Strict-Transport-Security max-age=15768000; # OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; ## verify chain of trust of OCSP response using Root CA and Intermediate certs ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates; resolver ; . >

    Генератор автоматически генерирует код для обработки редиректов с HTTP на HTTPS и изначально активирует поддержку HTTP/2!

    Internet Information Server под Windows

      Откройте “Start” → “Administrative Tools” → “Internet Information Services (IIS) Manager”. Нажмите на название сервера. Двойным щелчком откройте “Server Certificates” в средней колонке.

    Откройте “Internet Information Services (IIS) Manager”. Двойным щелчком откройте “Server Certificates”. (см. большую версию)

    Нажмите “Complete Certificate Request” в правой колонке. (см. большую версию)

    Выберите файл подписанного сертификата. (см. большую версию)

    Вы должны увидеть сертификат на вкладке “Server Certificates”. (см. большую версию)

    Выберите веб-сайт и нажмите “Bindings”. (см. большую версию)

    Нажмите кнопку “Add”. (см. большую версию)

    • “Type”: “https”
    • “IP address”: “All Unassigned”
    • “Port”: “443”

    Выберите “HTTPS” и укажите установленный сертификат HTTPS. (см. большую версию)

    Теперь для вашего веб-сайта должны быть установлены HTTP и HTTPS. (см. большую версию)

    Предупреждения о смешанном содержимом

    Возле адресной строки вы можете увидеть предупреждающий знак и сообщение вроде «Соединение небезопасно! Части страницы не защищены (такие как изображения)». Это не означает, что вы неправильно установили сертификат: просто убедитесь, что ссылки на все ресурсы (изображения, таблицы стилей, скрипты и др.), как локальные так и с удалённых серверов, не начинаются с http:// . Все ресурсы должны указывать на адреса относительно рута ( /images/image.png , /styles/style.css и т. д.) или относительно текущего документа ( ../images/image.png ), или это должны быть полные URL, которые начинаются с https:// , такие как .

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

    Тестирование сервера

    После того, как ваш сервер сконфигурирован и начал работать по HTTPS, я настоятельно рекомендую проверить безопасность конфигурации при помощи Qualys SSL Server Test. Он сканирует ваш веб-сайт, в том числе выполняет всестороннюю оценку конфигурации, выявляет возможные слабости и даёт рекомендации. Следуйте его советам для ещё большего улучшения конфигурации защиты сервера.

    Продление

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

    Отзыв

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

    Let’s Encrypt

    Let’s Encrypt — это бесплатный, автоматизированный и открытый центр сертификации (CA), который работает для общественного блага. Сервис Let’s Encrypt предоставляется Internet Security Research Group (ISRG).

    Ключевые принципы Let’s Encrypt:

    • Бесплатность
      Любой владелец доменного имени может использовать Let’s Encrypt для получения бесплатного доверенного сертификата.
    • Автоматизация
      Программное обеспечение на веб-сервере может взаимодействовать с Let’s Encrypt для безболезненного получения сертификата, безопасной конфигурации его и автоматического продления.
    • Безопасность
      Let’s Encrypt служит платформой для лучших методов продвинутой защиты TLS, как на стороне центра сертификации, так и помогая операторам веб-сайтов правильно обезопасить свои сервера.
    • Прозрачность
      Все выданные или отозванные сертификаты будут публично записаны и доступны для просмотра кем угодно.
    • Открытость
      Протокол автоматической выдачи и продления будет опубликован как открытый стандарт, который могут использовать другие.
    • Сотрудничество
      Во многом как протоколы, лежащие в основе Интернета, Let’s Encrypt — это совместный проект для блага сообщества, неподконтрольный какой-либо организации.

    Чтобы воспользоваться преимуществами Let’s Encrypt, нужно правильно настроить свой аккаунт на хостинге или сервере. Let’s Encrypt выдаёт краткосрочные сертификаты, которые следует регулярно обновлять, чтобы веб-сайт HTTPS оставался работоспособным.

    Как это работает

    Есть некоторые существенные отличия в работе Let’s Encrypt и других центров сертификации. В соответствии с тремя первыми пунктами, перечисленными выше, вот эти отличия:

    • Бесплатность
      Сертификаты HTTPS от Let’s Encrypt абсолютно бесплатны на весь срок жизни вашего сайта.
    • Автоматизация
      Сертификаты HTTPS от Let’s Encrypt действуют 90 дней, в отличие от обычных сертификатов HTTPS, которые действуют один год. Людей подталкивают к автоматизации обновления своих сертификатов; например, администратор сервера может запустить специализированный программный сервис (или периодически вызывать программу из cron) для управления первоначальной проверкой домена и последующими продлениями для всех своих доменов — в стиле «установил и забыл».
    • Безопасность
      Сертификаты HTTPS от Let’s Encrypt выдаются без компромиссов относительно безопасности, что ведёт к некоторым несовместимостям со старыми и более экзотическими платформами. Посмотрите страницу совместимости для проверки, не попадаете ли вы в отсекаемые платформы.

    Ограничения

    Let’s Encrypt выдаёт только сертификаты DV. Сертификаты OV и EV не поддерживаются, и в данный момент нет планов их поддержки. Выдаются сертификаты на один или несколько доменов, но в данный момент нет сертификатов с поддоменами (подстановочными знаками). Для получения дополнительной информации см. Let’s Encrypt FAQ.

    Автоматический режим работы Let’s Encrypt навязывает некоторые ограничения на использование, чтобы защитить инфраструктуру от умышленных и неумышленных злоупотреблений. Лимиты на интенсивность использования достаточно высоки, чтобы помешать обычным пользователям даже с сотнями доменов в распоряжении. Но если вы управляете сертификатами HTTPS в очень больших масштабах, то стоит ознакомиться с этими лимитами.

    Более старые и экзотические клиенты (до Windows XP SP3) не поддерживаются. Подробности см. на странице совместимости.

    Использование сертификатов HTTPS от Let’s Encrypt на практике

    cPanel

    1. Зайдите в cPanel своего хоста.
    2. Прокрутите вниз до раздела “Security” и нажмите “Let’s Encrypt for cPanel”.

    Раздел “Security” в cPanel. (см. большую версию)

    Проверьте оба доменных имени и нажмите “Issue Multiple”. (см. большую версию)

    Нажмите “Issue” и подождите минуту или две. (см. большую версию)

    Если процесс завершён удачно, вы увидите сообщение с подтверждением. (см. большую версию)

    Ваши домены с сертификатами Let’s Encrypt. (см. большую версию)

    Linux, FreeBSD, другие

    Самый простой способ установить сертификат Let’s Encrypt на своём сервере — использовать Certbot. Просто укажите свой веб-сайт и операционную систему — и следуйте инструкциям.

    Certbot для Let’s Encrypt (см. большую версию)

    Internet Information Server под Windows

    В данный момент нет официального клиента для IIS под Windows, но существует пара обходных путей.

    Несколько проектов ставят целью создание нативного Windows-клиента для Let’s Encrypt:

    • ACMESharp (PowerShell) — первая попытка написать Windows-клиент.
    • letsencrypt-win-simple (для командной строки) как будто самый простой в использовании.
    • Certify предоставляет GUI поверх ACMESharp, но всё ещё находится в альфа-версии.

    Cloudflare

    Cloudflare — сервис, который предоставляет сеть доставки контента (CDN), услуги обеспечения безопасности для веб-сайтов и защиты от DDoS-атак. Он предоставляет бесплатные сертификаты HTTPS на всех тарифных планах, включая бесплатный тариф — это коллективный сертификат DV Cloudflare Universal SSL. Чтобы получить уникальный сертификат HTTPS, нужно перейти на бизнес-тариф.

    Для получения сертификата просто создайте аккаунт, поднимите веб-сайт и зайдите в раздел “Crypto”.

    CertSimple

    CertSimple поставляет только сертификаты EV. Он совершил такую же революцию на рынке сертификатов EV HTTPS, какую Let’s Encrypt совершил на рынке сертификатов DV HTTPS, обеспечивая более быстрый и простой процесс проверки организации, который обычно медленный и обременительный. Вот его преимущества:

    • Упрощённая процедура подачи заявлений
      Не требуется установка программного обеспечения или ответы на вопросы в командной строке. Проверка в реальном времени, а большинство деталей проверяются до оплаты.
    • Быстрая проверка
      В среднем, три часа, по сравнению со средними по отрасли 7-10 сутками.
    • Бесплатный перевыпуск на протяжении всего срока действия сертификата
      Легко можно добавить позже доменные имена или восстановить потерянный секретный ключ.

    Несколько веб-сайтов HTTPS на одном IP-адресе

    Из-за сути процесса рукопожатия виртуальные хосты на одном IP-адресе представляют собой проблему для TLS. Виртуальные хосты работоспособны благодаря тому, что клиент включает доменное имя в заголовок запроса HTTP, но при использовании HTTPS рукопожатие TLS происходит до того, как отправляются первые запросы HTTP — нужно установить и наладить работу безопасного канала, прежде чем отправлять какой-либо открытый текст по HTTP, в том числе заголовки. Так что перед соединением с клиентом сервер не знает, какой сертификат предъявить, поэтому он показывает первый сертификат из своего файла конфигурации. И конечно, этот сертификат действителен только для первого сайта TLS из списка.

    Есть несколько способов обойти проблему: либо получить уникальные IP-адреса для каждого домена с TLS, либо зарегистрировать все домены на один сертификат. Оба способа не слишком хороши на практике — адресное пространство IPv4 уже исчерпано, а регистрация всех сайтов на один большой сертификат HTTPS означает, что при добавлении нового сайта на сервер вам придётся перевыпускать весь сертификат на многочисленные домены.

    Для устранения этого ограничения было разработано расширение к протоколу TLS под названием Server Name Indication (SNI). Его должны поддерживать и сервер, и клиент. И хотя поддержка SNI сегодня широко распространена, она всё-таки не гарантирована на 100%, если для вас важна гарантия совместимости со всеми возможными клиентами.

    Подробности о запуске SNI под Apache, nginx и IIS (8+) см. в соответствующей документации.

    Полезные ресурсы

    • Mozilla SSL Configuration Generator
    • Серверный тест SSL, Qualys
    • Безопасность TLS на стороне сервера, вики Mozilla
    • Лучшие практики внедрения SSL и TLS, SSL Labs
    • Документация, Qualys SSL Labs
    • Скрипт на PHP для поиска и замены в БД, Interconnect IT. Для замены всех упоминаний HTTP на HTTPS (ссылки, изображения и др.) в базе данных WordPress.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *