Подборки

Что такое протокол HTTPS и как на него перейти

18.11.2017

54107

Содержание

Протокол HTTPS

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

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

В этой статье я пошагово расскажу и покажу как перевести ваш сайт на HTTPS. Я написал подробные инструкции для пользователей разделенных хостингов с cPanel, администраторов Apache и Nginx на Linux и Unix, а также для администраторов IIS на Windows.

Начнем с самого базового.

HTTP Vs. HTTPS Vs. HTTP / 2 Vs. SSL Vs. TLS: что это такое?

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

Hypertext Transfer Protocol (HTTP)

Базовый протокол передачи данных между клиентом и сервером. Он описывает так вещи как запрос и ответ, сессии, кэш, аутентификация и прочее. Работа над ним (и HTML) была начата в 1989 году Тимом Бернерс-Ли (Tim Berners-Lee) и его командой в CERN. Первая официальная версия протокола (HTTP 1.0) была представлена в 1996 году, а чуть позже, в 1997 была выпущена версия 1.1, которой мы пользуемся и сегодня.

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

Зашифрованный канал устанавливается с помощью протокола Transport Layer Security (TLS), который раньше назывался Secure Socket Layer (SSL). Эти сроки, как правило, взаимозаменяемы, ведь SSL 3.0 был заменен TLS 1.0. SSL был протоколом, разработанным Netscape, в то время как TLS — стандарт IEFT. Все версии SSL (1.0, 2.0, 3.0) считаются устаревшими из-за проблем с безопасностью и будут вызывать предупреждения в браузеров. Версии TLS (1.0, 1.1, 1.2) используются и сейчас, а TLS 1.3 находится в разработке.

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

Следующим обновлением протокола HTTP является HTTP / 2, который поддерживает все больше сайтов. Он добавляет новые функции, уменьшает время ожидания и улучшает производительность и безопасность.

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

Предоставляющая HTTPS

Почему все так гоняются за HTTPS, что в нем такого? Его используют по трем причинам:

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

HTTPS защищает коммуникацию между клиентом и сервером от посторонних лиц. Без HTTPS кто-то может запустить точку доступа Wi-Fi и видеть все данные, за ней идут: номера кредитных карточек, и другие важные данные.

Целостность

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

Идентификация

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

Криптография: короткое интро

Конфиденциальность, гарантия целостности и идентификация — ключевые концепты криптографии, а не фича HTTPS. Рассмотрим их.

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

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

И если две стороны хотят общаться с шифрованием, они должны согласовать два аспекта:

Алгоритм шифрования.
С какими параметрами, паролем или правилами (секретом) происходит шифрования.
Существует два вида алгоритмов шифрования:

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

Https-шифрование (encryption) и Обратный процесс - расшифровкой (decryption) — Https-шифрование (encryption) и Обратный процесс — расшифровкой (decryption)

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

Как это работает? Представим, что Алиса и Боб хотят обмениваться какой-либо информацией конфиденциально. Каждый из них имеет пару ключей: частный и публичный. Частные ключи известны только их владельцам, публичные доступны любому.

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

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

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

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

Первая асимметричная часть рукопожатие (handshake) называется обменом ключами (key exchange).

Целостность

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

Были успешно получены все данные?
Не были ли изменены данные (третьей стороной) в процессе обмена?
Чтобы убедиться, что все данные доставлены успешно используют алгоритм message digest. Вычисления кода идентификации сообщений (message authentication code, MAC. Иногда его называют тегом (tag)) — это процесс криптографической хеширования. Требованиями к такого алгоритма является невозможность

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

Идентификация

Как по идентификации? Проблемой приложений с инфраструктурой публичных ключей является то, что обе стороны не могут точно знать кто есть кто, ведь они физически разделены. Для того, чтобы убедиться кем действительно есть другая сторона, существует взаимно доверенное третья сторона — certificate authority (CA). CA выдает сертификаты, подтверждающие, что домен example.com ассоциированный с публичным ключом XXX. В некоторых случаях (сертификаты EV и OV) CA также проверяет принадлежит домен определенной компании. Правдивость этой информации гарантируется (то есть она сертифицирована) certificate authority X, и эта гарантия действительна не ранее даты Y (begins on) и не позднее даты Z (expires on). Вся эта информация хранится в одном документе, называется HTTPS сертификат. Это можно сравнить с государством (которому доверяют все), которая выдает паспорта (сертификаты) людям — все, кто доверяют государству, будут уверены в том, что владелец паспорта является тем, кем представился.

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

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

Https-механизм называется цепочкой доверия

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

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

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

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

1. Валидация сервера- Domain validated (DV)

