ACME‑клиенты для SSL: Certbot, lego, acme.sh и builtin‑интеграции

В 2025 году ACME стал стандартным способом получать и продлять SSL‑сертификаты не только у Let’s Encrypt, но и у множества коммерческих центров сертификации. Если раньше «поставить HTTPS» значило один раз сгенерировать CSR и раз в год руками обновлять сертификат, то теперь это скорее задача о том, каким ACME‑клиентом и как именно автоматизировать процесс.

В этой статье посмотрим на четыре распространённых подхода:

• классический Certbot (Python);
• универсальный lego (Go‑утилита, библиотека, основа для многих тулов);
• скриптовый acme.sh (pure shell);
• builtin‑интеграции: встроенные клиенты в веб‑серверах, панелях и оркестраторах.

Фокус — продакшен‑сценарии для админов и DevOps: какие клиенты проще тащить в CI/CD, какие удобнее в монолитной установке на VDS или на виртуальном хостинге, а какие — в Kubernetes или PaaS.

Кратко об ACME и Let’s Encrypt

ACME (Automatic Certificate Management Environment) — это протокол, по которому клиент доказывает центру сертификации, что он контролирует домен, и получает подписанный сертификат.

Ключевые типы челленджей, которые нас интересуют:

• http-01 — CA ходит по HTTP на порт 80 и проверяет, что там лежит специальный токен;
• dns-01 — CA проверяет наличие TXT‑записи в DNS для домена;
• tls-alpn-01 — реже используется, проверка по TLS‑расширению ALPN на 443 порту.

От выбранного челленджа зависят требования к инфраструктуре:

• http-01 проще всего поднять на одном веб‑сервере с публичным 80 портом;
• dns-01 нужен для wildcard‑сертификатов и сложных схем с несколькими фронтендами, где 80 порт занят или недоступен;
• tls-alpn-01 удобен там, где HTTP‑трафика нет, но есть прямой TLS (reverse‑proxy, gRPC, MQTT over TLS и т.п.).

Все рассматриваемые клиенты так или иначе поддерживают эти режимы, но с разной степенью удобства и количеством готовых плагинов. Если вы только начинаете разбираться в теме wildcard‑сертификатов и DNS‑челленджей, посмотрите также обзор практики в материале об автоматизации wildcard‑SSL через dns-01.

Certbot: «дефолтный» ACME‑клиент для новичков и не только

В массовом сознании ACME почти синоним Certbot — это официальный клиент Let’s Encrypt, написанный на Python. Во многих дистрибутивах он тащит за собой плагины для Apache, Nginx, standalone‑режим и кучу обвязки.

Преимущества Certbot

• Удобный интерактивный режим. Для небольшого сервера с Apache/Nginx можно буквально за пару команд получить и сразу подключить сертификат.
• Плагины для веб‑серверов. Certbot умеет сам лезть в конфиги Apache/Nginx, добавлять временные location для http-01, прописывать ssl_certificate, ssl_certificate_key и т.д.
• Поддержка нескольких ACME CA. Хоть он и ассоциируется с Let’s Encrypt, через опцию --server можно указать другой совместимый endpoint.
• Интеграция с пакетными менеджерами. В Debian/Ubuntu/RHEL‑семействе есть готовые пакеты, часто уже с таймерами для авто‑продления.

Недостатки Certbot

• Тяжёлый стек. Python, зависимости, плагины — не всегда удобно для минималистичных контейнеров или embedded‑окружений.
• Ограничения по DNS‑API. Есть плагины dns-*, но покрытие не такое широкое, как у acme.sh, и установка их через пакеты иногда болезненна.
• Монолитный подход. Certbot рассчитан на «один сервер, один Certbot, локальные ключи». В микросервисной архитектуре это не всегда то, что нужно.

Базовый сценарий с Certbot

Классический путь: веб‑сервер на том же хосте, где Certbot, челлендж http-01, автоматическое продление через systemd‑таймер.

certbot certonly --nginx -d example.com -d www.example.com

Или через standalone, когда Nginx/Apache временно останавливается:

certbot certonly --standalone -d example.com --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx"

Для автоматического продления достаточно убедиться, что сервис certbot.timer активен, или добавить свой cron‑задание.

DNS‑челленджи с Certbot

DNS‑челлендж особенно важен для wildcard‑сертификатов *.example.com. В Certbot это обычно делается через плагины вида python3-certbot-dns-cloudflare, python3-certbot-dns-route53 и т.п. Есть и generic‑плагины, позволяющие дергать внешний скрипт.

