HTTP, HTTPS и TLS: Часть 11 — Сертификаты Let's Encrypt: ACME, проверки домена, CAA и Certificate Transparency

Let’s Encrypt — бесплатный удостоверяющий центр, который выдаёт сертификаты DV автоматически, без заявок и оплаты. Выпуск и продление идут по протоколу ACME (Automatic Certificate Management Environment, RFC 8555): программа на сервере сама доказывает, что управляет доменом, получает сертификат и ставит его в веб-сервер. По тому же протоколу работают ZeroSSL, Google Trust Services, Buypass и другие центры; чем они отличаются от Let’s Encrypt — в обзоре «За пределами Let’s Encrypt». Сроки жизни сертификатов сокращаются, и в ближайшие годы ручной выпуск станет практически невозможен, поэтому эту часть стоит один раз настроить правильно.

Как работает ACME

1. Учётная запись. Клиент создаёт у центра учётную запись — пару ключей, которой подписывает все дальнейшие запросы. Электронная почта необязательна; с июня 2025 года Let’s Encrypt больше не присылает напоминаний об истечении срока, так что следить за сроками придётся самостоятельно.
2. Заказ (order). Клиент перечисляет имена для сертификата: example.ru, www.example.ru.
3. Проверки (challenges). Для каждого имени центр выдаёт задание, которое может выполнить только владелец домена или сервера.
4. Выполнение проверки. Клиент размещает ответ, центр проверяет его из нескольких точек интернета.
5. Выпуск. Клиент отправляет запрос на подпись (CSR) со своим открытым ключом и скачивает сертификат вместе с промежуточным.

Успешная проверка домена какое-то время засчитывается повторно (authorization reuse) — сейчас до 30 дней, к 2028 году Let’s Encrypt сократит этот срок до 7 часов.

Три способа проверки

HTTP-01. Клиент кладёт файл с токеном по адресу http://example.ru/.well-known/acme-challenge/<токен>, центр скачивает его.

• нужен открытый порт 80 — другой порт указать нельзя; центр следует редиректам на HTTPS;
• домен должен указывать на этот сервер;
• не подходит для wildcard-сертификатов;
• если серверов несколько за балансировщиком, файл должен быть доступен на всех (или запрос проверки должен попадать на тот, где работает клиент).

DNS-01. Клиент создаёт TXT-запись _acme-challenge.example.ru с токеном. Пошаговая настройка для Cloudflare и Route 53 — в статье «SSL-сертификаты через DNS».

• единственный способ получить wildcard *.example.ru;
• не нужен ни открытый порт, ни доступ к серверу извне — подходит для внутренних сервисов с публичным доменом;
• клиенту нужен доступ к API DNS-провайдера. Чтобы не давать ему ключ от всей зоны, делегируйте проверку: _acme-challenge.example.ru CNAME _acme-challenge.acme-zone.example.net — и выдавайте ключ только от служебной зоны (так работает, например, acme-dns);
• после создания записи нужно дождаться, пока её увидят все авторитетные DNS-серверы зоны.

Let’s Encrypt готовит способ DNS-PERSIST-01, при котором TXT-запись создаётся один раз и не меняется при каждом продлении.

TLS-ALPN-01. Проверка на порту 443: центр подключается с ALPN acme-tls/1, и сервер отвечает специальным временным сертификатом. Удобно, когда порт 80 закрыт. Используется в основном встроенными клиентами — Caddy, Traefik, lego; с certbot и обычным Nginx не работает.

Клиенты ACME

certbot — клиент от EFF, есть в пакетах большинства дистрибутивов.

# выпуск с автоматической настройкой Nginx
certbot --nginx -d example.ru -d www.example.ru

# только выпуск, файл проверки кладётся в каталог сайта
certbot certonly --webroot -w /var/www/letsencrypt -d example.ru -d www.example.ru \
  --deploy-hook 'systemctl reload nginx'

# wildcard через API DNS (нужен плагин, например python3-certbot-dns-cloudflare)
certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.cf.ini \
  -d example.ru -d '*.example.ru'

# проверить продление без выпуска
certbot renew --dry-run

Пакет certbot ставит systemd-таймер или задачу cron, которая дважды в день вызывает certbot renew. Сертификаты лежат в /etc/letsencrypt/live/<имя>/: fullchain.pem — сертификат с промежуточным (его указывают в Nginx), privkey.pem — ключ. --deploy-hook выполняется только после успешного продления и перезагружает веб-сервер; без него Nginx продолжит отдавать старый сертификат.

acme.sh — клиент на shell без зависимостей, поддерживает больше сотни DNS-провайдеров.

acme.sh --set-default-ca --server letsencrypt   # по умолчанию acme.sh использует ZeroSSL
acme.sh --issue --dns dns_cf -d example.ru -d '*.example.ru'
acme.sh --install-cert -d example.ru \
  --fullchain-file /etc/nginx/ssl/example.ru.crt \
  --key-file /etc/nginx/ssl/example.ru.key \
  --reloadcmd 'systemctl reload nginx'

Встроенный ACME. Caddy и Traefik выпускают и продлевают сертификаты сами для каждого сайта в конфигурации. У Nginx с 2025 года есть официальный динамический модуль ngx_http_acme_module (пакет nginx-module-acme). Если веб-сервер умеет ACME сам, отдельный клиент не нужен.

Kubernetes — cert-manager: сертификаты описываются как ресурсы, выпуск и продление идут внутри кластера.