Самый популярный тип сертификата, он подтверждает, что домен и публичный ключи не подменен. Браузер устанавливает безопасное соединение с сервером и отображает панель с замочком. Кликнув по ней вы увидите надпись «Этот сайт не предоставил информации о владельце», ведь для получения этого сертификата достаточно лишь обладать доменом. DV сертификаты обычно достаточно дешевые (10 USD в год) или вообще бесплатные (см. Let’s Encrypt и Cloudflare ниже).

Extended validation (EV)

EV сертификат гарантирует, что домен принадлежит определенной компании. Это вид сертификата, вызывает наибольшее доверие. Он выдается после проверки CA организации, обладающей доменом. Это проверка:

владения доменом
в государственном реестре: действительно существует такая компания, или
активная она
в независимых бизнес реестрах (Dunn and Bradstreet, Salesforce connect.data.com, Yellow Pages и т.д.)
верификационный телефонный звонок
инспекция всех доменных имен в сертификате

Теперь рядом с замочком отображаться название компании, владеющей доменом, клик по которой покажет детали о компании, например, ее название и адрес. Стоят такие сертификаты от 150 до 300 USD в год.

Organization validated (OV)

Эти сертификаты похожи на EV, они гарантируют, что домен принадлежит организации, но ее название не отображается перед URL. То есть вам нужно соблюсти все правила как и для EV-сертификата, но без его плюсов. Поэтому этот сертификат наименее популярен. Стоит от 40 до 100 USD в год.

2. Количество доменов

Ранее, сертификаты выдавались только для одного домена в CN-поле. Позже было добавлено поле «subject alternative name» (SAN), теперь один сертификат мог работать для нескольких доменов. Сейчас все сертификаты выпускаются по одинаковой технологии, поэтому даже сертификат для одного домена будет поле SAN с этим самым доменом (и его www-версией). Но некоторые компании все еще отдельно продают сертификаты для одного и нескольких доменов.

Один домен

Самый популярный вид сертификата, который покрывает только один домен: example.com и www.example.com

Несколько доменов (UCC / SAN)

Такие типы сертификатов еще называют Unified Communications Certificate (UCC) или Subject Alternative Names (SAN), они могут покрывать сразу несколько доменов (или поддоменов) до определенного лимита. Обычно в цену включена оплата трех-пяти доменов, а остальные можно добавить за дополнительную цену.

Wildcard

Этот тип сертификата покрывает главный домен и все поддомены (* .example.com). Но его ограничением является то, что он покрывает только поддомены основного домена.

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

Вспомним, что для обеспечения HTTPS-шифрование нужно:

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

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

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

И поэтому вам нужно будет сделать несколько решений в конфигурации.

Коды

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

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

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

Очень удобным ресурсом, который поможет настроить HTTPS на сервере есть Mozilla SSL Configuration Generator, позже в этой статье мы воспользуемся им.

Тип ключа

Сертификаты с использованием эллиптической криптографии быстрее и меньше нагружают CPU, чем RSA-сертификаты, играет важную роль на мобильных устройствах. Но некоторые сервисы (на момент написания, 12 июля 2017 года, среди них были Amazon, CloudFront и Heroku) не поддерживают такие сертификаты.

256-битный ECC ключ признано достаточным.

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

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

Процедура получения сертификата

Чтобы получить HTTPS-сертификат нужно выполнить следующее:

Создайте пару из частного и публичного ключа и подготовьте запрос на подписание сертификата (Certificate Signing Request, CSR), включая информацию об организации и публичный ключ.
Обратитесь к CA и сделайте запрос на получение HTTPS-сертификата, основанный на вашем CSR.
Получите подписанный сертификат и установите на своем веб-сервере.

Существует определенный набор файлов, хранящих различные элементы инфраструктуры публичных ключей (public key infrastructure, PKI): частный и публичный ключи, CSR и подписан HTTPS-сертификат. И чтобы все это усложнить, различные стороны используют различные имена и расширения файлов для одних и тех же вещей.

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

Файлы, которые мы будем использовать в примерах:

example.com.key — это PEM-форматированный файл сохраняет частный ключ. Расширение .key не является обязательным, поэтому может и не использоваться. Он должен быть защищенным и доступным только суперпользователя.

example.com.pub — это PEM-форматированный файл сохраняет публичный ключ. Вы даже не нуждаетесь этого файла, ведь вы всегда можете сгенерировать его из частного ключа, как обычно и делают. Но для ясности примеров мы будем его использовать.

example.com.csr — это запрос на подписание запроса. PEM-форматированный файл, хранящий информацию об организации и публичный ключ сервера. Отправляется CA для получения сертификата.

