Внутренний ACME для TLS-сертификатов: офлайн продление

Проблема: сертификаты истекают и это останавливает сервисы

TLS-сертификаты почти всегда вспоминают в последний момент: когда пользователи видят предупреждение в браузере, API начинает отдавать ошибки, а клиенты VPN не подключаются. Причина простая - ручное продление держится на календаре, внимательности и доступе к нужным системам. Один пропущенный срок, один сотрудник в отпуске, одно забытое промежуточное звено в цепочке - и сервис «падает» не из-за кода, а из-за доверия.

В изолированных контурах проблема острее. «Без выхода в интернет» обычно означает, что узлы не могут:

• обращаться к публичным центрам сертификации и их проверкам;
• публиковать или обновлять записи во внешнем DNS;
• принимать входящие проверки снаружи;
• быстро ставить обновления и инструменты «как в облаке».

При этом сертификаты нужны везде, и чаще всего страдают самые заметные и критичные точки: веб-порталы и внутренние панели, API для интеграций, почтовые серверы, VPN-шлюзы, сервисы аутентификации и админки оборудования.

Когда таких сервисов десятки, ручная схема превращается в лотерею: где-то сертификат обновили, но забыли перезапустить балансировщик; где-то обновили только на одном узле кластера; где-то выдали сертификат с неверным именем. Поэтому внутренний ACME для TLS-сертификатов решает не «красоту процесса», а четыре практичные цели: непрерывность работы, единый контроль выдачи, предсказуемое продление по расписанию и аудит (кто, что, когда и на каких основаниях получил).

ACME в двух словах: роли и логика подтверждения владения

ACME - это протокол, который позволяет выпускать и продлевать TLS-сертификаты автоматически, по понятным правилам. Если говорить просто, есть три роли: клиент (агент на вашем сервере), ACME-сервер (точка, которая принимает запросы) и центр сертификации (CA), который в итоге подписывает сертификат. Клиент просит сертификат, ACME-сервер дает задание на проверку, клиент доказывает, что он правда владеет именем, и после этого CA выпускает сертификат.

Главное отличие ACME от «скрипта, который копирует сертификат» в том, что ACME привязывает выпуск к проверке владения доменом и к учетной записи (account) клиента. Плюс, протокол описывает весь цикл: запрос, проверку, выпуск, продление, отзыв. Это снижает риск «тихого» выпуска сертификатов не туда и помогает держать процесс под контролем.

Обычно используются такие проверки владения именем (challenge):

• HTTP-01: разместить токен по HTTP на домене (удобно, если есть общий входной веб-доступ к сервису).
• DNS-01: создать TXT-запись в DNS (часто самый практичный вариант внутри сегментированных сетей).
• TLS-ALPN-01: отдать токен через TLS на 443 порту (подходит, когда проще поднять временный TLS-ответ).

Внутри закрытого контура чаще всего выигрывает DNS-01: не нужно пробивать HTTP-доступ до каждого сервиса, достаточно управляемого внутреннего DNS.

Где хранится ключ, зависит от политики. Чаще ключ создается и живет на сервере приложения (там же происходит ротация). Для более строгих требований ключ можно генерировать и хранить в HSM или в хранилище секретов, чтобы снизить риск утечки и ограничить доступ администраторов.

Архитектура: из чего состоит внутренний контур ACME

Внутренний ACME для TLS-сертификатов обычно строят как небольшой контур внутри сети: отдельный сервис выдает и продлевает сертификаты, а приложения только запрашивают их и ставят на свои endpoints. Так вы убираете ручной выпуск, но сохраняете контроль.

Базовый набор компонентов выглядит так:

• ACME-сервер в локальной сети: принимает запросы на выпуск, запускает проверку владения именем и отдает готовый сертификат.
• Частный центр сертификации (CA): корневой сертификат хранится максимально изолированно, а выпуск выполняет промежуточный CA.
• DNS и DHCP: помогают держать порядок в именах и IP, а DNS часто используется для подтверждения доменов.
• Хранилище секретов: место, где безопасно хранить ключи аккаунтов ACME, токены автоматизации и, при необходимости, ключи для доступа к DNS.
• Точки интеграции: те места, где сертификат реально нужен.

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

DNS и DHCP становятся частью доверия: если кто-то может самовольно создавать записи, он сможет проходить проверку и получать сертификаты. Поэтому права на зоны, обновления и журналы изменений должны быть понятны и ограничены.

