SSL-сертификаты: почему ваш сайт может лечь в самый неподходящий момент

Когда у тебя пара доменов — всё прекрасно. Настроил сертификат, забыл на три месяца, обновил, снова забыл. Рутина, но не проблема. Другое дело, когда проектов становится больше: основной сайт, блог, API, мобильное приложение бэкенд, тестовые площадки для клиентов... И вот ты уже пытаешься вспомнить, какой из двадцати сертификатов истекает на следующей неделе.

Знакомо? Мне тоже.

Что такое wildcard SSL и почему он экономит нервы

Wildcard-сертификат — это один документ на все поддомены. Вместо того чтобы получать отдельные файлы для api.example.com, staging.example.com и market.example.com, ты получаешь один, который покрывает всю ветку *.example.com.

Звучит просто. И это действительно просто — пока не доходит до установки.

HTTP-проверка: работает везде, кроме самых важных случаев

Let's Encrypt использует два основных способа подтвердить, что домен принадлежит именно тебе: HTTP и DNS.

HTTP-валидация — это классика. Сервер авторизации стучится на твой сайт, ты отдаёшь ему специальный файлик, он видит, что всё в порядке, выдаёт сертификат. Работает идеально... пока работает.

Проблемы начинаются, когда у тебя сервер за NAT. Или файрвол с жёсткими правилами. Или двадцать микросервисов в Kubernetes, где вообще непонятно, кто должен отвечать на запросы. В таких случаях HTTP-проверка просто не может дотянуться до твоего сервера — и всё, приехали.

DNS-валидация: работает из любой точки мира

Здесь логика другая. Вместо того чтобы доказывать владение доменом через файлы на сервере, ты добавляешь TXT-запись в DNS. Сервис проверки смотрит эту запись, видит, что ты действительно можешь ей управлять — и выдаёт сертификат.

Главное преимущество: проверка вообще не касается твоего сервера. Ей не нужны открытые порты, ей не нужен доступ извне. Единственное требование — возможность менять DNS через API.

Для серверов в закрытых сетях, для staging-окружений, для всего того, что спрятано за сложной инфраструктурой — это единственный работающий вариант.

Что даёт связка wildcard + DNS

Забываешь про таблицу с дедлайнами. Один сертификат — и никакой головной боли с отслеживанием. Обновил один раз, работает на всех поддоменах.

Автоматизация становится тривиальной. Написал скрипт, который обновляет DNS-запись — и всё. Сертификаты продлеваются сами, без твоего участия.

Новые поддомены появляются мгновенно. Захотел добавить newproject.example.com — добавил DNS-запись, поднял сервис, SSL уже есть. Никаких дополнительных телодвижений.

Работает там, где другие методы падают. Сервер в дата-центре с блокирующим файрволом? Локальная машина разработчика? Kubernetes-кластер с изолированными подами? DNS-проверка плевать хотела на все эти ограничения.

Как это настраивается на практике

Если твой хостинг-провайдер даёт доступ к DNS через API (а современные платформы, типа того же хостинга, где я держу свои проекты, это умеют), процесс выглядит так:

1. Привязываешь DNS-провайдера к своей утилите для сертификатов. Certbot, dehydrated, acme.sh — выбирай любой.
2. Указываешь, куда складывать полученные сертификаты.
3. Настраиваешь перезагрузку веб-сервера после обновления.

И вот здесь многие спотыкаются. Сертификат обновился, всё хорошо, но Nginx продолжает отдавать старый. Почему? Потому что кто-то забыл его перезапустить. Или пути в конфигурации не совпадают с реальным расположением файлов. Или панель управления хостинга перезаписывает конфиги при каждом обновлении.

Мелочи, но именно из таких мелочей складывается дежурный вызов в три часа ночи.

Зачем вообще заморачиваться

Автоматизация SSL — это не про модные технологии. Это про то, чтобы пятничным вечером заниматься своими делами, а не судорожно обновлять сертификат, потому что завтра важная презентация для клиента.

Один истёкший сертификат — это не просто ошибка в браузере. Это потерянные посетители, испорченное впечатление, сообщения от клиентов с вопросами «что случилось с сайтом?». И времени на возню с этим уходит гораздо больше, чем кажется.

С чего начать

Первое — проверь, поддерживает ли твой DNS-провайдер API. Если нет — возможно, стоит сменить. Управление DNS вручную через веб-интерфейс — это прошлый век, особенно когда речь заходит об автоматизации.

Второе — выбери клиент для получения сертификатов. Убедись, что он поддерживает твоего DNS-провайдера из коробки. Если нет — посмотри, есть ли плагины. acme.sh, например, поддерживает огромное количество провайдеров.

Третье — напиши деплой-скрипт. Не забудь про рестарт веб-сервера. Протестируй на стенде.

Четвёртое — мониторинг. Даже с автоматизацией раз в месяц заглядывай в даты истечения. Автоматика ломается редко, но случается.

Wildcard через DNS — это не хак и не костыль. Это правильный подход к инфраструктуре, который освобождает время для действительно важных задач. И когда в следующий раз тебе нужно будет срочно развернуть тестовое окружение для клиента, ты оценишь это по достоинству.