Но если у вас менее популярный DNS‑провайдер, может оказаться, что простого официального плагина нет, и именно здесь на сцену выходят другие клиенты.

lego: ACME‑движок в виде CLI и библиотеки

lego — это ACME‑клиент на Go, который часто не виден напрямую: он встроен во множество других решений. Например, в некоторые reverse‑proxy, Kubernetes‑контроллеры и прочие инструменты автоматизации. Сам по себе lego — это и библиотека, и CLI‑утилита.

Чем lego удобно

• Огромный набор DNS‑провайдеров. Поддержка десятков API: от популярных облаков до экзотики; для dns-01 это один из самых богатых инструментов.
• Статически скомпилированный бинарник. Удобно таскать в контейнерах и минимальных системах без Python/Perl/прочего.
• Гибкая библиотека. Можно встроить lego прямо в своё приложение или кастомный контроллер.

Минусы lego

• Меньше «маги» вокруг веб‑серверов. В отличие от Certbot, lego не умеет сам менять конфиги Apache/Nginx: это задача на вашу автоматизацию.
• Немного выше порог входа для тех, кто привык к интерактивным режимам и «сделайте всё за меня».

Пример использования lego

Получаем сертификат через http-01, если у нас есть отдельный сервер для челленджа (встроенный webserver в lego):

lego --email admin@example.com --domains example.com --http :80 --accept-tos run

Для dns-01 lego использует переменные окружения с кредами DNS‑провайдера. Например, для Cloudflare (примерно):

export CLOUDFLARE_DNS_API_TOKEN="token-value"
lego --email admin@example.com --domains example.com --dns cloudflare --accept-tos run

Дальше остаётся интегрировать выпущенные сертификаты в деплой: положить в общий secret, перезагрузить nginx‑pods, обновить конфиг reverse‑proxy и т.д.

acme.sh: лёгкий и гибкий shell‑клиент

acme.sh — это ACME‑клиент, написанный на POSIX‑совместимом shell. Он не требует Python/Go и ставится простой инсталляцией в домашний каталог. На практике это один из самых популярных клиентов на VPS и небольших серверах, особенно когда нужно много DNS‑интеграций.

Плюсы acme.sh

• Минимальные зависимости. Нужны только стандартные утилиты типа curl, openssl, sed.
• Очень широкая поддержка DNS‑API. Поддерживаются десятки, если не сотни провайдеров. Шанс, что ваш провайдер есть в списке, очень высок.
• Гибкость. Можно указывать «хуки» до и после выпуска сертификатов, строить сложные сценарии с рестартом сервисов, синхронизацией ключей на другие хосты и т.п.
• Удобная работа с профилями. Можно подключать разные аккаунты для разных CA, хранить всё в ~/.acme.sh и не засорять системный /etc.

Минусы acme.sh

• Требует аккуратности. Поскольку всё на shell, любая опечатка в хуках или окружении легко ломает процесс.
• Нет тесной связи с веб‑серверами. Нет волшебной кнопки «сделайте мне HTTPS в Apache», всё конфигурируется руками.

Базовые команды acme.sh

Установка (по сути, скачивание скрипта и развёртывание в ~/.acme.sh):

curl https://get.acme.sh | sh

Получение сертификата через http-01 на уже работающем веб‑сервере (acme.sh положит токен в указанную директорию):

acme.sh --issue -d example.com -w /var/www/example

Wildcard через DNS‑челлендж и DNS‑API (структура команды, конкретное имя провайдера и переменные окружения зависят от него):

export CF_Token="token-value"
export CF_Account_ID="account-id"
acme.sh --issue -d example.com -d *.example.com --dns dns_cf

Установка выданного сертификата в нужный путь и запуск нужного рестарта/релоада:

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 "systemctl reload nginx"

По умолчанию acme.sh создаёт собственное cron‑задание для периодической проверки и продления сертификатов.

Builtin‑решения: Caddy, Traefik, панели и оркестраторы

Отдельный класс решений — это когда ACME‑логика встроена прямо в веб‑сервер, reverse‑proxy, панель управления или оркестратор. В этом случае вам не нужно явно ставить certbot/lego/acme.sh: вы просто включаете авто‑TLS, настраиваете домен — и дальше всё происходит само.

Кому подходят builtin‑клиенты

• Малые и средние проекты, где хочется минимум ручной работы: указал домен, включил HTTPS в панели — и забыл.
• Контейнерные окружения, где есть ingress‑контроллер или сервис‑мэш, берущий на себя управление сертификатами.
• Разработчики, которым важен быстрый старт, а не тонкая кастомизация процесса выдачи.