Интеграции обычно делаются через стандартные клиенты ACME и автоматическую перезагрузку конфигурации, например для:

• веб-серверов и API
• балансировщиков
• Kubernetes ingress
• reverse proxy
• почтовых и внутренних порталов

В закрытых контурах (например, в дата-центрах госорганизаций или банков) такой подход помогает поддерживать короткие сроки сертификатов без зависимости от интернета.

Доверие и контроль: как не превратить внутренний CA в "печатный станок"

Внутренний ACME для TLS-сертификатов снимает ручную работу, но добавляет риск: если правила выпускa слабые, любой сервис сможет получить сертификат на чужое имя. Поэтому в центре внимания не скорость, а доверие и контроль.

Начните с простого принципа: корневой центр (Root CA) должен быть максимально недоступен. Его держат офлайн, включают только для выпуска или ротации промежуточных центров, а доступ дают узкому кругу администраторов по регламенту. Закрытый сейф, отдельная машина без сети, журнал действий и двух человек на критические операции часто дают больше безопасности, чем сложные схемы.

Рабочей лошадкой становится промежуточный CA. Он подписывает сертификаты для ACME, живет короче (например, 1-3 года) и проще отзывается при инциденте. Важно заранее продумать ротацию: новый intermediate выпускается заранее, доверие обновляется на клиентах, затем старый выводится из обращения.

Доверие к внутреннему корню нужно раздать управляемо: на ПК и серверы через доменные политики, на мобильные через MDM, на тонкие клиенты через базовый образ или централизованную конфигурацию. Отдельно проверьте устройства в медицине и производстве, где обновления могут быть редкими.

Политики, которые держат систему в руках

Хорошая политика выпуска обычно отвечает на пять вопросов:

• Кто имеет право запрашивать выпуск (группы, сервисные аккаунты, сетевые сегменты).
• Какие имена разрешены: только ваш внутренний DNS-зонный список, запрет внешних доменов.
• Разрешены ли wildcard и какие именно (часто их стоит ограничить).
• Какие SAN допустимы (например, только внутри конкретного проекта или подразделения).
• Максимальные сроки и частота перевыпуска, чтобы не плодить "вечные" сертификаты.

Аудит: что должно оставаться в следах

Логи должны показывать цепочку: кто запросил сертификат, каким способом подтвердил владение именем, что именно выдано (CN/SAN, срок, отпечаток), и кто одобрил, если у вас есть ручной шаг. В закрытой сети, например у госзаказчика или банка, это помогает быстро ответить на вопрос "почему этот сервис получил сертификат" и вовремя остановить неправильные заявки.

Как подтверждать домены внутри: DNS, HTTP и особенности сегментации

Внутренний ACME для TLS-сертификатов упирается в одно: как доказать, что сервис действительно владеет именем, если сеть изолирована и правила доступа жесткие. Внутри контура чаще всего побеждает DNS-01, потому что он не требует прямого HTTP-доступа к сервису и хорошо работает через сегменты.

DNS-01 обычно становится базовым вариантом: ACME-клиент кладет временную TXT-запись в вашу внутреннюю DNS-зону, а ACME-сервер проверяет ее через корпоративный DNS. Это удобно, если у вас много сервисов, балансировщики, NAT и закрытые порты.

HTTP-01 тоже возможен в изолированном контуре, но он капризнее. Он подходит, когда ACME-сервер может дойти по HTTP до конкретного хоста и пути проверки, а маршрутизация и прокси не меняют запрос. Он мешает, если сервисов много, адреса плавают, все сидит за одним reverse proxy, или доступ из зоны ACME к DMZ закрыт.

Полезная развилка выглядит так:

• DNS-01: лучший выбор для закрытых сетей, DMZ, балансировщиков и wildcard
• HTTP-01: проще для одиночных сервисов, где есть прямой маршрут и стабильный URL
• Wildcard: удобно для микросервисов, но требует строгого контроля прав на выпуск

Wildcard-сертификаты (например, для *.corp.local) сокращают количество выпусков, но снижают точность контроля: один ключ может открыть доступ сразу ко многим именам. Поэтому их обычно дают только платформенным командам и только для отдельных зон.

Сегментация важна: для DMZ и внутренних зон задайте разные политики (кто может запрашивать, на какие домены, с каким сроком). Хорошая практика - отдельные аккаунты ACME и разные профили выдачи для сетей с разным уровнем риска.

