Мой дэйли дайджест

одно техническое понятие в день

ACME

3 августа 2026 · ~13 мин чтения

протокол безопасность tls автоматизация сертификаты

ACME

ACME (Automatic Certificate Management Environment) — протокол, по которому
сервер сам, без участия человека, доказывает удостоверяющему центру, что
владеет доменом, и получает TLS-сертификат. Именно на нём построен Let's
Encrypt и вся современная «бесплатная HTTPS-инфраструктура» интернета.

История

Что это такое

ACME — это HTTPS-протокол общения двух программ: ACME-клиента (стоит на
твоём сервере) и ACME-сервера (стоит у удостоверяющего центра, например
Let's Encrypt). Клиент говорит: «Хочу сертификат для домена blog.example.ru».
Сервер отвечает: «Докажи, что ты — владелец этого домена. Вот задание».
Клиент выполняет задание, сервер проверяет, всё сходится — выдаёт сертификат.

Ключевая идея — машинная верификация владения доменом (Domain Control
Validation, DCV). Никаких паспортов, юридических лиц, звонков в офис.
Только техническое доказательство: «я контролирую этот домен прямо сейчас».
Из этого следует важное ограничение — ACME умеет выдавать только
сертификаты уровня DV (Domain Validation). То есть браузер увидит
«соединение защищено», но никакой информации об организации в сертификате
не будет. Для сертификатов уровня OV или EV (Extended Validation, с
проверкой юрлица и зелёной строкой в старых браузерах) ACME не подходит —
там нужна ручная проверка документов.

Отличие от старой модели («X vs Y»):

Аналогии из жизни

1. Пропуск в офисный центр по коду из СМС.

Раньше пропуск делали так: приходишь на ресепшн, показываешь паспорт,
охранник звонит в компанию, тебе печатают бумажный пропуск на месяц.
Через месяц — снова. ACME похож на систему, где ты один раз привязал свой
телефон, и дальше при каждом входе тебе приходит СМС с кодом. Твоё
владение номером — доказательство личности; охраннику ничего проверять
руками не надо.

Где ломается: аналогия плохо работает, когда СИМ-карту крадут — ACME
устроен так, что «доступ к домену» это и есть личность в его картине
мира, никакого «настоящего тебя» за пределами этого нет. Если кто-то
захватил твой домен, он для CA становится тобой. В офисной аналогии
владелец здания всё-таки может выгнать самозванца, у ACME такого
арбитра нет.

2. Регистрация водителя в такси через фото машины.

Представь, что чтобы стать водителем такси, тебе не нужны документы: ты
просто фотографируешь свою машину рядом со специальным QR-кодом, который
диспетчер попросил именно тебя разместить (кто-то другой не мог знать,
где его размещать). Диспетчер видит фото — регистрирует. С ACME так же:
CA просит клиента положить конкретный файл в конкретное место, куда
может дотянуться только владелец домена.

Где ломается: машина — физическая вещь, украсть её сложно. Домен —
запись в базе данных регистратора. Захват аккаунта у регистратора
доменов делает атаку тривиальной. Именно поэтому ACME сам по себе не
решает проблему «а если у меня угонят домен» — тут нужны отдельные
защиты (регистр-локи, DNSSEC, CAA-записи).

3. Автопродление подписки на журнал.

Раньше журналы приходилось выписывать заново каждый год: платил,
получал наклейку с индексом, шёл на почту. Сейчас — списывают с карты
автоматически, доставка не прерывается. ACME превратил TLS-сертификаты
из «раз в год руками» в «раз в 60 дней тихо и автоматически». Ты даже
не знаешь, когда именно это происходит.

Где ломается: у автопродления журнала есть длинная память — если карта
испортилась, у почты остаются старые данные и она может задержать
списание. У сертификатов такой снисходительности нет: если автообновление
не сработало и старый сертификат истёк — сайт мгновенно отдаёт «Ваше
соединение не защищено», трафик обваливается. Мониторинг на срок
действия — обязательный.

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

Разберём типичный сценарий: сервер хочет получить сертификат для
blog.example.ru.

Шаг 1. Регистрация аккаунта.
Клиент генерирует пару ключей (обычно RSA 2048 или ECDSA P-256). Публичный
ключ отправляет ACME-серверу вместе с email для аварийных уведомлений.
Сервер создаёт учётную запись, привязывает её к публичному ключу. Дальше
все запросы клиента подписываются приватным ключом — так CA понимает,
что запрос идёт от того же аккаунта.

Шаг 2. Newnonce (одноразовый маркер).
Каждый запрос в ACME должен содержать одноразовый nonce, полученный от
сервера. Это защита от replay-атак — злоумышленник не может перехватить
твой подписанный запрос и повторить его. Клиент делает HEAD /new-nonce,
получает заголовок Replay-Nonce, кладёт его в следующий запрос.

Шаг 3. New Order (заказ на сертификат).
Клиент шлёт: «Хочу сертификат на такие-то identifier'ы» (списки доменов).
Сервер отвечает объектом Order с массивом Authorization'ов — по одному
на каждый домен. Authorization содержит массив Challenge'ей.

Шаг 4. Выбор challenge (проверки).
Для каждого домена CA предлагает несколько способов доказать владение.
Клиент выбирает один. Основные три:

Шаг 5. Клиент выполняет challenge.
Например, для HTTP-01 создаёт файл с содержимым <токен>.<хэш публичного ключа> в .well-known/acme-challenge/. Или обращается к nginx-конфигу
и добавляет специальный location-блок. Именно эту работу выполняли
плагины webroot, standalone, nginx у certbot.

Шаг 6. Клиент дёргает сервер: «Готов, проверяй».
Отправляет запрос на URL challenge'а. Сервер запускает валидатор — идёт
за файлом или DNS-записью с нескольких точек мира (multi-perspective
validation, введено Let's Encrypt в 2020 году как защита от BGP-атак).
Если всё сходится — статус Authorization становится valid.

Шаг 7. Finalize.
Когда все Authorization'ы для Order'а стали valid, клиент генерирует
приватный ключ для будущего сертификата, формирует CSR (Certificate
Signing Request — файл с публичным ключом и списком доменов, подписанный
приватным ключом сертификата) и отправляет его на URL finalize. CA
подписывает CSR своим intermediate-ключом, получается сертификат.

Шаг 8. Скачивание.
Клиент периодически опрашивает URL Order'а. Когда статус — valid,
скачивает готовый сертификат вместе с промежуточными сертификатами
(certificate chain). Кладёт куда нужно (обычно /etc/letsencrypt/live/<домен>/),
перезагружает веб-сервер.

Шаг 9. Через ~60 дней — повторить.
Сертификаты Let's Encrypt действуют 90 дней. Рекомендуется обновлять на
60-м дне — остаётся месяц запаса на случай проблем. Клиент запускается
по крону (или systemd-таймеру), проверяет срок действия, если пора —
повторяет шаги 3–8. Аккаунт уже существует, ключи уже есть — обычно
занимает секунды.

Клиент                                  ACME-сервер (Let's Encrypt)
   |                                             |
   |-- POST /new-account (публичный ключ) ------>|
   |<---------------------- 201 (аккаунт создан) |
   |                                             |
   |-- POST /new-order (домены) ---------------->|
   |<---- 201 (Order + список Authorization URL) |
   |                                             |
   |-- GET /authz/... --------------------------->|
   |<--------------------- challenges (HTTP/DNS) |
   |                                             |
   |  ... клиент выполняет HTTP-01 challenge ... |
   |                                             |
   |-- POST /challenge/... (готов) ------------->|
   |                                    (валидатор идёт за файлом)
   |<------------------------- valid / invalid   |
   |                                             |
   |-- POST /finalize (CSR) -------------------->|
   |<------------------------- Order: processing |
   |-- GET /order/... --------------------------->|
   |<------------- Order: valid + certificate URL|
   |-- GET /cert/... ---------------------------->|
   |<--------------------- PEM: cert + chain     |

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Кто пользуется

Масштаб: Let's Encrypt отдаёт около 8 миллионов сертификатов в день. Их
инфраструктура — примерно 10 датацентров, шифруется чуть ли не половина
всего интернета.

Альтернативы и конкуренты

Когда НЕ стоит использовать

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера половина рабочего дня ушла на восстановление TLS-сертификатов на
нескольких доменах, где после переезда сломалась цепочка renew: certbot
не мог пройти HTTP-01 challenge из-за того, что nginx-конфиг раньше
отдавал 301 на HTTPS вместо того, чтобы обслуживать
/.well-known/acme-challenge/ по HTTP. Ползали по webroot-плагину,
чинили location-блоки, разбирали, почему LE-валидатор ходит на
Fornex-адрес, а не на реальный сервер. Пока это чинил — стало
очевидно, что понимание ACME на уровне «протокол между клиентом и CA»
экономит часы: сразу видно, где в этой цепочке лежит поломка.

Краткое резюме