Примеры builtin‑интеграций

Особенности зависят от конкретного ПО, но общие паттерны такие:

• Веб‑серверы и reverse‑proxy. Некоторые серверы умеют по конфигу автоматически ходить в ACME CA, запрашивать и продлять сертификаты, хранить их на диске и прозрачно применять при релоаде.
• Панели управления. Hosting‑панели часто предоставляют кнопку «Получить бесплатный Let’s Encrypt сертификат» для каждого домена, плюс автоматическое продление.
• Kubernetes‑экосистема. Контроллеры типа cert‑manager управляют сертификатами как Kubernetes‑ресурсами, используя разные реализации ACME‑клиентов под капотом.

Плюсы builtin‑подхода

• Минимум ручной конфигурации. Не нужно думать про cron, таймеры, хуки рестарта.
• Хорошая интеграция с конкретным стеком. Если всё крутится в одной панели/оркестраторе, встроенный клиент часто лучший выбор.
• Меньше движущихся частей. Нет отдельного пакета certbot, нет скриптов вокруг.

Минусы builtin‑решений

• Зависимость от выбранной платформы. Переезд на другую панель или сервер может означать полную перестройку стратегии SSL.
• Ограниченная гибкость. Если нужны сложные сценарии (несколько CA, особые профили, нестандартные доменные схемы), встроенные клиенты могут не дать нужного уровня контроля.
• Иногда узкое место для отладки. Трассировка ACME‑ошибок через много абстракций (панель → API → ACME‑клиент → CA) может быть сложной.

Сравнение Certbot, lego, acme.sh и builtin по ключевым критериям

1. Поддержка http-01 / dns-01 / tls-alpn-01

• Certbot: отличный http-01, dns-01 через плагины, tls-alpn-01 есть, но реже используется и хуже задокументирован.
• lego: поддерживает все основные типы, часто является базой для других ACME‑клиентов.
• acme.sh: делает ставку на http-01 и dns-01, с большим количеством DNS‑плагинов.
• Builtin: зависит от конкретной реализации; для большинства типичный набор — http-01 и dns-01 (через DNS‑плагины/интеграции панели).

2. DNS‑провайдеры и wildcard‑домены

Wildcard‑сертификаты требуют DNS‑челленджа, поэтому главное — наличие плагина под ваш DNS:

• Если DNS у популярного облака — подойдут все три (Certbot с плагином, lego, acme.sh).
• Если DNS у редкого провайдера — шансы выше у acme.sh и lego. Certbot придётся колхозить через generic‑скрипты.
• Builtin‑решения в панелях обычно привязаны к ограниченному числу DNS‑интеграций; если вы используете их DNS, всё просто, иначе придётся городить внешние клиенты.

3. Удобство в CI/CD и контейнерах

• Certbot: тяжеловат для минималистичных образов, но знакомый; удобно использовать в отдельном «TLS‑контейнере», который кладёт сертификаты в общий volume.
• lego: статический бинарь, идеально подходит для Alpine/BusyBox‑образов и как часть сборочного пайплайна.
• acme.sh: чуть сложнее в контейнерах (cron внутри контейнера — отдельная тема), но отлично ложится в GitOps‑подход, когда вы запускаете его по расписанию из CI.
• Builtin: если ваш ingress/панель уже решает ACME‑задачу, то в CI вам остаётся только прописать нужные аннотации/параметры, сертификаты появятся сами.

4. Управление ключами и безопасностью

В продакшене важно, где физически хранятся приватные ключи и кто к ним имеет доступ.

• Certbot по умолчанию кладёт их в /etc/letsencrypt. Нужно следить за правами доступа и бэкапами (или, наоборот, исключать из бэкапов).
• lego по умолчанию хранит аккаунт и ключи в директории .lego. Легко перенастроить путь и права, интегрировать с Secret‑хранилищами.
• acme.sh хранит всё в ~/.acme.sh, причём может быть несколько аккаунтов и CA. Важно аккуратно настроить права на каталог и учётные записи, от имени которых он работает.
• Builtin: ключи часто хранятся в приватном хранилище самого сервера/панели/оркестратора. Здесь вопрос: доверяете ли вы этой системе и как организованы бэкапы/экспорт ключей.

Практические сценарии выбора ACME‑клиента

1. Один VPS, один сайт на Nginx/Apache

Задача: включить HTTPS без лишней боли.

Подход:

• Чаще всего достаточно Certbot с плагином для Nginx/Apache и http-01.
• Если пакет certbot в дистрибутиве сильно устарел или хочется минималистичный стек — можно рассмотреть acme.sh с --issue -w и ручной интеграцией в конфиг Nginx.