example.com.crt — это PEM-форматированный файл, и нашей сертификатом, который подписан CA. В нем хранится публичный ключ сервера, информация об организации, подпись CA и дату окончания. Расширение .crt не является стандартом, иногда еще используют .cert и .cer.

Имена (и расширения) файлов не является стандартом и могут быть любыми. Я использую такие имена, ведь считаю, что они понятное показывают, что есть что.

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

Храните ваши личные ключи в тайне! Установите им достаточно ограниченные права (600) и не сообщайте посторонним лицам.

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

Запрос на подписание сертификата (CSR) выглядит так:

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

И наконец, HTTPS-сертификат выглядит так:

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

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

Шаг первый: создание частного ключа и запроса на подписание сертификата (CSR)

Мы будем использовать 2048-битный RSA-сертификат, но если ваш сервер-провайдер поддерживает ECC, я рекомендую использовать его.

cPanel

Войдите в вашу cPanel
Проскрольте в секцию «Security» и кликните на «SSL / TLS».

Кликните по «Private Keys (KEY)», чтобы создать новый частный ключ.

Выставьте параметр «Key Size» в «2048-bit» и нажмите «Generate»

Выставьте параметр «Key Size» в «2048-bit» и нажмите «Generate»

Будет сгенерирован новый частный ключ и вы увидите подтверждение.

Будет сгенерирован новый частный ключ и вы увидите подтверждение.

Если вы вернетесь на страницу «Private Keys», то увидите этот ключ в списке.

Вернитесь к странице «SSL / TLS Manager» и кликните по «Certificate Signing Requests (CSR)», чтобы создать CSR.

Вернитесь к странице «SSL / TLS Manager» и кликните по «Certificate Signing Requests (CSR)», чтобы создать CSR.

Теперь выберите ключ, мы только что сгенерировали в соответствующем поле. Заполняйте все поля правильно, ведь эта информация будет видно публично в вашем сертификате. Обратите особое внимание на секцию «Domains», имя домена должно точно совпадать. Когда закончите, нажмите кнопку «Generate».

Новый CSR будет создан, вы увидите подтверждение.

Новый CSR будет создан, вы увидите подтверждение.

Если вы вернетесь на страницу «Certificate Signing Request», то увидите созданный CSR:

Linux, FreeBSD

Убедитесь, что OpenSSL установлен:

openssl version

Если OpenSSL отсутствует, то нужно его установить:

Debian, Ubuntu и подобные

sudo apt-get install openssl

Red Hat, CentOS и подобные

sudo yum install openssl

FreeBSD

make -C /usr/ports/security/openssl install clean

Теперь сгенерировать ключ и CSR мы можем одной командой:

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», в котором нужно указать ваш домен.

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 []:[email protected]

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

Internet Infromation Server (IIS)

Откройте «Start» → «Administrative Tools» → «Internet Information Services (IIS) Manager». Кликните по имени сервера. Сделайте двойной клик по «Server Certificates».

Кликните по «Create Certificate Request» в правой колонке.

Внимательно заполняйте поля, особенно «Common Name», где должно быть указано имя домена. Нажмите «Next».

«Cryptographic Service Provider» оставьте как есть, а «Bit length» установите в 2048. Нажмите «Next».

Выберите куда сохранить готовый CSR и нажмите «Finish».

Шаг второй: получение HTTPS-сертификата

Чтобы получить HTTPS-сертификат, прежде всего, за него нужно заплатить сертификат-провайдера. После этого вам нужно будет прислать ваш CSR, а если вам нужен EV или OV-сертификат, то нужно будет еще приложить дополнительные документы. Регистратор проверит ваш запрос (и дополнительные документы, если есть) и выдаст вам HTTPS-сертификат.

Общая инструкция

Эта процедура может отличаться от одного регистратора к другому, но в общем покупка HTTPS-сертификата выглядит так:

