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

2026-05-08

nginxsslinstallationtlsserver

Это руководство проведёт вас через установку SSL-сертификата на Nginx — от загрузки файлов до оптимизации настроек TLS и устранения распространённых ошибок. Оно работает с сертификатами от GetHTTPS, Certbot или любого другого источника.

Если у вас ещё нет сертификата, получите его бесплатно за 5 минут.

Предварительные требования

Nginx установлен и обслуживает ваш сайт по HTTP (порт 80)
Root/sudo-доступ к серверу
Файлы сертификата — вам нужны два:
- fullchain.pem — ваш сертификат + промежуточная цепочка (объединённые)
- privkey.pem — ваш закрытый ключ

Какой файл какой? GetHTTPS выдаёт четыре файла. Nginx нужны fullchain.pem (не cert.pem) и privkey.pem. Использование только cert.pem вызывает ошибки “incomplete chain”, потому что браузеры не могут проверить цепочку доверия. Форматы сертификатов →

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

Скопируйте файлы в защищённую директорию:

# Создание директории
sudo mkdir -p /etc/ssl/gethttps

# Копирование файлов (с локальной машины на сервер)
sudo cp fullchain.pem /etc/ssl/gethttps/
sudo cp privkey.pem /etc/ssl/gethttps/

# Ограничение прав на закрытый ключ — только root должен его читать
sudo chmod 600 /etc/ssl/gethttps/privkey.pem
sudo chmod 644 /etc/ssl/gethttps/fullchain.pem
sudo chown root:root /etc/ssl/gethttps/*

При передаче через SCP:

scp fullchain.pem privkey.pem user@your-server:/tmp/
# Затем на сервере:
sudo mv /tmp/fullchain.pem /tmp/privkey.pem /etc/ssl/gethttps/

Шаг 2: Настройка HTTPS-блока сервера

Отредактируйте конфигурацию Nginx для вашего сайта. Файл обычно находится по пути:

/etc/nginx/sites-available/yourdomain.conf (Debian/Ubuntu)
/etc/nginx/conf.d/yourdomain.conf (CentOS/RHEL)

Полная рекомендуемая конфигурация:

# HTTPS-блок сервера
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

    # ─── Файлы сертификата ───────────────────────
    ssl_certificate     /etc/ssl/gethttps/fullchain.pem;
    ssl_certificate_key /etc/ssl/gethttps/privkey.pem;

    # ─── Протокол TLS и шифры ────────────────
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # ─── Кеширование сессий (производительность) ───────────
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # ─── OCSP stapling (ускорение проверки) ─────
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # ─── Заголовки безопасности ────────────────────────
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;

    # ─── Ваш сайт ───────────────────────────────
    root /var/www/html;
    index index.html;

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

# Блок HTTP-редиректа
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Что делает каждая секция:

Директива	Назначение
`listen 443 ssl http2`	HTTPS на порту 443 с включённым HTTP/2
`ssl_certificate`	Путь к сертификату + цепочке
`ssl_certificate_key`	Путь к закрытому ключу
`ssl_protocols`	Только TLS 1.2 и 1.3 (1.0/1.1 устарели с 2020 года)
`ssl_prefer_server_ciphers off`	Позволяет клиенту выбрать лучший шифр (современная лучшая практика)
`ssl_session_cache`	Кеширование TLS-сессий — избегает повторного рукопожатия для возвращающихся посетителей
`ssl_session_tickets off`	Тикеты могут ослабить прямую секретность
`ssl_stapling`	Сервер получает OCSP-ответ — быстрее для клиентов
`Strict-Transport-Security`	HSTS — браузеры запоминают, что нужно всегда использовать HTTPS
`return 301`	Постоянный редирект с HTTP на HTTPS

Шаг 3: Тестирование конфигурации

Всегда тестируйте перед перезагрузкой:

sudo nginx -t

Ожидаемый вывод:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Если тест не прошёл, Nginx укажет точный номер строки с ошибкой. Распространённые ошибки:

Опечатка в пути к файлу (ssl_certifcate вместо ssl_certificate)
Файл не существует по указанному пути
Пропущенные точки с запятой

Шаг 4: Перезагрузка Nginx

sudo systemctl reload nginx

Используйте reload, а не restart. Reload применяет новую конфигурацию к новым соединениям без разрыва существующих — нулевое время простоя.

Шаг 5: Проверка сертификата

Проверка в браузере

Перейдите на https://yourdomain.com. Нажмите на значок замка для подтверждения:

Выдан: “Let’s Encrypt” (или ваш удостоверяющий центр)
Действителен: даты начала и окончания
Домен: соответствует вашему URL

Проверка из командной строки

# Полные данные сертификата
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Проверка наличия полной цепочки
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | grep -E 'Verify return code|depth='

Ожидается: Verify return code: 0 (ok) и несколько уровней глубины (ваш сертификат + промежуточный).

Онлайн-проверка

Используйте SSL Labs Server Test для комплексного отчёта. Он проверяет:

Валидность цепочки сертификатов
Поддержку протоколов (должны отображаться только TLS 1.2 + 1.3)
Надёжность набора шифров
Известные уязвимости (BEAST, POODLE, Heartbleed)
Конфигурацию HSTS

Цель: оценка Grade A или A+.

Как обновить сертификат

Когда срок действия сертификата приближается к истечению (60-й день из 90 для Let’s Encrypt):

Получите новый сертификат на GetHTTPS (или через ваш инструмент обновления)

Замените файлы:

sudo cp new-fullchain.pem /etc/ssl/gethttps/fullchain.pem
sudo cp new-privkey.pem /etc/ssl/gethttps/privkey.pem

Перезагрузите Nginx:
```
sudo systemctl reload nginx
```

Перезапуск не нужен. Nginx подхватывает новые файлы при перезагрузке. Полное руководство по обновлению →

Хотите автоматическое обновление? Установите Certbot для обновления без вмешательства: sudo certbot --nginx -d example.com. Он обрабатывает всё, включая конфигурацию Nginx.

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

”SSL: error:0B080074:x509 certificate routines”

Причина: Вы используете cert.pem вместо fullchain.pem.

Исправление: Измените ssl_certificate, чтобы указывал на fullchain.pem, который включает и ваш сертификат, и промежуточную цепочку доверия:

ssl_certificate /etc/ssl/gethttps/fullchain.pem;  # НЕ cert.pem

“cannot load certificate key”

Причина: Неправильные права доступа к файлу закрытого ключа, файл повреждён или ключ не соответствует сертификату.

Исправление:

# Проверьте права (должны быть 600)
ls -la /etc/ssl/gethttps/privkey.pem

# Проверьте валидность ключа
sudo openssl ec -in /etc/ssl/gethttps/privkey.pem -check  # Для ECDSA
sudo openssl rsa -in /etc/ssl/gethttps/privkey.pem -check  # Для RSA

# Проверьте соответствие ключа и сертификата
sudo openssl x509 -noout -modulus -in /etc/ssl/gethttps/fullchain.pem | md5sum
sudo openssl rsa -noout -modulus -in /etc/ssl/gethttps/privkey.pem | md5sum
# Оба хеша ДОЛЖНЫ совпадать

“nginx: [emerg] bind() to 0.0.0.0:443 failed”

Причина: Порт 443 уже используется другим процессом.

Исправление:

# Найти, что использует порт 443
sudo ss -tlnp | grep 443

# Обычно: другой экземпляр Nginx или Apache
sudo systemctl stop apache2  # Если Apache запущен
sudo systemctl reload nginx

HTTPS работает, но браузер показывает “Not Secure”

Причина: Смешанный контент — ваша страница загружает изображения, скрипты или CSS по http://.

Исправление: Откройте DevTools (F12) → Консоль → ищите предупреждения “Mixed Content”. Обновите все URL ресурсов для использования https:// или относительных путей.

”ERR_SSL_VERSION_OR_CIPHER_MISMATCH”

Причина: Клиент не поддерживает версии TLS или шифры, которые предлагает ваш сервер.

Исправление: Убедитесь, что ваша конфигурация включает TLS 1.2 (не только 1.3):

ssl_protocols TLSv1.2 TLSv1.3;  # НЕ только TLSv1.3

Сертификат отображается как “Untrusted” несмотря на правильные файлы

Причина: Цепочка сертификатов неполная — в fullchain.pem отсутствует промежуточный сертификат, или файл в неправильном порядке.

Исправление: Пересоберите fullchain.pem, объединив ваш сертификат + промежуточный:

cat cert.pem chain.pem > fullchain.pem

Порядок имеет значение: сначала ваш сертификат, затем промежуточный.

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

Нужны ли отдельные файлы конфигурации для HTTP и HTTPS?

Нет. Поместите оба блока server (порт 80 и 443) в один файл. HTTP-блок существует только для редиректа на HTTPS.

Нужно ли использовать `ssl on;`?

Нет. ssl on; устарел. Используйте listen 443 ssl; — параметр ssl в директиве listen является современным подходом.

В чём разница между `reload` и `restart`?

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

Можно ли обслуживать несколько доменов с разными сертификатами?

Да. Используйте отдельные блоки server с разными server_name, ssl_certificate и ssl_certificate_key. Nginx использует SNI (Server Name Indication) для отдачи правильного сертификата в зависимости от запрашиваемого имени хоста.

Поддерживает ли Nginx сертификаты ECDSA/ECC?

Да. Nginx обрабатывает сертификаты ECDSA точно так же, как RSA — те же директивы, тот же формат файлов. GetHTTPS по умолчанию генерирует ECDSA P-256 (меньшие ключи, более быстрые рукопожатия).

Как включить HTTP/2?

Добавьте http2 в директиву listen: listen 443 ssl http2;. Это уже есть в рекомендуемой конфигурации выше. HTTP/2 требует HTTPS — использовать его по незащищённому HTTP нельзя.