ACME (Automatic Certificate Management Environment) сделал то, что админы любят больше всего: убрал ручную рутину вокруг TLS. Сертификат выпускается и продлевается автоматически, часто бесплатно, и HTTPS становится «фоновым процессом». Но в проде вопрос обычно звучит не «SSL vs ACME», а «какая модель управления сертификатами и какие гарантии я реально получаю».
Под «SSL» в быту часто понимают любой серверный сертификат, хотя корректнее говорить про TLS. В статье я использую термин «SSL-сертификат» как общепринятый и сравниваю две практики эксплуатации: коммерческий сертификат от УЦ (commercial certificate) и выпуск через ACME (чаще всего — публичные УЦ, например Let’s Encrypt).
Что именно сравниваем: протокол ACME и тип сертификата
Сначала важно развести понятия:
- ACME — протокол автоматизации выпуска и продления. Его реализуют клиенты вроде certbot, lego, acme.sh, а также встроенные решения в reverse proxy/ingress.
- Сертификат — результат выпуска: DV/OV/EV, с разными документами, SLA, условиями поддержки и юридическими оговорками.
Отсюда ключевой вывод: коммерческий УЦ тоже может поддерживать ACME, а бесплатный DV можно выпустить вручную без ACME. В эксплуатации сравнивают не «транспорт», а совокупность: уровень проверки, процесс, поддержку, контроль рисков и предсказуемость.
DV/OV/EV: где начинается compliance
В публичных ACME-УЦ почти всегда речь про DV (Domain Validation): УЦ проверяет контроль над доменом. Это быстро, дёшево и отлично подходит для большинства сайтов, API и внутренних админок, если модель «домен подтверждён — достаточно» вас устраивает.
OV (Organization Validation) и EV (Extended Validation) добавляют проверку организации и набор документов. В современных браузерах EV не даёт заметной «магии интерфейса», но OV/EV всё ещё бывают важны не для UI, а для:
- compliance: внутренние политики, требования контрагентов, аудит;
- понижения риска «серый домен + DV» в цепочках поставок, когда важно подтвердить юрлицо, а не только владение доменом;
- закупок и ответственности: кто, на каких условиях и с какими процедурами выпускает сертификаты.
Если аудитору/банку нужно подтверждение организации, это решается не самим ACME, а уровнем валидации (OV/EV) и документами, которые выдаёт УЦ.
Warranty: что это и почему к ней нельзя относиться как к страховке «от всего»
Warranty в сертификатах — финансовая гарантия со стороны УЦ на определённых условиях (обычно если ошибка УЦ привела к ущербу). В коммерческих сертификатах warranty встречается заметно чаще и выглядит внушительно в описании продукта.
Прагматичная позиция инженера:
- warranty не заменяет вашу ответственность за приватные ключи, конфигурацию TLS и цепочку доверия;
- в условиях почти всегда есть «мелкий шрифт»: корректная установка, соблюдение регламента, отсутствие компрометации ключа по вашей вине и т.д.;
- для многих компаний важнее не «сумма warranty», а наличие контакта поддержки, процедур, сроков реакции и бумажного следа.
Но как элемент risk management warranty может быть полезна: её проще «упаковать» для ИБ и юристов как часть формального решения.
Support и SLA: где коммерческий сертификат выигрывает у бесплатного DV
В продакшне стоимость сертификата почти всегда меньше стоимости простоя. Поэтому support и SLA — один из самых приземлённых критериев выбора.
Что часто даёт коммерческий УЦ (конкретика зависит от вендора и тарифа):
- помощь по установке и цепочке (как собрать fullchain, какой intermediate нужен, что делать со старыми клиентами);
- понятные процедуры перевыпуска и отзыва (reissue/revoke) и ожидаемые сроки реакции;
- помощь в спорных кейсах: подозрение на компрометацию ключа, неправильный выпуск, вопросы по валидации организации;
- предсказуемость «кто отвечает»: договор, документы, единая точка эскалации.
В модели «бесплатный DV + ACME» вы чаще полагаетесь на:
- собственные компетенции и runbook’и;
- сообщество и публичную документацию;
- мониторинг истечения и ошибок TLS на своей стороне.
Это не «плохо» и не «хорошо» — это про зрелость эксплуатации. Если у вас IaC, единые шаблоны nginx/haproxy/ingress и централизованный мониторинг, бесплатный DV может быть отличным выбором.
Compliance: где ACME «не проходит» не технически, а организационно
ACME закрывает выпуск и продление, но compliance — это шире, чем «сертификат валиден». Обычно аудит и ИБ смотрят на процесс:
- кто имеет право выпускать сертификаты на домены компании;
- как хранится приватный ключ (секрет-хранилище, политики доступа, ротация);
- как оформляются изменения (change management) и кто утверждает выпуск;
- как ведётся инвентаризация сертификатов, владельцев, сроков, наблюдение за публикациями в CT;
- как выполняются требования стандартов и внутренних политик (включая требования к управлению ключами и настройкам TLS).
ACME отлично вписывается в compliance, если вы заранее построили governance: разделили аккаунты, ограничили права, логируете операции, а ключи защищаете не «по остаточному принципу».
Но если в компании процесс устроен как «сертификаты покупает закупка, выпуск контролирует ИБ, ответственность закреплена договором», то коммерческий сертификат часто проще легализовать организационно.
Сроки жизни, риски продления и «цена» автоматизации
Публичные ACME-сертификаты обычно короткоживущие. Это уменьшает окно риска при компрометации ключа, но делает качество автоматизации критичным: одно неудачное продление легко превращается в инцидент.
Типовые точки отказа в ACME-автоматизации:
- HTTP-01: закрыли 80 порт, поменяли редиректы, включили глобальную авторизацию, и challenge стал недоступен;
- DNS-01: сломалась интеграция с DNS API, изменились токены/права, вырос TTL, упёрлись в rate limit;
- деплой: сертификат обновился на диске, но сервис не перечитал его (не тот reload, другой контейнер, другой unit);
- цепочка: обновился intermediate, а вы продолжаете отдавать старый bundle;
- «спящие» домены: сервис выключили, а сертификат всё ещё нужен интеграциям, и продление внезапно стало невозможным.
Если у вас много SAN и вы активно создаёте/удаляете имена, полезно заранее понять лимиты и модель выпуска. По этой теме пригодится материал про лимиты Let’s Encrypt и автоматизацию массовых выпусков.
ACME в корпоративной инфраструктуре: сегментация, прокси, мульти-тенант
В реальной компании ACME «упирается» не в криптографию, а в периметр и процессы:
- Сегментация сети: edge стоит за балансировщиками, входящий трафик ограничен, а HTTP-01 требует доступности извне.
- Мульти-тенант: десятки проектов на одном прокси. Ошибка в маршрутизации challenge задевает всех.
- Change freeze: вы не хотите, чтобы автопродление инициировало reload в период запрета изменений.
- Единые секреты: общий DNS API токен на всю компанию — риск домино при утечке.
Обычно это решается архитектурно: раздельные аккаунты и токены, разделение зон, canary-проверки продления, отдельный слой терминации TLS, централизованный выпуск через cert-manager/аналог, регламент на reload. Но это работа, и её нужно честно закладывать в стоимость владения.
Техническая сторона TLS: сертификат не спасёт от плохой конфигурации
Ошибка мышления — обсуждать «SSL vs ACME» так, будто сертификат сам по себе определяет безопасность. На практике TLS чаще ломают другое:
- устаревшие протоколы и наборы шифров из-за попытки поддержать очень старых клиентов;
- неверная цепочка (missing intermediate, неправильный bundle);
- слабая защита приватных ключей (права на файлы, бэкапы, секреты в CI);
- ошибки SNI на мультидоменном фронте;
- отсутствие мониторинга истечения и ошибок рукопожатия.
Рекомендую держать под рукой единый базовый профиль настроек и периодически сверяться с актуальными практиками. В помощь: best practices по SSL/TLS для продакшна.
Практическая матрица выбора: что брать и когда
Ниже — короткая логика выбора, которую удобно применять как чек-лист для проекта.
Когда ACME (обычно бесплатный DV) — лучший вариант
- много доменов/субдоменов, частые изменения, инфраструктура как код;
- вы можете обеспечить стабильный HTTP-01 или надёжный DNS-01;
- есть мониторинг истечения и алерты на ошибки продления;
- нет требований к OV/EV и пакету документов, а compliance закрывается внутренними контролями;
- вы готовы поддерживать автоматизацию сами (runbook + наблюдаемость).
Когда коммерческий сертификат проще и безопаснее процессно
- нужны OV/EV, документы и формальные подтверждения для аудита/контрагентов;
- важны warranty и юридическая рамка ответственности (пусть и с условиями);
- нужен вендорский support с понятным каналом эскалации;
- выпуск/перевыпуск должен идти через утверждения и контроль ИБ/закупок;
- инфраструктура нестабильна для автоматических челленджей (сложный периметр, строгий WAF, частые блокировки портов).
Комбинированный подход: «ACME везде» и «платное на критичных точках»
Часто выигрывает гибрид:
- для большинства веб-сервисов и API — ACME DV с нормальной автоматизацией;
- для витринных доменов компании, B2B-кабинетов, платёжных страниц и точек с повышенными требованиями — коммерческий сертификат (часто OV) и формализованный процесс;
- для части инфраструктуры (где это оправдано) — внутренняя PKI и короткоживущие сертификаты для сервисной идентификации и mTLS.
Так вы не переплачиваете за «везде платное», но и не загоняете критичные бизнес-системы в модель, которую тяжело защитить процессно.
Что проверить перед выбором: вопросы, которые экономят время
- Кто владелец домена и кто имеет право выпускать сертификаты? Это governance, а не openssl.
- Какие требования к compliance? Нужны ли OV/EV, документы, договор, процедуры?
- Где терминируется TLS? На edge-прокси, LB, ingress или на каждом приложении.
- Какая стратегия приватных ключей? Ротация, доступы, хранение, бэкапы, секреты CI.
- Что будет, если автопродление не сработало? Нужны алерты заранее и понятный ручной план B.
- Нужен ли support? Не «в целом», а в сценариях: инцидент, перевыпуск, смена домена, компрометация, массовая ротация.
Итог: SSL vs ACME — это про риски, процессы и ответственность
ACME — отличный способ автоматизировать выпуск и продление TLS и снизить вероятность человеческих ошибок «забыли продлить». Но коммерческий сертификат — это не просто «платно», а пакет из поддержки, документов для compliance и условий warranty, который проще встроить в корпоративные процессы.
Если у вас зрелая эксплуатация (мониторинг, IaC, шаблоны конфигураций, дисциплина ключей) — ACME закрывает большую часть задач быстрее и дешевле. Если критичны юридические и аудиторские аспекты, нужна поддержка и формальная ответственность — коммерческий сертификат часто окупается снижением организационных рисков.
И в обоих случаях помните: безопасность TLS определяется не ценником сертификата, а конфигурацией, хранением ключей и качеством процессов вокруг них.
Если вам нужна «железобетонная» базовая связка для продакшна (сертификаты, домены, переносы), удобно держать всё в одном месте: регистрация доменов и SSL-сертификаты закрывают формальную часть, а дальше всё решает эксплуатация.