Чтобы не получить "шторм" продления, введите лимиты:

• ограничение частоты выпуска на домен и на команду
• джиттер (случайный сдвиг) в расписании продлений
• блокировку массового выпуска при аварии DNS
• обязательное подтверждение для wildcard в чувствительных зонах

Например, в закрытой сети больницы сервисы в DMZ подтверждают имена через DNS-01, а внутренние панели админов получают отдельную зону и более строгие лимиты, чтобы один сбой автоматизации не остановил всю инфраструктуру.

Варианты развертывания без интернета: полностью офлайн и полуофлайн

Для внутреннего ACME для TLS-сертификатов чаще всего выбирают один из двух режимов: полностью офлайн, когда весь контур живет внутри закрытой сети, или полуофлайн, когда есть строго контролируемый "мост" только для обновлений и политик.

Полностью офлайн

В этой схеме внутри периметра находятся: частный центр сертификации (root и чаще всего отдельный intermediate), ACME сервер, база данных ACME, DNS (если вы делаете DNS-01), а также клиенты на сервисах (например, Certbot или встроенные ACME-клиенты в прокси). Никаких внешних проверок, никаких обращений к публичным DNS и никакой зависимости от внешних репозиториев.

Главный плюс - предсказуемость и безопасность. Главный минус - обновления и исправления вы делаете сами и по плану.

Полуофлайн с "мостом"

Здесь контур выпуска сертификатов остается изолированным, но появляется выделенный узел или процесс, который по расписанию привозит внутрь: обновления ОС и пакетов, новые версии ACME, списки отзыва, шаблоны конфигураций и изменения политик. Этот "мост" должен быть односторонним по смыслу: он доставляет внутрь, а не "публикует наружу".

Обновления лучше проводить окнами и сначала на стенде. Не меняйте одновременно CA, ACME и клиентов: так сложнее понять, что сломалось.

Для резервного копирования заранее решите, что восстанавливается быстро, а что перевыпускается:

• конфигурации CA и ACME, политики, профили сертификатов
• база данных ACME (аккаунты, заказы, статусы)
• журналы аудита и события выпуска и отзыва
• конфиги DNS и HTTP-челленджей (если они ваши)
• хранилища ключей только в защищенном виде (HSM, зашифрованные бэкапы)

План восстановления должен включать минимум три сценария: утечка ключа intermediate, компрометация узла ACME, ошибочный массовый выпуск. В каждом случае заранее определите, кто дает команду на отзыв, как быстро распространяются CRL/OCSP внутри, и как организован форсированный перевыпуск на критичных сервисах (например, в закрытой сети предприятия или дата-центра, который интегратор вроде GSE.kz обслуживает по SLA).

Пошагово: как внедрить внутренний ACME и включить автопродление

Начните с простого: какие имена вы будете выпускать и как долго должен жить сертификат. Зафиксируйте доменные зоны (например, *.corp.local, *.svc.intra), список критичных сервисов и правила: срок действия, минимальный остаток до продления, требования к ключам (RSA или ECDSA), где хранить ключи.

Дальше важно построить цепочку доверия. Создайте root CA (лучше держать офлайн) и intermediate CA для повседневной выдачи. В политиках задайте: какие имена разрешены, какие поля обязательны, кто имеет право запрашивать сертификаты, и как вы будете отзывать их при компрометации.

Когда CA готов, разверните внутренний ACME для TLS-сертификатов: ACME-сервер в локальной сети, который принимает запросы от клиентов, проверяет владение именем и выпускает сертификат через ваш intermediate CA. Отдельно продумайте журналирование и аудит: кто запросил, для какого имени, с какого хоста.

Практический план внедрения обычно выглядит так:

• Описать доменные зоны, стандарты имен и требования по срокам.
• Поднять root и intermediate CA и утвердить политики выпуска.
• Развернуть ACME-сервер и подключить его к intermediate CA.
• Настроить DNS-автоматизацию для DNS-01: какой сервис меняет записи и под какой учеткой.
• Настроить ACME-клиенты на серверах приложений и безопасную перезагрузку сервисов после обновления.

Завершите тестом: выпустите сертификат для одного непубличного сервиса, проверьте цепочку доверия на клиентах, затем дождитесь планового продления (или сократите порог) и убедитесь, что обновление проходит без простоя. После этого включайте регулярное продление для остальных сервисов по группам, начиная с менее критичных.

