🔐 NGINX теперь сам умеет получать SSL-сертификаты: модуль ACME без костылей

Иллюстрация с логотипом NGINX, замками и сертификатами, символизирующая автоматическую установку и обновление SSL/TLS-сертификатов через нативную поддержку ACME-протокола.

12 августа 2025 года команда NGINX сделала то, чего ждали многие админы и DevOps-инженеры: представила ngx_http_acme_module — нативную поддержку протокола ACME прямо в конфигурации сервера. Это значит, что для автоматического получения и продления TLS-сертификатов больше не нужно ставить отдельные утилиты вроде Certbot или acme.sh — всё делается внутри NGINX.

🧩 Что такое ACME и зачем он нужен

ACME (Automated Certificate Management Environment) — это протокол, созданный в рамках инициативы Let’s Encrypt в 2015 году. Он полностью автоматизировал процесс:

• 📜 запроса и выпуска сертификата,
• ✅ проверки владения доменом,
• ♻️ продления и отзыва.

До ACME админам приходилось вручную генерировать CSR, отправлять его в центр сертификации, ждать письма, загружать файлы в веб-корень, потом обновлять конфиги — и повторять это каждые 90 дней. Сейчас это решается одной строкой в конфиге.

⚙️ Как это реализовано в NGINX

NGINX пошёл по пути глубокой интеграции и написал модуль на Rust SDK, доступный как динамическое расширение и для Open Source-версии, и для NGINX Plus.

В конфигурации появились новые директивы:

• 🏷 acme_issuer — задаёт ACME-сервер (например, Let’s Encrypt) и путь для хранения данных.
• 📦 acme_shared_zone — общая память для сертификатов, ключей и challenge-данных (по умолчанию 256K).
• 🔑 acme_certificate — автоматическая выдача/продление сертификатов для доменов из server_name.

Пример для Let’s Encrypt:

acme_issuer letsencrypt {
uri https://acme-v02.api.letsencrypt.org/directory;
state_path /var/cache/nginx/acme-letsencrypt;
accept_terms_of_service;
}

acme_shared_zone zone=acme_shared:1M;

server {
listen 80;
return 404;
}

server {
listen 443 ssl;
server_name example.com;
acme_certificate letsencrypt;
ssl_certificate $acme_certificate;
ssl_certificate_key $acme_certificate_key;
}

🛠 Ограничения текущей версии

• 📍 Поддерживается только HTTP-01 challenge (требует 80 порт).
• ❌ Нет поддержки TLS-ALPN и DNS-01 (в том числе для wildcard-сертификатов) — пока в планах.
• 🔍 Регулярные выражения и подстановки в server_name недоступны.

💡 Почему это важно

Сейчас процесс получения сертификатов часто зависит от внешних скриптов и cron-задач, что:

• увеличивает риск ошибок при ручных обновлениях;
• создаёт зависимость от сторонних пакетов;
• усложняет деплой в контейнерах и CI/CD.

С нативным ACME:

• 🔐 уменьшается поверхность атаки (меньше софта — меньше уязвимостей),
• 🚀 упрощается автоматизация (всё в одном месте — в конфиге NGINX),
• 📦 повышается переносимость (модуль работает одинаково на всех платформах).

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

📊 Моё мнение

Я считаю, что этот шаг логичен и давно назрел. Certbot и аналоги отлично справляются, но для DevOps-процессов, где ценится минимум внешних зависимостей, встроенный ACME — огромный плюс. Особенно это важно для Kubernetes-инфраструктур, где NGINX часто используется как Ingress-контроллер: лишние контейнеры для сертификатов просто отпадут.

Если NGINX реализует DNS-01 и wildcard в следующем релизе, то внешние ACME-клиенты многим станут просто не нужны.

🔗 Источники:

• Блог NGINX: https://blog.nginx.org/blog/native-support-for-acme-protocol