Самоподписанный SSL для Nginx

Логотип Nginx

Быстрые ссылки

Генерация и самоподпись SSL-сертификата
Конфигурация Nginx для использования приватного ключа и сертификата

Если вам нужно только шифрование для внутренних соединений или сайтов, не ориентированных на публичную аудиторию, самоподписанные SSL‑сертификаты — простой способ избежать работы с внешним центром сертификации (CA). Ниже — подробная инструкция для nginx.

Если вы хотите бесплатные сертификаты для публичных сайтов, используйте LetsEncrypt: он удобен для пользовательских браузеров, потому что выдача идёт от признанного CA. Let’s Encrypt не подходит для приватных IP‑адресов в большинстве случаев — тогда остаётся самоподпись.

Генерация и самоподпись SSL-сертификата

Мы будем использовать утилиту openssl. Обычно она уже установлена как зависимость nginx; если нет — установите через менеджер пакетов (пример для Debian/Ubuntu):

sudo apt-get install openssl

После установки можно сгенерировать самоподписанный сертификат командой:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx.key -out /etc/ssl/certs/nginx.crt

В процессе генерации вас попросят ввести данные организации. Для самоподписанного сертификата важен только Common Name — укажите домен или IP‑адрес сервера.

Country Name (2 letter code) []:

State or Province Name (full name) []:

Locality Name (eg, city) []:

Organization Name (eg, company) []:

Organizational Unit Name (eg, section) []:

Common Name (eg, fully qualified host name) []: your_ip_address

Email Address []:

Команда создаст RSA‑приватный ключ в /etc/ssl/private/nginx.key и сертификат в /etc/ssl/certs/nginx.crt, действительный в течение указанного числа дней (в примере — 365).

Дополнительно рекомендуется сгенерировать параметры Diffie‑Hellman для обеспечения Perfect Forward Secrecy (PFS). Это создаёт эпhemeral‑ключи для сессий: если приватный ключ скомпрометирован, прошлые сессии остаются зашифрованными.

sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

Генерация dhparam может занять значительное время (особенно для 4096 бит). На слабой машине это может быть час и более.

Важно: если вы ограничены по времени, можно использовать 2048 или предварительно сгенерировать файл на более быстрых хостах и перенести его.

Конфигурация Nginx: подключаем ключ и сертификат

Чтобы не копировать одно и то же в каждый server-блок, создадим сниппет конфигурации nginx и подключим его.

touch /etc/nginx/snippets/self-signed.conf

Откройте файл в редакторе и вставьте туда следующую конфигурацию (весь блок ниже — файл сниппета):

ssl_certificate /etc/ssl/certs/nginx.crt;
ssl_certificate_key /etc/ssl/private/nginx.key;
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
ssl_dhparam /etc/nginx/dhparam.pem;
ssl_ecdh_curve secp384r1;

Первые строки указывают nginx использовать наш самоподписанный сертификат и приватный ключ. Остальное — рекомендуемые SSL‑настройки: протоколы, набор шифров, кэш сессий, OCSP stapling и заголовки безопасности.

Примечание: если вы не генерировали dhparam, удалите или закомментируйте строку ssl_dhparam.

Теперь подключите этот сниппет в вашем server‑блоке nginx. Для одиночных сайтов основной конфиг обычно /etc/nginx/nginx.conf; на серверах с несколькими сайтами — файлы в /etc/nginx/sites-available.

Пример server‑блока для HTTPS:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    include snippets/self-signed.conf;
    server_name example.com www.example.com;

    # ... остальная конфигурация сайта (root, proxy_pass, location и т.д.)
}

И пример редиректа с HTTP на HTTPS (временный 302, затем поменяйте на 301):

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 302 https://$server_name$request_uri;
}

После изменений перезапустите nginx и проверьте конфигурацию:

sudo nginx -t
sudo service nginx restart

Сетевая конфигурация и файрвол

HTTPS использует порт 443. Настройте файрвол (UFW, iptables или облачные правила) чтобы разрешить входящие подключения на 443/TCP. Пример для UFW:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp

Если сервер работает внутри LAN, рекомендуется разрешать доступ только из вашей подсети и обеспечивать доступ извне через VPN.

Интерфейс брандмауэра AWS

Что увидит пользователь и почему браузер предупреждает

При самоподписанном сертификате браузер покажет предупреждение безопасности и попросит подтвердить доверие сертификату вручную.

Предупреждение SSL в Chrome

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

Когда самоподпись не подходит

Для публичных сайтов и сервисов, где доверие пользователей важно — используйте признанные CA (Let’s Encrypt и т. п.).
Если нужно шифровать приватные IP в публичной сети — большинство публичных CA не выдают сертификаты для прямых IP.
Для автоматического обновления сертификатов и управления доверием в браузерах лучше CA.

