Nginx как подключить ssl

Настройка 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 попытается использовать секретный ключ с первым сертификатом из связки вместо сертификата сервера.

В этом примере субъект (“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-адресе:

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

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

Лучше поместить сведения о файле сертификата с несколькими именами и файле с его секретным ключом на уровне конфигурации 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 выдаёт предупреждение:

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

Источник

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

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

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

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

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

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

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

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

Для получения сертификата от правильного центра, необходимо за него заплатить или получить бесплатно от 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 файла:

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

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

systemctl restart nginx

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

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

Источник

Как настроить SSL-сертификат на Nginx

В статье мы рассмотрим, как установить SSL-сертификат на веб-сервер Nginx.

Перед установкой SSL убедитесь, что вы его заказали. Затем перейдите в Личный кабинет, кликните по строке нужного SSL-сертификата и убедитесь, что у услуги статус «Активна»:

Как установить SSL-сертификат на Nginx

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

Также вы можете использовать для установки сертификат, купленный в сторонней компании.

Рассмотрим, как выполняется установка и настройка Nginx SSL:

Объедините три сертификата (сам SSL-сертификат, корневой и промежуточный сертификаты) в один файл. Для этого создайте на ПК новый текстовый документ с именем your_domain.crt (your_domain — доменное имя сайта, который вы хотите защитить). Создать его можно при помощи блокнота или другого текстового редактора. Поочередно скопируйте и вставьте в созданный документ каждый сертификат. После вставки всех сертификатов файл должен иметь вид:

Обратите внимание: один сертификат идёт следом за другим, без пустых строк.

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

your_domain.com — домен сайта,

/etc/ssl/your_domain.crt — путь до созданного файла с тремя сертификатами,

/etc/ssl/your_domain.key — путь до файла с приватным ключом.

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

Если вы хотите, чтобы сайт работал не только по защищённому соединению (https://), но и по незащищенному (http://), то нужно создать единый HTTP/HTTPS сервер. Для этого в конфигурационном файле Nginx необходимо иметь две секции server<> для каждого типа соединения.

Добавьте в секцию server<>, которую вы создали на шаге 4, следующую строку:

Также вы можете дополнительно оптимизировать работу Nginx HTTPS-сервера. SSL-операции задействуют дополнительные ресурсы сервера. Чтобы снизить количество операций, можно повторно использовать параметры SSL-сессий. Они хранятся в кеше SSL-сессий. Можно задать тип кеша (в примере это shared-кеш, разделяемый между всеми рабочими процессами) и его размер в байтах (в 1 Мб кеша помещается около 4000 сессий) с помощью директивы ssl_session_cache. Также можно увеличить таймаут кеша (время, в течение которого клиент повторно использует параметры сессии) директивой ssl_session_timeout: по умолчанию он равен 5 минутам. Можно настроить время работы одного keepalive-соединения с помощью директивы keepalive_timeout.

Добавьте в конфигурационном файле в секции server<> строки:

Вы можете указать протоколы SSL, которые поддерживает сервер:

Источник