Как настроить https для nginx

Правильная настройка SSL в NGINX

В данной инструкции разберем принцип правильной настройки поддержки https в веб-сервере NGINX, которая пройдет проверку безопасности с присвоением максимальной категории. Тестировать конфигурацию мы будем с помощью сервиса https://www.ssllabs.com/ssltest/ — наша задача получить категорию А:

Статья не рассчитана на новичков — вы должны понимать общие принципы настройки https в NGINX. Команды, приведенные в данном руководстве выполняются на системе Linux. Для Windows принцип настройки остается таким же, за исключением конкретных команд и путей до конфигурационных файлов.

Для достижения результата мы рассмотрим:

1. Правильный сертификат

Под этим подразумевается выполнение двух условий:

1. Сертификат должен быть выпущен доверенным центром.
2. Сертификат должен быть выдан для домена, к которому идет подключение.

Доверенный центр

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

Для получения сертификата от правильного центра, необходимо за него заплатить или получить бесплатно от Let’s Encrypt. Купить сертификат можно у большинства хостеров или регистраторов доменных имен. Для получения бесплатного сертификата можно воспользоваться инструкцией Получение бесплатного SSL сертификата Let’s Encrypt.

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

Сертификат для домена

Заказывая сертификат, мы обязательно указываем, для какого доменного имени его будем использовать. Это обязательное требование. Например, если мы хотим настроить SSL-подключение к узлу security.dmosk.ru, то необходимо указывать именно это имя при заказе ключа безопасности. В противном случае, браузер будет выдавать нам ошибку, что сертификат выдан для другого узла.

Также мы можем заказать сертификат типа wildcard — он применим к домену и все его поддоменам. Например, в нашем случае мы можем заказать ключ для *.dmosk.ru — он будет применять для любого доменного имени 3-го уровня с корнем dmosk.ru.

2. Использование всей цепочки сертификатов

Применяя сертификат в NGINX, необходимо загрузить не только сертификат для домена, но и для всех центров сертификации — как основного, так и промежуточных. В противном случае, мы получим ошибку This server’s certificate chain is incomplete. Grade capped to B:

В случае покупки сертификата, нам отправляют все ключи в отдельных файлах. Цепочка сертификатов, как правило, идет в файле chain. Мы должны скопировать последовательность в данном файле и добавить ее к содержимому в файле с сертификатом домена — получиться файл, содержащий как последовательность для домена, так и всех центров. Назвать его можно fullchain.pem.

В случае получение бесплатного сертификата от Let’s Encrypt, мы получаем 4 файла, один из которых называется fullchain.pem — именно он и содержит все необходимые последовательности.

И так, при настройке виртуального домена в NGINX, необходимо указать путь до файла, содержащего в себе все ключи, например:

server <
listen 443;
server_name security.dmosk.ru;
ssl on;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;

* в данном примере мы настраиваем NGINX для домена security.dmosk.ru; обратите внимание, что мы указали путь до файла fullchain.pem, в котором должны находиться последовательности, как для домена, так и центров сертификации.

Не забываем перезапустить nginx:

systemctl restart nginx

3. Отключение устаревших протоколов

В случае, если наш веб-сервер поддерживает подключение с использованием устаревших протоколов безопасности, например, TLS 1.0, мы получим ошибку This server supports TLS 1.0 and TLS 1.1:

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

Внутри раздела http добавим:

* в данном примере мы указали, что разрешены подключения только по TLS версии 1.2.

Не забываем перезапустить nginx:

systemctl restart nginx

4. Задаем приоритет для серверных шифров

Нам необходимо указать, чтобы при использовании протокола TLS серверные шифры были приоритетнее, чем клиентские. В противном случае мы увидим ошибку This server does not support Forward Secrecy with the reference browsers:

Задать настройку можно в разделе http основного конфигурационного файла:

http <
.
ssl_prefer_server_ciphers on;
..
>

Не забываем перезапустить nginx:

systemctl restart nginx

5. Настройка более стойкого ключа Диффи-Хилмана

Для шифрования сессий NGINX использует DH-шифры. Если последовательность не достаточно стойкая (ниже 2048 бит), мы увидим ошибку This server supports weak Diffie-Hellman (DH) key exchange parameters:

Чтобы исправить ошибку, генерируем стойкую последовательность для Diffie-Hellman файла:

openssl dhparam -out /etc/nginx/dh2048.pem 2048

В настройках NGINX (разделе http) добавляем:

Не забываем перезапустить nginx:

systemctl restart nginx

(Опционально) Перенаправление с 80 на 443

Стоит добавить настройку для перенаправления запроса с http на https. Для этого в настройке виртуального домена в NGINX добавим:

Источник

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

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

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

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

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

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

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

Цепочки SSL-сертификатов

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

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

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

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

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

При тестировании конфигураций с SNI необходимо указывать опцию -servername , так как openssl по умолчанию не использует SNI.

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

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

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

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

До версии 0.7.14 SSL нельзя было включить выборочно для отдельных слущающих сокетов, как показано выше. SSL можно было включить только для всего сервера целиком, с помощью директивы ssl, что не позволяло настроить единый HTTP/HTTPS сервер. Для решения этой задачи был добавлен параметр ssl директивы listen. Поэтому использование директивы ssl в современных версиях не рекомендуется.

Выбор HTTPS-сервера по имени

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

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

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

SSL-сертификат с несколькими именами

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

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

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

Указание имени сервера

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

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

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

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

Совместимость

• Статус поддержки SNI отображается по ключу “-V” начиная с версий 0.8.21 и 0.7.62.
• Параметр ssl директивы listen поддерживается начиная с версии 0.7.14. До версии 0.8.21 его можно было указывать только совместно с параметром default .
• SNI поддерживается начиная с версии 0.5.23.
• Разделяемый кэш SSL-сессий поддерживается начиная с версии 0.5.6.

• Версия 1.9.1 и более поздние: протоколами SSL по умолчанию являются TLSv1, TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).
• Версия 0.7.65, 0.8.19 и более поздние: протоколами SSL по умолчанию являются SSLv3, TLSv1, TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).
• Версия 0.7.64, 0.8.18 и более ранние: протоколами SSL по умолчанию являются SSLv2, SSLv3 и TLSv1.

• Версия 1.0.5 и более поздние: шифрами SSL по умолчанию являются “ HIGH:!aNULL:!MD5 ”.
• Версия 0.7.65, 0.8.20 и более поздние: шифрами SSL по умолчанию являются “ HIGH:!ADH:!MD5 ”.
• Версия 0.8.19: шифрами SSL по умолчанию являются “ ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM ”.
• Версия 0.7.64, 0.8.18 и более ранние: шифрами SSL по умолчанию являются
  “ ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP ”.

Источник