ADG Оставить заявку
Блог Информационная безопасность 4 мин чтения

Let's Encrypt, ACME v2 draft и год автоматизации: где хватает, а где нет

ACME v2 draft опубликован, wildcard-сертификаты анонсированы. Разбираем год работы с certbot + systemd timer и честно говорим, где корпоративный CA пока незаменим.

Контекст момента

Let's Encrypt опубликовал ACME v2 draft, анонсированы wildcard-сертификаты и поддержка IPv6

На прошлой неделе Let's Encrypt опубликовал черновик ACME v2 и объявил, что в рамках этой версии протокола появится поддержка wildcard-сертификатов. Новость прошла по всем профильным каналам - и это хороший повод оглянуться на год, который мы провели с certbot в продакшене, и честно сформулировать, где автоматизация работает чисто, а где по-прежнему упираешься в ограничения.

Год с certbot: что сложилось

После того как в июле мы перевели managed-клиентов на LE, задача расширилась: покрыть собственную инфраструктуру и внешние сервисы клиентов по аудиту. К концу 2016 все внешние сервисы - nginx-прокси, почтовые шлюзы, веб-интерфейсы мониторинга, API-эндпоинты - перешли на автоматическое получение сертификатов.

Архитектура простая. Certbot в режиме webroot, systemd timer вместо cron:

# /etc/systemd/system/certbot.timer
[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target
# /etc/systemd/system/certbot.service
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"

RandomizedDelaySec - не эстетика, а необходимость: когда хостов много и все они обновляются по одному таймеру, размазать нагрузку по часовому окну разумно. ACME rate limits на стороне LE никуда не делись.

Мониторинг срока сертификата через Zabbix оставили. Логика прежняя: timer может не сработать по десятку причин - хост в обслуживании, systemd что-то отъел, кто-то перезаписал unit-файл. Алерт за 20 дней - это страховка, не недоверие к автоматике.

Где LE хватает

Большинство внешних задач закрывается без вопросов:

  • Публичные веб-сервисы - всё, у чего есть A-запись и доступный 80-й порт. HTTP-01 challenge работает стабильно, certbot справляется сам.
  • API-эндпоинты и внутренние порталы с выходом наружу - та же история. Главное что у хоста есть публичный DNS.
  • Почтовые шлюзы - STARTTLS на сертификате LE работает нормально, клиентские MTA не жалуются. Всё что нужно - домен в MX совпадает с тем, на который выдан сертификат.

За год на этой схеме не было ни одного протухшего сертификата из-за логики LE или certbot. Все инциденты, что были - человеческий фактор: хост переехал, DNS не обновили, webroot сменился, никто не проверил.

Где корпоративный CA пока незаменим

Здесь честно, без округлений:

  • Wildcard. Это главное ограничение прямо сейчас. DNS-01 challenge в certbot существует, но автоматизация под него требует API доступа к DNS-провайдеру. Не у всех клиентов DNS стоит там, где есть нормальный API. Руками выписывать wildcard каждые 90 дней через ACME - хуже чем купить сертификат на год. Wildcard через LE в ACME v2 анонсированы, но это пока черновик протокола.
  • Внутренние сервисы без публичного DNS. ERP, 1С-сервер, внутренний GitLab на приватном домене типа gitlab.corp.example - LE не выдаст сертификат для домена, которого нет в публичном DNS. Здесь корпоративный CA и точка. Развернуть свой промежуточный CA на базе CFSSL или встроенных средств Windows PKI - нормальное решение для такого сегмента.
  • EV-сертификаты. LE выдаёт только DV. Если заказчик по требованиям или договорённостям с клиентами хочет EV - это отдельный CA с юридической верификацией. Таких кейсов немного, но они есть.
  • Клиентские сертификаты для mTLS. LE для этого не предназначен. Взаимная аутентификация по сертификатам между сервисами или для VPN - корпоративный CA.

Что ждём от ACME v2

Черновик протокола опубликован, рабочая группа IETF его рассматривает. Главное для нас - wildcard через DNS-01. Это закроет один из последних сценариев, где мы продолжаем выписывать сертификаты руками или держим платный CA ради одного wildcard.

Но DNS-01 упирается в следующий слой: нужен динамический DNS с API, и нужна автоматизация вокруг него. У части клиентов DNS живёт в регистраторе без нормального API, и это организационная задача, не техническая. Для Route53, Cloudflare, DigitalOcean есть сторонние плагины и хук-скрипты - там автоматизация реализуема. Для всего остального придётся делать руками или писать плагин.

Разрыв между «LE объявил wildcard» и «мы автоматически получаем wildcard для всех клиентов» будет не техническим, а инфраструктурным. Это честное ожидание.

Итог года

Сертификаты для внешних публичных сервисов - закрытая тема. Certbot + systemd timer работает без вмешательства, задача снята с радара. Время, которое уходило на ручное продление, теперь идёт на что-то полезное.

Корпоративный CA никуда не делся и не должен был: wildcard внутри, приватные домены, клиентские сертификаты - это отдельный слой с другими требованиями. Хорошо когда инструменты не пытаются закрыть всё подряд, а делают свою часть хорошо.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.