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

Это руководство показывает вам, как установить SSL/TLS-сертификат на NGINX. Оно охватывает ту часть, на которой спотыкается большинство пользователей: построение правильной цепочки сертификатов («fullchain»), которую требует NGINX, направление нужных директив на нужные файлы, тестирование конфигурации перед перезагрузкой и добавление корректного редиректа с HTTP на HTTPS, чтобы каждый посетитель попадал на защищённую версию вашего сайта.

Создание кода CSR для NGINX

Если вы уже сгенерировали CSR и у вас на руках есть выданные файлы сертификата, переходите сразу к разделу Установка SSL-сертификата на NGINX.

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

• Сгенерировать CSR автоматически с помощью нашего генератора CSR. Инструмент возвращает как CSR, так и соответствующий закрытый ключ, который вы затем загружаете на сервер.
• Сгенерировать CSR непосредственно на сервере с помощью OpenSSL, следуя нашему руководству о том, как сгенерировать CSR на NGINX. Закрытый ключ остаётся на сервере.

Откройте полученный файл .csr в любом текстовом редакторе; блок текста внутри (включая строки ——BEGIN CERTIFICATE REQUEST—— и ——END CERTIFICATE REQUEST——) — это то, что вы вставляете в форму заявки на SSL при оформлении заказа. Если вы хотите проверить содержимое CSR перед отправкой, вставьте его в наш декодер CSR.

Установка SSL-сертификата на NGINX

После того как удостоверяющий центр выдаст сертификат, вы обычно получите:

• Ваш основной (серверный) сертификат, как правило, файл .crt, названный по имени вашего домена.
• Промежуточные (а иногда и корневые) сертификаты, либо в виде отдельных файлов .crt, либо объединённые в один файл .ca-bundle.
• Закрытый ключ (файл .key), который был сгенерирован вместе с вашим CSR.

NGINX требует, чтобы серверный сертификат и промежуточная цепочка были объединены в один файл («fullchain»), на который указывает директива ssl_certificate; закрытый ключ указывается отдельно директивой ssl_certificate_key. Пропуск цепочки — самая распространённая ошибка при установке: сертификат выглядит нормально в десктопном браузере, но не работает на Android, в API-клиентах и в таких инструментах, как наш SSL Checker.

Шаг 1. Объедините сертификаты в один файл

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

• Ваш основной сертификат для доменного имени.
• Промежуточный сертификат (сертификаты).
• Корневой сертификат (опционально).

Вы можете создать файл fullchain вручную в текстовом редакторе (вставив каждый блок PEM по порядку) или с помощью одной команды cat. Если вы получили отдельные файлы промежуточного и корневого сертификатов, выполните:

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

Если промежуточные и корневой сертификаты уже находятся в одном файле .ca-bundle, выполните:

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

Замените имена файлов на свои. Переместите объединённый файл (и закрытый ключ, если его там ещё нет) в директорию SSL на вашем сервере, например /etc/ssl/ или /etc/nginx/ssl/. Убедитесь, что файл ключа доступен для чтения только root:

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

Шаг 2. Отредактируйте файл конфигурации NGINX

Откройте файл конфигурации NGINX для вашего сайта. На Debian и Ubuntu он находится в /etc/nginx/sites-available/ (с символической ссылкой в sites-enabled/); на RHEL, CentOS, AlmaLinux и Rocky Linux он находится в /etc/nginx/conf.d/. Добавьте или отредактируйте блок server, который слушает порт 443, чтобы он указывал на файл fullchain и закрытый ключ:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

    ssl_session_timeout 1d;
    ssl_session_cache shared:NginxSSL:10m;
    ssl_session_tickets off;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Несколько замечаний о приведённых выше директивах:

• listen 443 ssl; включает TLS на порту 443. Устаревшая директива ssl on; была удалена в NGINX 1.25 и не должна использоваться в современных конфигурациях.
• http2 on; включает HTTP/2 как отдельную директиву (NGINX 1.25.1 и новее). В более старых конфигурациях использовалось listen 443 ssl http2;, что по-прежнему работает, но считается устаревшим.
• ssl_protocols TLSv1.2 TLSv1.3; отключает устаревшие TLS 1.0 и 1.1. Начиная с NGINX 1.27.3, это значение также используется по умолчанию, если директива не указана, но явное указание — более понятный и удобный для аудита вариант.
• Список шифров соответствует профилю «intermediate» от Mozilla и работает с любыми современными клиентами. Если вам нужны только клиенты TLS 1.3, вы можете полностью убрать ssl_ciphers.

Шаг 3. Перенаправление с HTTP на HTTPS

Добавьте отдельный блок server на порту 80, который постоянно перенаправляет все запросы на HTTPS, чтобы посетители, заходящие по обычному HTTP, попадали на защищённый URL:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

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

Шаг 4. Проверьте конфигурацию и перезагрузите NGINX

Всегда проверяйте конфигурацию перед перезагрузкой, чтобы опечатка не привела к отключению сервиса:

sudo nginx -t

Вы должны увидеть сообщения syntax is ok и test is successful. Если появляется ошибка, в сообщении указывается файл и номер строки; исправьте её и снова запустите тест. Когда тест пройден успешно, перезагрузите NGINX, чтобы он применил новую конфигурацию без разрыва существующих соединений:

sudo systemctl reload nginx

В системах без systemd используйте вместо этого собственный сигнал перезагрузки NGINX:

sudo nginx -s reload

Отдавайте предпочтение reload, а не restart: перезагрузка (reload) повторно считывает конфигурацию, не закрывая активные соединения, тогда как перезапуск (restart) их разрывает.

Шаг 5 (опционально): включите OCSP stapling

OCSP stapling позволяет NGINX передавать актуальный, подписанный статус отзыва вместе с сертификатом, чтобы клиентам не приходилось обращаться к удостоверяющему центру при каждом рукопожатии. Добавьте следующее внутри блока server для HTTPS:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

Снова перезагрузите NGINX командой sudo systemctl reload nginx. Stapling — это небольшой, но полезный шаг по усилению безопасности, и большинство современных сертификатов поддерживают его «из коробки».

Проверка установки

Откройте свой сайт по https:// в браузере и убедитесь, что значок замка закрыт, а сертификат соответствует вашему домену. Затем выполните более глубокую проверку с помощью нашего SSL Checker, чтобы получить мгновенный отчёт о сертификате, цепочке, а также протоколах и шифрах, которые предлагает ваш сервер. Зелёный результат означает, что клиенты на всех основных платформах будут доверять сертификату, включая мобильные и API-клиенты.

Часто задаваемые вопросы