Альтернативные подходы

Let’s Encrypt (ACME) — бесплатные сертификаты для публичных доменов с автоматическим продлением.
Внутренний корпоративный CA — для централизованного управления доверенными сертификатами внутри организации.
Использование mTLS (взаимная аутентификация) — когда нужно подтверждать и клиент, и сервер.

Практическая методика (микро‑SOP)

Убедитесь, что openssl установлен.
Сгенерируйте ключ и самоподписанный сертификат.
(Опционально) Сгенерируйте dhparam для PFS.
Создайте сниппет конфигурации nginx и подключите его.
Настройте редирект HTTP→HTTPS и откройте порты в файрволе.
Протестируйте подключение с браузера и с утилит (curl/openssl).
Переведите редирект в 301 после проверки.

Проверки и тесты (Критерии приёмки)

nginx стартует без ошибок: sudo nginx -t → OK.
Прослушивается порт 443: sudo ss -tlnp | grep 443 или netstat -tlnp.
Сертификат доступен: openssl s_client -connect example.com:443 -servername example.com и в выводе видно «Verify return code: 18» (self signed certificate).
Браузер может открыть сайт по https, хотя и с предупреждением о доверии.
Редирект с HTTP работает и перенаправляет на HTTPS.

Команда для проверки TLS:

openssl s_client -connect example.com:443 -servername example.com

Или простая проверка curl:

curl -vk https://example.com/

Чеклист ролей

Системный администратор:
- Сгенерировать ключ/сертификат и dhparam.
- Разместить файлы в /etc/ssl и установить права 600 на приватный ключ.
- Обновить сниппет и перезапустить nginx.
- Открыть 443/TCP в файрволе.
Разработчик/DevOps:
- Протестировать приложение через HTTPS.
- Настроить healthcheck и мониторинг HTTPS.
- Автоматизировать создание и деплой сертификатов (если нужно).
Сетевой инженер:
- Обеспечить, что сетевые ACL и балансировщики пропускают 443.
- При необходимости — настроить белые списки для сетей доступа.

Усиление безопасности и рекомендации

Используйте минимум TLS 1.2, предпочтительно TLS 1.3, если поддерживается ваш стек.
Отключите слабые шифры и включите ECDHE/DHE для PFS.
Отключите session tickets, если у вас нет безопасного механизма ротации ключей.
Включите HSTS только после тестирования (add_header Strict-Transport-Security …;), потому что это навсегда заставит браузеры использовать HTTPS для вашего домена при длительном max-age.
Установите строгие права на приватный ключ (root:root, 600).
Разграничьте доступ к /etc/ssl/private и /etc/nginx/dhparam.pem.
Ротация ключей: создавайте новый сертификат и ключ по плану (например ежегодно) и тестируйте процедуру восстановления.

Типовые проблемы и способы их решения (Edge‑case gallery)

Ошибка при старте nginx после правки конфига: всегда проверяйте nginx -t, исправляйте синтаксис.
Очень долгий генератор dhparam: используйте 2048 бит для ускорения или сгенерируйте на другом хосте.
Браузер по‑прежнему блокирует доступ и не предлагает исключение: импортируйте сертификат в хранилище доверенных корней в вашей ОС/браузере (только в доверенной инфраструктуре).
OCSP Stapling не работает: проверьте доступность резолверов и правильность resolver в сниппете.

Мини‑справочник (1‑линейный глоссарий)

Самоподписанный сертификат — сертификат, подписанный тем же субъектом, которому он принадлежит (нет внешнего CA).
DH param — параметры для протокола Диффи‑Хеллмана, обеспечивающие PFS.
OCSP Stapling — механизм, когда сервер прикрепляет проверку статуса сертификата для ускорения и приватности.

Короткая методология принятия решения (Decision × Effort)

Public site + UX доверия → Let’s Encrypt (высокая польза, средняя сложность).
Внутренние сервисы + приватные IP → Самоподпись (низкая сложность, быстрый запуск).
Корпоративный контроль → Внутренний CA (высокая польза, высокая сложность).

Итог

Самоподписанные сертификаты — быстрый и практичный способ обеспечить шифрование для внутренних систем. Они НЕ заменяют сертификаты от признанных CA на публичных сайтах из‑за отсутствия доверенной проверки идентичности. Следуйте рекомендациям по безопасности: используйте PFS, безопасные шифры, HSTS осторожно и защищайте приватный ключ.

Если вам нужно — ниже шаблоны команд и конфигов уже готовы: просто подставьте свои домены и пути.