Контроль сроков: мониторинг, оповещения и отчетность

Автопродление не отменяет контроля. Внутренний ACME для TLS-сертификатов снимает ручную работу, но добавляет новую задачу: быстро замечать сбои в цепочке (ACME сервер, challenge, выпуск, доставка, перезапуск сервиса) до того, как сертификат истечет.

Что стоит измерять и держать на одном экране:

• Дни до истечения по каждому имени (и отдельно по критичным сервисам)
• Процент успешных продлений за 24 часа и за 7 дней
• Частые причины провалов: DNS/HTTP challenge, недоступность ACME, ошибки прав
• Возраст сертификатов и доля тех, что обновились не по графику
• Время от запроса до установки сертификата на узле

Проверять лучше в двух местах. Централизованно - чтобы видеть общую картину по всем сегментам. И локально на узлах - чтобы поймать ситуацию, когда сертификат выпущен, но не применился (файл не обновился, сервис не перезапустился, перепутан путь к хранилищу).

Оповещения задайте простыми порогами: 30/14/7/1 день до истечения. На 30 дней достаточно уведомления владельцу сервиса. На 7 и 1 день - дежурной смене и тем, кто отвечает за DNS/прокси, чтобы не терять время на согласования.

Для разборов нужны журналы: выпуск и отзыв сертификата, попытки challenge, изменения DNS-записей, перезапуски веб-серверов и балансировщиков. Раз в месяц делайте аудит: список активных сертификатов, где установлены, кто владелец, и какие имена больше не нужны. Это снижает риск, что внутренний CA превратится в неконтролируемую выдачу "на все подряд".

Частые ошибки и ловушки при внутреннем ACME

Внутренний ACME для TLS-сертификатов часто внедряют «как в интернете», а потом удивляются, что стало даже опаснее. Ниже ошибки, которые встречаются чаще всего, и почему они реально бьют по безопасности и стабильности.

Ошибки, которые ломают управляемость

Самая популярная ловушка - выпускать слишком долгоживущие сертификаты «на всякий случай». Кажется, что так меньше шансов на простой, но на деле вы теряете контроль: компрометация ключа становится проблемой на годы, а не на недели.

Еще одна крайность - один wildcard на все сервисы. Это удобно, пока не утек приватный ключ. Тогда под угрозой сразу весь контур, и вы не можете ограничить ущерб по сегментам или командам.

Проблемы часто начинаются и с доверия: root CA раздают «кому надо» без учета мобильных ноутбуков, изолированных рабочих мест и временных подрядчиков. В итоге где-то доверие не установлено (сервисы падают), а где-то установлено слишком широко (растет риск подмены).

Ошибки в хранении и эксплуатации

Технически внутренний ACME сервер в локальной сети работает, но процессы вокруг него хромают:

• приватные ключи попадают в общие папки, артефакты сборки или CI-логи
• нет плана отзыва и быстрой замены при компрометации
• автопродление включили, но не проверили, что сервис перечитывает сертификат (нужен reload или перезапуск)

Простой пример: сертификат обновился ночью, а утром часть клиентов видит старый, уже просроченный цепочкой, потому что прокси не перечитал файлы. Поэтому автопродление всегда дополняют тестом перезагрузки и проверкой «что реально отдает сервис».

Короткий чек-лист перед запуском в эксплуатацию

Перед тем как включать автопродление в проде, проверьте не только сам ACME сервер, но и организационные вещи. Ошибки чаще всего не в криптографии, а в том, что никто не понимает, где живут сертификаты и кто за них отвечает.

5 проверок, которые экономят недели

• Соберите инвентаризацию всех TLS-точек: веб и API, reverse proxy, ingress, брокеры очередей, базы данных, почта, внутренние панели. Если что-то забыть, оно и упадет первым.
• Определите владельцев доменов и правила выдачи: какие имена разрешены, кто может запрашивать wildcard, какие команды или сервис-аккаунты имеют право выпускать сертификаты.
• Разведите роли CA: Root CA держите изолированным (и используйте редко), а intermediate CA сделайте ротационным, с коротким сроком жизни и минимальными правами. Проверьте, что ключи защищены и есть понятный порядок замены.
• Выберите один основной challenge и отработайте его до автоматизма. В закрытых сетях обычно выигрывает DNS challenge, но важно заранее проверить права на изменение зон, задержки обновления и сегментацию между ACME, DNS и клиентами.
• Настройте контроль сроков: метрики, оповещения, отчеты, плюс тест аварийного продления (например, искусственно сократить срок тестового сертификата и убедиться, что цепочка продления работает).

