Wildcard и мультидоменный SSL: когда нужен каждый

Коротко

• Wildcard (*.example.com) — один сертификат на все поддомены одного уровня одного домена: shop.example.com, api.example.com, любые новые.
• Мультидоменный, или SAN-сертификат — явный список имён в поле Subject Alternative Name: example.com, www.example.com, example.uz, brand.org. Домены могут быть разными.
• Это не взаимоисключающие варианты: в один SAN-сертификат можно положить и обычные имена, и несколько wildcard.

Правила покрытия

• Звёздочка заменяет ровно одну метку и только самую левую. *.example.com подходит для a.example.com, но не для a.b.example.com.
• Wildcard не покрывает сам домен. Чтобы работали и example.com, и поддомены, в сертификат добавляют оба имени.
• Частичные шаблоны вроде api-*.example.com центры сертификации не выпускают.
• Для второго уровня нужен свой wildcard: *.eu.example.com.
• EV-сертификаты в варианте wildcard не выпускаются.
• Количество имён в SAN ограничено правилами конкретного центра сертификации. У Let's Encrypt — до 100 имён в одном сертификате.

DNS-проверка для wildcard

Let's Encrypt выдаёт wildcard только через проверку DNS-01: центр сертификации даёт токен, вы публикуете его в TXT-записи _acme-challenge.example.com, центр проверяет запись. Платные центры сертификации тоже обычно проверяют wildcard через DNS или по почте.

Вручную это делается командой с --manual, но такой сертификат не продлится сам. Правильно — плагин для API вашего DNS-провайдера, например для Cloudflare:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

# /root/.secrets/cloudflare.ini, права 600
dns_cloudflare_api_token = <токен с правом Zone:DNS:Edit только для этой зоны>

Что важно знать:

• Для example.com и *.example.com проверка идёт по одному имени _acme-challenge.example.com, поэтому там одновременно будут две TXT-записи. Это нормально.
• Ограничьте токен одной зоной и правом на DNS. Ключ с доступом ко всему аккаунту на веб-сервере — лишний риск.
• Делегирование через CNAME. Можно сделать _acme-challenge.example.com CNAME-записью на имя в отдельной служебной зоне, к которой есть доступ у автоматизации. Тогда сервер вообще не получает прав на основную зону.
• Проверка может упасть, если TXT ещё не появилась на всех авторитетных серверах. У плагинов есть параметр ожидания распространения.

Как спланировать сертификаты для многих поддоменов

Группируйте имена не по удобству, а по тому, где лежит ключ и кто за него отвечает.

Когда выбирать wildcard:

• поддомены создаются автоматически, например client1.app.example.com для каждого клиента;
• TLS завершается в одном месте — на балансировщике, ingress или reverse proxy;
• не хочется раскрывать имена поддоменов: SAN-имена попадают в публичные журналы Certificate Transparency, а wildcard показывает только шаблон.

Когда выбирать SAN или отдельные сертификаты:

• разные домены одного проекта — example.com, example.uz;
• сервисы на разных серверах или у разных подрядчиков;
• имён немного и они меняются редко.

Рабочая схема:

1. example.com + www.example.com — обычный сертификат с двумя именами.
2. *.app.example.com — wildcard на балансировщике для клиентских поддоменов.
3. *.staging.example.com — отдельный сертификат и ключ для тестовой среды, не общий с продакшеном.
4. Внутренние сервисы — свои сертификаты или внутренний центр сертификации.
5. Учёт всех сертификатов и внешний мониторинг сроков. В Kubernetes выпуск и продление удобно отдать cert-manager.

Частые ошибки

• Ожидать, что *.example.com покроет example.com или a.b.example.com.
• Копировать один wildcard-ключ на все серверы, включая подрядчиков: утечка в одном месте компрометирует все поддомены.
• Выпустить wildcard вручную и забыть, что он не продлевается сам.
• Собрать в один SAN-сертификат несвязанные проекты: если один домен уйдёт или перестанет проходить проверку, продление всего сертификата сломается.