Найдите продавца сертификатов.
Выберите тип сертификата ((DV, OV, EV, single site, multisite, wildcard) и добавьте в корзину. Выберите удобный метод и оплатите покупку.
Включите ваш сертификат, загрузите или скопируйте ваш CSR.
Вас спросят о способе проверки владения доменом (Domain Control Validation, DCV) — через электронную почту, загрузкой HTML-файла или добавлением TXT-записи в вашей доменной зоны. Выбирайте который вам удобнее.
Подождите несколько минут пока проходит валидация и выдается HTTPS-сертификат. Скачайте его.

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

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

Пример сертификата выше является самоподписанным. А создать сертификат самому можно с помощью OpenSSL:

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

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

Шаг третий: установка сертификата

cPanel

Вернитесь на страницу «SSL / TLS Manager». Кликните по «Certificates (CRT)», чтобы импортировать новый сертификат.

Вы будете перемещены на страницу «Paste, Upload or Generate». Загрузите или скопируйте контент файла полученный на прошлом шаге.

Когда вы загрузите сертификат, его содержание будет распознано и данные появятся в соответствующих полях. Нажмите кнопку «Save Certificate».

Сертификат будет сохранен, а вы получите сообщение с подтверждением.

Если вы вернетесь на страницу «Certificates (CRT)», то увидите наш сертификат.

Вернитесь на страницу «SSL / TLS Manager» и кликните по «Install and Manage SSL for your website (HTTPS)», чтобы присвоить новый сертификат существующем веб-сайту.

Теперь необходимо заполнить форму «Install an SSL Website». Кликните по «Browse Certificates» и выберите наш сертификат. Выберите нужный домен с выпадающего списка и проверьте заполненные поля «Certificate» и «Private Key».

Теперь следует проверить все ли хорошо работает: перейдите по адресу https://www.example.com. Если все работает, то вы, наверное, захотите перенаправлять пользователей с HTTP на HTTPS-версию. Для этого создайте файл .htaccess (если вы используете Apache) в вашей корневой директории:

RewriteEngine On

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Если этот файл уже существует, то скопируйте только две последние строчки и вставьте сразу после строки RewriteEngine On.

Linux, FreeBSD

Переместите ваш ключ, CSR и сертификат в соответствующие им места:

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

Владельцем этих файлов должен быть супер-пользователь, а разрешения установлены в 600.

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 установлено на вашем сервере,
загрузить сертификат на сервер,
редактировать конфиги Apache

Начнем с mod_ssl. В зависимости от вашей ОС, должна работать какая-то из этих команд

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

Измените конфиг Apache:

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

    # # Раскомментируйте следующую директиву, если хотите использовать идентификацию
       # клиентского сертификата
    #SSLCACertificateFile  /path/to/ca_certs_for_client_authentication

    # HSTS (потрібне mod_headers) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=15768000"
    ...


# Средняя конфигурация, редактируйте под свои нужды
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, лише в httpd 2.3.3 і новіше
SSLUseStapling                  on
SSLStaplingResponderTimeout     5
SSLStaplingReturnResponderErrors    off
SSLStaplingCache                shmcb:/var/run/ocsp(128000)

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

Nginx

Измените конфиг nginx:

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;

    # # Сертификаты, будут направлены в SERVER HELLO конкатеновани в 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 параметри для DHE ciphersuites, рекомендовано 2048 bits
    ssl_dhparam /path/to/dhparam.pem;

    # средняя конфигурация, редактируйте под свои нужды
    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) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;

    # OCSP Stapling ---
    # Получения OCSP-записей с URL в ssl_certificate и их кэширования
    ssl_stapling on;
    ssl_stapling_verify on;

## проверка цепочки доверия OCSP с использованием Root CA
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
    resolver ;

    ....
}

Эта конфигурация была сгенерирована с помощью Mozilla SSL Configuration Generator. Удостоверьтесь, что вы указали пути к сертификату и частного ключа. Также сюда уже включены перенаправления с HTTP к HTTPS, а также поддерживается HTTP / 2 из коробки.

Internet Infromation Server (IIS)

Кликните по «Complete Certificate Request» в правой колонке.

Выберите полученный от CA файл сертификата. Придумайте для него понятное имя («Friendly name»), чтобы понять что это за сертификат в будущем. Переместите новый сертификат в персональное хранилище (IIS 8 +), кликните «ОК».

Если все сделали хорошо, вы увидите сертификат в «Server Certificates».

«Раскройте» имя сервера. В сайтах выберите тот, которому нужно присвоить сертификат. Кликните по «Bindings» в правой колонке.

Здесь нажмите кнопку «Add».

В этом окне заполните поля следующим образом:
Type: https
IP address: All Unassigned
Port: 443
SSL Certificate: «friendly name» вашего сертификата.
Кликните «ОК».

Теперь ваш сайт работает как через HTTP, так и через HTTPS.

Предупреждение о смешанном контенте http- https