2. Несколько доменов и wildcard, DNS у внешнего провайдера

Задача: один сервер обслуживает десятки субдоменов и пару wildcard‑зон, DNS хостится у стороннего провайдера.

Подход:

• acme.sh — часто лучший выбор за счёт огромного количества DNS‑плагинов и удобных хуков.
• lego хорош, если вы хотите двигаться в сторону контейнеризации или уже пользуетесь инструментами, основанными на lego.

3. Микросервисы и reverse‑proxy‑слой

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

Подход:

• Если reverse‑proxy умеет ACME builtin — часто проще доверить управление сертификатами ему.
• Альтернатива — отдельный «TLS‑сервер» на базе lego или acme.sh, который хранит сертификаты и отдаёт их фронтенду через volume или API.

4. Kubernetes и динамические окружения

Задача: кластер, в котором поды и ingress‑ресурсы появляются и исчезают, сертификаты должны подхватываться автоматически.

Подход:

• Использовать Kubernetes‑оператор для сертификатов (например, cert‑manager и аналоги), который под капотом может использовать lego или другие клиенты.
• Отдельные Certbot/acme.sh‑контейнеры уместны, если у вас нестандартные требования по CA или логике выдачи, но в большинстве случаев достаточно штатного инструмента кластера.

Типичные проблемы и как их диагностировать

Ошибки в http-01

Самые частые симптомы:

• CA не может достучаться до /.well-known/acme-challenge/... на домене.
• Вместо токена отдаётся 404, редирект на HTTPS/другой домен или страница приложения.

Что проверить:

• Маршрут /.well-known/acme-challenge/ должен отдаваться без редиректов и через тот же сервер, который создаёт токены.
• Отсутствие WAF/фильтров, которые подрезают нестандартные URL.
• Правильность DNS‑записей A/AAAA на время выдачи сертификата.

Заодно не забывайте про базовую гигиену HTTPS‑конфига: шифры, HSTS и прочие заголовки. Детальнее про это говорили в статье о настройке HTTP‑заголовков безопасности для Nginx и Apache.

Ошибки в dns-01

Частые источники проблем:

• Плагин создал TXT‑запись в «не той» зоне (нестандартная делегация, подпорки субдоменов).
• Разное состояние зон у провайдера и у того, что реально видит CA (кэширование, репликация).
• TTL слишком большой, а вы слишком быстро запускаете проверку.

Полезная техника диагностики — проверять TXT‑запись через независимые резолверы (например, с разных машин и сетей) до запуска ACME‑проверки.

Проблемы с продлением и автоматизацией

ACME‑клиент сам по себе — только половина истории. Вторая половина — как вы подключаете его в регулярную автоматизацию.

Основные моменты:

• Убедитесь, что cron/systemd‑таймер реально запускается и что логирование даёт вам сигналы об ошибках.
• Проверьте, что хуки с релоадом/рестартом веб‑сервера корректно отрабатывают: иногда сертификат уже обновлён, но сервер всё ещё держит старый в памяти.
• В микросервисной архитектуре продумайте, кто и как обновляет TLS‑секреты и отзывает старые.

Рекомендации по выбору стратегии

Если обобщить всё сказанное, можно вывести несколько практических правил.

1. Для одиночных VDS или виртуального хостинга с Apache/Nginx и простым доменным сценарием — начинайте с Certbot. Он даёт максимально быстрый путь к работающему HTTPS.
2. Если у вас много доменов, нужен wildcard и DNS‑челлендж с редким провайдером — присмотритесь к acme.sh и его DNS‑плагинам; внимательно настройте хуки.
3. Если архитектура вращается вокруг контейнеров, вы строите собственные утилиты и хотите статические бинарники — lego даёт хороший баланс между гибкостью и простотой деплоя.
4. Если используете современный reverse‑proxy, панель или оркестратор, в котором уже есть ACME‑поддержка, — логично сперва исчерпать возможности builtin‑клиента, и только если их не хватает, переходить к внешним решениям.

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

При грамотной настройке любой из рассмотренных инструментов — Certbot, lego, acme.sh или builtin‑интеграция — способен обеспечить надёжную, предсказуемую и полностью автоматизированную работу HTTPS‑сертификатов в вашем продакшене. А если вы только планируете инфраструктуру под новые проекты, имеет смысл сразу закладывать в архитектуру автоматическое получение и продление SSL-сертификаты, чтобы вопрос безопасности и доверия браузеров был закрыт из коробки.