Документы и аварийные действия

Зафиксируйте процесс отзыва и срочной замены сертификатов: кто принимает решение, как быстро обновляются trust stores, и как откатиться, если новый сертификат не принимается клиентами. Это должно быть понятно дежурной смене, а не только автору внедрения.

Пример сценария: закрытая сеть и десятки внутренних сервисов

Представим банк или больницу с закрытым контуром: интернет на серверах приложений запрещен, доступ есть только через внутренние сегменты, а простои недопустимы. Внутри работают десятки сервисов: регистратура, личный кабинет, электронный документооборот, API для интеграций, панели администрирования.

Имена обычно живут в внутреннем DNS. Часто есть отдельная зона для приложений, чтобы не смешивать серверные имена и пользовательские: например, apps.corp для веб-сервисов и infra.corp для инфраструктуры. Это помогает и с политиками доступа, и с тем, кто имеет право менять записи.

Дальше включается внутренний ACME для TLS-сертификатов. В контуре поднимают частный центр сертификации и ACME-сервер в локальной сети, а на каждом сервисе ставят ACME-клиент. Для подтверждения владения доменом выбирают DNS-01: клиент создает временную TXT-запись в внутреннем DNS, ACME-сервер ее проверяет и выпускает сертификат.

Обычно процесс выглядит так:

• ACME-клиент раз в сутки проверяет срок действия и запускает продление заранее.
• При успехе он кладет новый сертификат в нужный каталог.
• Сервис (например, веб-сервер) получает мягкий перезапуск, чтобы подхватить ключи без простоя.

Контроль сроков делают не вручную, а через дашборд в мониторинге: видно, сколько сертификатов истекает в 30, 14 и 7 дней. Алерты уходят дежурным, а раз в месяц формируется короткий отчет для ИБ и владельцев систем.

Для команды это заметная разница: меньше ночных аварий из-за просроченных сертификатов, меньше ручных заявок, больше предсказуемости. В таком сценарии CA и ACME-сервер часто размещают на выделенных локальных серверах (например, на стойке в ЦОД), чтобы все работало стабильно и без зависимости от внешних каналов.

Следующие шаги: пилот, масштабирование и поддержка

Начните не с установки ACME, а с учета. Соберите список сервисов, которые уже используют TLS, и тех, кто планирует включить HTTPS в ближайшие месяцы. Важно сразу назначить владельцев: кто отвечает за доменные зоны, кто за DNS, кто за балансировщики и кто будет получать уведомления.

Дальше выберите целевую модель: полностью офлайн (вся цепочка внутри) или полуофлайн (например, редкая синхронизация политик и обновлений через контролируемый шлюз). Решение влияет на план миграции: где хранить корневой ключ, как обновлять доверие на рабочих станциях и серверах, как выпускать сертификаты для старых приложений.

Перед пилотом проверьте, что инфраструктура готова к ежедневной эксплуатации:

• Разделение ролей: CA, ACME и мониторинг не должны жить в одной точке без причин
• Резервное копирование: ключи, конфигурации, журналы, база выданных сертификатов
• Наблюдаемость: метрики выдачи, ошибки валидации, рост числа запросов
• Контроль доступа: минимум прав для сервисных аккаунтов, аудит действий
• План аварийных действий: что делать при компрометации ключа или сбое ACME

Пилот делайте на 2-3 сервисах с разной природой: один веб-сервис за балансировщиком, один внутренний API, один сервис в отдельном сегменте. Так быстрее выявятся проблемы с DNS, маршрутизацией и политиками. Зафиксируйте, сколько времени занимает выпуск, продление и раскатка сертификата, и кто реально участвует в процессе.

Масштабирование лучше вести волнами: по доменным зонам или по командам-владельцам. Для каждой волны заранее готовьте шаблоны политик (сроки, SAN, допустимые ключи, правила именования), а также критерии приемки: автопродление работает, мониторинг видит сроки, инциденты разбираются по логам.

Если нужна помощь в проектировании и внедрении, логично подключить системного интегратора. Например, GSE.kz может помочь собрать целевую схему под ваш контур, подобрать серверную платформу для CA и ACME (включая локально произведенные серверы), настроить мониторинг и организовать поддержку 24/7 с понятной зоной ответственности.