Как перестать мучиться с SSL-сертификатами и полюбить Go

Automatic Certificates and HTTPS for everyone.

Помните времена, когда получение SSL-сертификата было целым квестом с генерацией CSR, перепиской с удостоверяющим центром и ручной вставкой ключей в конфиг Nginx? Let's Encrypt и протокол ACME превратили это в рутину, но стандартные инструменты вроде Certbot не всегда удобны. Особенно если вы пишете на Go и хотите встроить управление сертификатами прямо в свое приложение или автоматизировать процесс в специфическом окружении.

Репозиторий lego — это одновременно и консольная утилита, и библиотека для Go, которая берет на себя всю грязную работу по общению с ACME-серверами. Проект существует с 2015 года, набрал почти 10 тысяч звезд на GitHub и стал своего рода швейцарским ножом для тех, кому нужно «просто поднять HTTPS».

Почему именно lego

Я часто сталкиваюсь с тем, что разработчики используют Certbot просто по привычке. Это отличный инструмент, но у него есть зависимости (Python), и он довольно тяжеловесный. Lego написан на Go, компилируется в один бинарник и не требует ничего, кроме самого себя.

Интересно, что название проекта — это не только отсылка к конструктору. Это акроним от Let's Encrypt Go. Авторы изначально закладывали идею модульности: вы собираете процесс получения сертификата из нужных «деталей», будь то разные способы подтверждения владения доменом (challenges) или поддержка экзотических DNS-провайдеров.

Что умеет этот конструктор

Главная проблема автоматизации сертификатов — это прохождение проверок (Challenge). Если ваш сервер смотрит в интернет 80-м портом, проблем нет. Но что, если вы за NAT, в закрытом контуре или выпускаете Wildcard-сертификат?

Lego поддерживает три типа проверок:

1. HTTP (http-01): классика, когда ACME-сервер стучится к вам на порт 80.
2. TLS (tls-alpn-01): проверка через TLS, полезно, если 80 порт занят или закрыт.
3. DNS (dns-01): самый гибкий вариант. Вы создаете TXT-запись в своей DNS-зоне, и вуаля — сертификат ваш.

И вот тут кроется главная ценность проекта. Lego поддерживает около 180 DNS-провайдеров. В списке есть как мировые гиганты вроде Cloudflare или AWS Route53, так и локальные сервисы: Selectel, Reg.ru, Yandex Cloud, Timeweb и Beget. Если ваш домен живет у популярного регистратора, скорее всего, lego уже умеет с ним работать «из коробки».

Использование в коде

Для Go-разработчиков lego — это песня. Вам не нужно запускать внешние процессы или парсить логи. Библиотека предоставляет чистый API.

Вот пример того, как может выглядеть инициализация клиента:

// Создаем пользователя
myUser := MyUser{
    Email: "admin@example.com",
    key:   privateKey,
}

config := lego.NewConfig(&myUser)

// Настраиваем клиента (используем staging-сервер для тестов)
config.CADirURL = "https://acme-staging-v02.api.letsencrypt.org/directory"
client, _ := lego.NewClient(config)

// Выбираем способ проверки, например, через DNS провайдера Cloudflare
provider, _ := cloudflare.NewDNSProvider()
client.Challenge.SetDNS01Provider(provider)

// Запрашиваем сертификат
request := certificate.ObtainRequest{
    Domains: []string{"example.com", "*.example.com"},
    Bundle:  true,
}
certificates, _ := client.Certificate.Obtain(request)

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

Консольная утилита

Если вы не хотите писать код, lego отлично работает как CLI. Это особенно удобно в Docker-контейнерах или CI/CD пайплайнах. Установка сводится к скачиванию бинарника под вашу архитектуру.

Пример получения сертификата через DNS-проверку для домена на хостинге Beget:

BEGET_USER=myuser \
BEGET_API_KEY=mykey \
lego --email admin@example.com --dns beget --domains "example.com" run

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

Практические кейсы

Где это реально экономит время?

Во-первых, при создании внутренних инструментов управления инфраструктурой. Если вы пишете свою панель управления или оператор для Kubernetes, lego как библиотека станет идеальным компонентом.

Во-вторых, в микросервисах, которым нужен mTLS или просто честный HTTPS. Вместо того чтобы пробрасывать сертификаты томами в Docker, сервис может сам обновлять свои ключи при старте или по расписанию.

В-третьих, это спасение для Wildcard-сертификатов. Обновлять их вручную раз в три месяца — сомнительное удовольствие. С lego этот процесс полностью автоматизируется за пять минут.

Стоит ли пробовать

Если вам нужно просто «повесить SSL» на один сайт, Certbot или встроенные средства Nginx/Caddy справятся не хуже. Но если ваша задача — автоматизация в специфических условиях, работа с редкими DNS-провайдерами или встраивание ACME-клиента прямо в софт на Go, альтернатив lego практически нет.

Проект живой, активно поддерживает новые RFC (например, ARI для информации об обновлении) и быстро реагирует на изменения в API провайдеров. Единственный нюанс — документация иногда кажется лаконичной, но это с лихвой компенсируется понятным кодом и примерами в репозитории.

Подойдет ли это вам? Определенно да, если вы цените чистоту решений и отсутствие лишних зависимостей в системе.