Сроки жизни и профили

Сертификаты Let’s Encrypt традиционно живут 90 дней. Проект переходит на более короткие сроки через профили ACME — клиент выбирает профиль при заказе:

• classic — профиль по умолчанию: 90 дней; с 10 февраля 2027 года — 64 дня, с 16 февраля 2028 года — 45 дней;
• tlsserver — с 13 мая 2026 года выдаёт сертификаты на 45 дней, для тех, кто хочет перейти раньше;
• shortlived — около 6 дней. Такие сертификаты можно выпускать и на IP-адреса.

Это совпадает с общим решением CA/Browser Forum: максимальный срок любых публичных сертификатов — 200 дней с марта 2026 года, 100 дней с марта 2027-го, 47 дней с марта 2029-го.

Что из этого следует:

• продлевайте примерно на двух третях срока, а не «за 30 дней до конца»: у 45-дневного сертификата 30 дней — это почти весь срок;
• используйте клиент с поддержкой ARI (ACME Renewal Information, RFC 9773): центр сам подсказывает, когда продлевать, например при массовом отзыве. Продления через ARI не расходуют лимиты;
• любой ручной шаг — копирование сертификата на другой сервер, загрузка в панель, обновление в роутере — нужно автоматизировать или отказаться от него.

Лимиты Let’s Encrypt

Самые заметные:

• 50 сертификатов на зарегистрированный домен за 7 дней — для example.ru вместе со всеми поддоменами;
• 5 сертификатов на одинаковый набор имён за 7 дней — обычно исчерпывается, когда скрипт или контейнер при каждом запуске выпускает сертификат заново вместо использования сохранённого;
• 5 неудачных проверок в час на одно имя для учётной записи;
• 300 новых заказов за 3 часа на учётную запись.

Для отладки используйте тестовый сервер (staging, в certbot — ключ --staging или --test-cert): лимиты там гораздо выше, а сертификаты не доверенные. Продления с тем же набором имён не считаются в лимит 50 сертификатов на домен.

Записи CAA

CAA (Certification Authority Authorization, RFC 8659) — DNS-запись, которая перечисляет удостоверяющие центры, имеющие право выпускать сертификаты для домена. Центры обязаны проверять её перед выпуском. Если записи нет, выпускать может любой.

example.ru.  3600  IN  CAA  0 issue "letsencrypt.org"
example.ru.  3600  IN  CAA  0 issuewild ";"
example.ru.  3600  IN  CAA  0 iodef "mailto:security@example.ru"

• issue — кто может выпускать обычные сертификаты;
• issuewild — кто может выпускать wildcard; ";" — никто;
• iodef — куда сообщать о попытках выпуска в нарушение правил (центры это поддерживают не всегда).

Можно ограничить не только центр, но и учётную запись и способ проверки (RFC 8657):

example.ru. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"

Запись действует и на поддомены, пока у поддомена нет своей. Если сайт за CDN, который сам выпускает сертификаты (Cloudflare, например, использует Let’s Encrypt и Google Trust Services), не забудьте добавить его центры, иначе CDN не сможет продлить сертификат. Проверка: dig CAA example.ru.

Certificate Transparency

Certificate Transparency (CT) — система публичных журналов, в которые удостоверяющие центры записывают каждый выпущенный публичный сертификат. Chrome с 2018 года, а за ним Safari и Firefox принимают сертификат, только если в нём есть подтверждения записи в журналы (SCT). Выпустить доверенный сертификат тайно невозможно.

Зачем это владельцу домена:

• обнаружить чужой выпуск. Если кто-то получил сертификат на ваш домен — через взлом DNS, ошибку центра или бывшего подрядчика, — он появится в журнале;
• понять, что ваши имена публичны. Каждый сертификат раскрывает все имена из SAN. Выпустили сертификат на grafana.example.ru или test-crm.example.ru — это имя в течение минут видят все, включая сканеры, которые отслеживают журналы CT и сразу проверяют новые хосты на уязвимости.

Поиск по журналам — сервис crt.sh:

curl -s 'https://crt.sh/?q=%25.example.ru&output=json' \
  | jq -r '.[].name_value' | sort -u

%25 — это закодированный знак %, шаблон «любой поддомен». Оповещения о новых сертификатах на ваш домен дают бесплатные сервисы мониторинга CT, например Cert Spotter.

Как не раскрывать внутренние имена:

• для внутренних сервисов выпускайте wildcard *.example.ru — в журнал попадёт только шаблон, а не каждое имя;
• или используйте внутренний удостоверяющий центр (step-ca): его сертификаты в журналы CT не пишутся;
• не рассчитывайте, что «никто не знает адрес» — CT делает любое имя из публичного сертификата известным.

Типичные ошибки

• cert.pem вместо fullchain.pem в Nginx — неполная цепочка.
• Продление работает, но нет --deploy-hook или --reloadcmd — веб-сервер отдаёт старый сертификат до перезапуска.
• Выпуск сертификата при каждом старте контейнера — лимит 5 дубликатов за неделю, и сервис остаётся без сертификата.
• Закрыт порт 80 «для безопасности» — перестаёт работать HTTP-01.
• CAA разрешает только Let’s Encrypt, а CDN выпускает сертификаты у другого центра — продление на CDN молча ломается.
• Мониторинг сроков не настроен в расчёте на письма от Let’s Encrypt, которых больше нет.