Когда в инвентаре десятки или сотни доменов и поддоменов, случайный запуск ACME-клиента «одним скриптом» превращается в лотерею: лимиты Let’s Encrypt, лишние дубли, проваленные валидации, рассинхрон перезапусков, а потом неделя ручного тушения пожаров. Ниже — практическая стратегия массового выпуска и регулярного обновления SSL-сертификатов на базе ACME, чтобы всё работало предсказуемо, без падений и штрафов по лимитам.
Когда нужна стратегия массового выпуска
Массовый подход оправдан, если у вас:
- Парк доменов: от 20–30 до сотен FQDN, принадлежащих нескольким зарегистрированным доменам (eTLD+1) и зонам.
- Разнородная инфраструктура: несколько веб-серверов, балансировщики, CDN, контейнеры и микросервисы.
- Жёсткие SLO по доступности: любые просрочки сертификатов — инцидент.
- Ограничения по времени/штатам: хочется «одна кнопка, много сертификатов», а не проект на полгода.
Цель — минимизировать количество выпусков, равномерно распределить нагрузку по времени, автоматизировать валидации и добиться предсказуемости. Для этого важно понимать лимиты Let’s Encrypt и правильно применять SAN.
Ключевые лимиты Let's Encrypt (rate limits)
Certificates per Registered Domain
До 50 сертификатов в неделю на один зарегистрированный домен (eTLD+1). Например, example.com и все его поддомены суммарно подпадают под этот лимит. Если поддоменов много и вы выпускаете для каждого отдельный сертификат, упрётесь в порог быстро. SAN и wildcard помогают оптимизировать.
Duplicate Certificate
Не более 5 сертификатов в неделю с идентичным набором имён (SAN set). Если ваш пайплайн избыточно перевыпускает при каждом деплое — быстро приедете в лимит дублей. Решение: выпускать по окну продления, сравнивать текущий и желаемый SAN, не форсить без причины.
Failed Validations и операционные лимиты
Есть лимит на неуспешные валидации для конкретного хоста в рамках аккаунта в час. Массовая волна 404/403 для /.well-known/acme-challenge или некорректные DNS-записи приводит к «штрафу» по времени. Плюс лимиты на новые заказы и число «висящих авторизаций». Практически: не запускайте все выпуски в одну минуту; добавьте рассев и ретраи с экспоненциальной паузой.
Лимит SAN в одном сертификате
До ~100 имён (FQDN). Это предел для стратегии «укрупняем в один SAN». Разумнее группировать по сервисам/кластерам/окружениям, чтобы снизить «радиус поражения» при перевыпусках.
Выпуск SAN-сертификата с именами из нескольких зарегистрированных доменов засчитывается против лимита каждого из этих доменов. Склеивание разных зон в один SAN не «обманывает» лимиты.
SAN vs одиночные и wildcard-сертификаты
Три модели:
- Одиночные: изолированы и просты, но быстро упираются в 50/нед на домен, если поддоменов много.
- SAN (multi-domain): до ~100 имён, меньше выпусков, ниже риск упереться в лимит. Минусы — любое изменение набора имён перевыпускает весь сертификат; растёт размер и «blast radius».
- Wildcard: покрывает все поддомены одного уровня (
*.example.com), резко сокращает число выпусков. Требует DNS-01 и доступа к DNS API.
Практика: для доменов с множеством поддоменов — wildcard через DNS-01; для наборов разных доменов и сервисов — SAN-группы на 50–80 имён; для критичной изоляции — одиночные сертификаты (учитывайте лимиты и график). Подробно про wildcard и DNS-01 см. в разборе DNS-01 автоматизации для wildcard.
Методы валидации: HTTP-01, DNS-01, TLS-ALPN-01
- HTTP-01: минимальная интеграция, если контролируете веб-сервер и корректно проброшен
/.well-known/acme-challenge. Уязвим при многоступенчатых прокси и агрессивных редиректах. - DNS-01: универсален, нужен для wildcard и доменов без стабильного HTTP-эндоинта. Требует DNS API, учёта квот и управления TTL/репликацией.
- TLS-ALPN-01: точечный вариант, когда не хотите трогать HTTP и есть контроль над TLS-стеком.
Если проект работает на виртуальном хостинге, чаще всего удобен HTTP-01 через webroot. Для инфраструктуры на собственных VDS проще централизовать DNS-01 и wildcard, автоматизируя через API DNS-провайдера.
Архитектуры автоматизации для парка доменов
Централизованный «оркестратор»
Один сервис хранит desired state, общается с ACME (стейджинг/прод) и выкладывает ключи/цепочки на целевые хосты (SCP/rsync/артефакт-стор/секрет-менеджер). Плюсы — предсказуемый график, единый контроль дублей, простая отчётность. Минусы — точка отказа, безопасная доставка приватных ключей.
Дистрибутивные «раннеры»
Каждый хост сам выпускает/обновляет свои сертификаты. Нужны распределённые локи, рандомизация задач, унифицированные хуки перезагрузки и аккуратная валидация. Плюсы — меньше централизованных секретов. Минусы — сложнее собирать целостную картину.
Аккаунты ACME: стейджинг и прод
Держите два окружения: стейджинг и прод. Любые изменения логики, группировок SAN и миграции DNS — сначала в стейджинге, чтобы не ловить массовые Failed Validations и Duplicate.
Планирование и распределение нагрузки
Срок действия сертификатов — 90 дней. Обновляйте при остатке 30 дней, но не «в один день». Рабочие приёмы:
- Шардинг по доменам/кластерам с окнами в разные дни недели.
- Рандомизация старта в окне: джиттер 0–3600 секунд.
- Контроль Duplicate: если SAN не менялся — не перевыпускайте до окна.
- Учитывайте реальную репликацию DNS у вашего провайдера.
Работа с DNS, CAA и CDN
- CAA: при использовании CAA разрешите выпуск Let’s Encrypt для всех нужных имён.
- TTL: для DNS-01 держите низкий TTL у TXT под
_acme-challengeили у зоны на период массового выпуска. - CDN/прокси: для HTTP-01 сделайте bypass для
/.well-known/acme-challengeи отключите кэш/JS-челленджи/редиректы. - Квоты DNS API: учитывайте лимиты провайдера в шедулере и ретраях.
SAN-группировки: как резать по живому
- Группируйте по назначению и окружениям: prod, staging, dev отдельно.
- Не заполняйте SAN до 100 имён — оставьте резерв для будущих добавлений и аварий.
- Не смешивайте разные SLA в одном SAN: любое добавление триггерит перевыпуск всего сертификата.
Мониторинг и алерты
- Сроки действия: экспорт с хранилища и с хостов; триггеры за 30/14/7/3/1 день.
- Пайплайн: метрики успехов/ошибок ACME, длительности валидации, число операций, коды ошибок.
- Конфигурация: дрифт desired vs actual по SAN-группам; любое расхождение — событие.
Безопасность ключей и совместимость
Рекомендуйте ECDSA P-256 как основной: меньше CPU и быстрее TLS. Для старых клиентов допускается параллельная выдача EC+RSA и раздача по приоритетам сервера. Не забывайте:
- Защищённая доставка и хранение приватных ключей, строгие права на файлы.
- Бэкап ключа аккаунта ACME и артефактов выпуска.
- Грейсфул-перезагрузки сервисов после обновления цепочек.
Если требуется EV/OV или нестандартные требования совместимости, дополните парк коммерческими SSL-сертификатами.
Анти‑паттерны массового выпуска
- Один гигантский SAN «на всё»: любое изменение перевыпускает «всё» и увеличивает blast radius.
- Force‑renew на каждый деплой: упрётесь в Duplicate и перегрузите ACME.
- HTTP-01 за CDN без исключений: 403/JS-челленджи/редиректы ломают валидацию.
- Синхронный запуск раннеров: и ACME, и ваш DNS API ответят отказами.
Минимальный набор артефактов
- Список желаемых сертификатов (YAML/JSON): SAN-группы, метод валидации, целевые хосты, окна выпуска.
- Единые хуки: до/после валидации, установка файлов, перезапуск сервисов, отправка метрик.
- Хранилище состояний: ключи аккаунта, токены, артефакты и журнал операций.
Примеры команд и конфигураций
Certbot с webroot и SAN
# Выпуск SAN-сертификата для нескольких имён через HTTP-01
certbot certonly --agree-tos --non-interactive --email admin@example.com --webroot -w /var/www/acme -d example.com -d www.example.com -d api.example.com
# Обновление (обычно через systemd timer), можно вызвать вручную
certbot renew --deploy-hook "/usr/local/bin/reload-nginx"Nginx: прокладка для HTTP-01
location ^~ /.well-known/acme-challenge/ {
root /var/www/acme;
default_type text/plain;
try_files $uri =404;
}acme.sh с DNS-01 и wildcard
# Пример с DNS API провайдера (переменные зависят от провайдера)
export DNS_API_KEY=xxxx
acme.sh --issue -d example.com -d *.example.com --dns dns_provider
# Установка сертификата и перезапуск сервиса
acme.sh --install-cert -d example.com --key-file /etc/ssl/private/example.com.key --fullchain-file /etc/ssl/certs/example.com.fullchain.pem --reloadcmd "/usr/local/bin/reload-nginx"systemd таймер с джиттером
[Unit]
Description=ACME renew for shard A
[Service]
Type=oneshot
ExecStart=/usr/local/bin/acme_renew_shard_a
[Install]
WantedBy=timers.target[Unit]
Description=Timer for ACME renew shard A
[Timer]
RandomizedDelaySec=3600
Persistent=true
[Install]
WantedBy=timers.targetПорядок внедрения: чек‑лист
- Инвентаризация: полный список доменов/поддоменов, владельцев сервисов, текущих методов валидации, CDN и DNS-провайдеров.
- Лимиты: оцените объёмы; где wildcard, где SAN, где одиночные, чтобы не упереться в 50/нед.
- CAA и DNS: приведите записи в порядок, настройте доступ к DNS API и TTL.
- Окна: шардируйте парк, назначьте окна и джиттер, подготовьте стейджинг.
- ACME-аккаунты: создайте тестовый и продовый, зафиксируйте хранение и бэкапы ключей.
- Хуки и перезапуски: единые скрипты установки и graceful reload.
- Мониторинг: сроки, успехи/ошибки, дрифт конфигурации, алерты.
- Демо‑волна: прогон на стейджинге для одного шарда, затем на проде.
- Раскатка: шард за шардом, с наблюдением метрик и корректировкой таймингов.
- Ретроспектива: обновите документацию и правила группировок SAN.
Частые ошибки и быстрые решения
- Просрочили из‑за проваленных валидаций: ретраи с экспоненциальной паузой, алерты за N дней, fallback на альтернативный метод (DNS-01 вместо HTTP-01).
- Уперлись в 50/нед: укрупняйте SAN в пределах домена или переходите на wildcard через DNS-01; перенастройте окна.
- Duplicate Certificate: сравнивайте текущий и желаемый SAN, выключите force по умолчанию, тестируйте в стейджинге.
- CDN ломает HTTP-01: сделайте bypass для
/.well-known/acme-challengeи отключите проверки/редиректы/кэш. - DNS API квоты: расширьте окно, добавьте джиттер, батчьте изменения TXT, снизьте частоту проверок.
Итоги
Массовый выпуск через Let’s Encrypt — это инженерный процесс: знание лимитов, разумные SAN-группы и wildcard там, где это оправдано, корректная валидация (HTTP-01/DNS-01), расписание с джиттером, мониторинг и дисциплина «сначала стейджинг — потом прод». При таком подходе сотни имён обновляются незаметно, а команда не просыпается от алертов «истекает завтра».