Вы можете получить предупреждение от браузера, контент этой страницы не защищены. Это не значит, что вы установили что-то неправильно, просто скорее всего где-то в коде страницы есть элементы (например, изображения), которые загружаются через HTTP. Адреса всех ресурсов должны быть указаны относительно главной директории (/images/image.png, /styles/style.css), относительно текущего документа (../images/image.png) или с полным URL, в начале которого стоит https: / / (<script src = «https://code.jquery.com/jquery-3.1.0.min.js»> </ script>).

Протестируйте ваш сервер

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

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

Ваш сертификат действует не вечно, а только определенный период. Обычно, это год. Не ждите последнего момента чтобы продолжить сертификат, ваш регистратор посылать вам напоминание как только приблизится дата конца его действия. Я рекомендую оформить новый сертификат при первом таком напоминанию. Эта процедура мало отличается от получения нового сертификата: создание CSR, получение сертификата и его установки. К тому же, сертификат будет валидным сразу после подписания, и до даты прекращения действия прошлого сертификата + один год. То есть, будет время, когда оба сертификата будут работать, а в вас будет время, чтобы проверить работу нового сертификата без заминок в работе вашего сайта.

Аннулирование

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

Let’s Encrypt

Главными принципами нашего сервиса являются:

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

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

Как это работает Let’s Encrypt

Есть три существенных различия между Let’s Encrypt и другими CA.

Доступность
Let’s Encrypt выдает HTTPS-сертификаты совершенно бесплатно.

Автоматизация
Сертификаты от Let’s Encrypt действительны в течение 90-дней, в то время как обычные — год. Таким образом людей поощряют автоматизировать этот процесс с помощью отдельного ПО или скрипта, запускается по крону. Такой себе «сделай и забудь».

Безопасность
Let’s Encrypt не идет на компромиссы когда вопрос касается безопасности, поэтому сертификаты могут не поддерживаться какими старыми или экзотическими платформами. Список поддерживаемых платформ можно посмотреть здесь.

Ограничения

Let’s Encrypt выдает только DV-сертификаты, OV и EV-сертификаты сейчас не поддерживаются, и, на данный момент, нет планов по их внедрению. Поддерживаются также сертификаты для одного или нескольких доменов, но не поддерживаются шаблоны (wildcard). Подробнее описано в FAQ.

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

Также поддерживаются старые клиенты (в частности старше Windows XP SP3). Больше информации на этой странице.

Настройка сервера для использования Let’s Encrypt

cPanel

Войдите в вашу cPanel.
Проскрольте в секцию «Security» и кликните по «Let’s Encrypt for cPanel».

Заметьте оба домена (example.com и www.example.com) и нажмите «Issue Multiple».

Вам будет показано подтверждение. Ваш главный домен (без www) будет отмечено как приоритетное, а www-домен будет занесен в сертификат в поле «Subject Alt Name» (SAN). Нажмите «Issue» для продолжения. Дождитесь и не спешите перезагружать страницу, ведь инициализация может занять некоторое время (минуту или две).

Если все прошло успешно, вы увидите такое сообщение. Нажмите «Go back» и проверить установленные сертификаты.

Вы увидите ваш домен в списке «Your domains with Let’s Encrypt certificates».

Linux, FreeBSD и все такое

Самым простым способом настроить автоматическое получение и установка сертификатов Let’s Encrypt на вашем сервере есть Certbot. Просто выберите ваш веб и ОС из списка и следуйте инструкциям.

Internet Infromation Server (IIS)

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

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

Cloudflare

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

Чтобы воспользоваться этим, создайте аккаунт, настройте сайт и перейдите в секцию «Crypto».

CertSimple

CertSimple выдает только EV-сертификаты, и делает это похожим на Let’s Encrypt способом. И вот в чем его преимущества:

Простой процесс подачи заявки
Не нужно никакого дополнительного софта или вопросов в консоли.

Быстрое время проверки
Обычно проверка занимает около трех часов, в то время как в других CA это занимает 7-10 дней.

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

Подробнее написано здесь.

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

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

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

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

Вы можете узнать как включить SNI для Apache, nginx и IIS (8+).

Спасибо codeguida.com

Протокол HTTPS

HTTP Vs. HTTPS Vs. HTTP / 2 Vs. SSL Vs. TLS: что это такое?

Hypertext Transfer Protocol (HTTP)

Предоставляющая HTTPS

Криптография: короткое интро

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

Шаг первый: создание частного ключа и запроса на подписание сертификата (CSR)

Linux, FreeBSD

Internet Infromation Server (IIS)

Шаг второй: получение HTTPS-сертификата

Шаг третий: установка сертификата

Nginx

Предупреждение о смешанном контенте http- https

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

Как это работает Let’s Encrypt

Настройка сервера для использования Let’s Encrypt

Cloudflare

CertSimple

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

Популярное

Горячее

Выбор редактора

Популярные посты

ПОПУЛЯРНЫЕ КАТЕГОРИИ