Wildcard TLS: настройка DNS-01 и GitOps

Настройка Wildcard TLS через DNS-01 и GitOps — автоматизация сертификатов для всех поддоменов. При появлении в домене более пяти поддоменов — стейджинг, API, админка, промо — выпуск отдельного сертификата для каждого превращается в рутину с риском пропустить продление. Wildcard TLS-сертификат *.company.com решает проблему одним cert, но требует правильного подхода: DNS-01 challenge, автоматическое обновление и безопасное хранение приватного ключа. Мы выполняем настройку «под ключ»: от выпуска до мониторинга. Проект занимает 2–4 дня, после чего он обновляется без участия человека. Всё построено на GitOps — инфраструктура как код, изменения через PR, интеграция с Helm и ArgoCD. Никаких ручных ssh-сессий на production. Экономия времени команды — до 70% за счёт автоматизации. Ошибки при обновлении отслеживаем в Slack. SAN для корневого домена добавляется при выпуске, чтобы company.com тоже был под защитой. Подключаемся к вашему DNS-провайдеру через API с ограниченными правами — создаём временную TXT-запись и удаляем её после выпуска.

Наша команда имеет 5+ лет практики в управлении TLS-инфраструктурой в production, выполнила более 50 проектов по настройке wildcard TLS. Снижаем затраты на управление TLS-автоматизацией на 60–70%. Закажите оценку вашего проекта.

Покрытие и ограничения wildcard

Wildcard *.company.com покрывает:

• api.company.com
• app.company.com
• любой другой поддомен первого уровня

Не покрывает:

• company.com (корневой домен — нужно явно добавлять как SAN)
• api.staging.company.com (второй уровень — нужен отдельный *.staging.company.com)

Для покрытия корневого домена выпускают комбинированный сертификат с SAN: *.company.com + company.com. Это стандарт, описанный в документации Let's Encrypt.

Почему DNS-01 challenge — единственный вариант для wildcard?

HTTP-01 challenge требует, чтобы каждый поддомен был доступен по HTTP. Для wildcard это невозможно — нельзя предугадать все поддомены заранее. DNS-01 challenge использует DNS-запись TXT для подтверждения владения доменом. Мы подключаемся к вашему DNS-провайдеру через API, создаём временную запись и автоматически её удаляем после выпуска. Это безопасно и не требует прав на редактирование всей зоны — достаточно API-токена с ограниченными правами. DNS-01 challenge — единственный способ получить wildcard-сертификат от Let's Encrypt.

Выпуск через certbot и Cloudflare

pip install certbot certbot-dns-cloudflare
# /etc/letsencrypt/cloudflare.ini (chmod 600)
# dns_cloudflare_api_token = ваш_api_токен
certbot certonly \
    --dns-cloudflare \
    --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
    --dns-cloudflare-propagation-seconds 60 \
    -d "*.company.com" \
    -d "company.com" \
    --email [email protected] \
    --agree-tos \
    --non-interactive

Cloudflare API token нужен с правами Zone:DNS:Edit только для нужной зоны — не весь аккаунт. Создавать через Cloudflare Dashboard → My Profile → API Tokens → Create Token → Edit zone DNS.

Wildcard в Kubernetes через cert-manager и Route53

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-company-com
  namespace: cert-manager
spec:
  secretName: wildcard-company-com-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - "*.company.com"
    - "company.com"
  duration: 2160h
  renewBefore: 720h

После выпуска Secret wildcard-company-com-tls нужно распространить по неймспейсам. cert-manager не умеет это из коробки — для этого используется reflector или kubernetes-replicator:

# Аннотация на Secret для reflector
annotations: reflector.v1.k8s.emberstack.com/reflection-allowed: "true"
  reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "production,staging"

Или через ClusterSecret (оператор kubernetes-replicator):

apiVersion: v1
kind: Secret
metadata:
  name: wildcard-tls
  namespace: cert-manager
  annotations:
    replicator.v1.mittwald.de/replicate-to: "production,staging,dev"

Сравнение подходов и провайдеров

Как настроить wildcard-сертификат через cert-manager?

Мы используем cert-manager как стандарт де-факто для Kubernetes. Процесс включает:

1. Установка cert-manager через Helm.
2. Создание ClusterIssuer с DNS-01 провайдером.
3. Создание Certificate ресурса с wildcard-именем.
4. Настройка автоматической репликации Secret.
5. Интеграция с Ingress-controller (nginx, traefik, AWS ALB).

Весь процесс автоматизирован в наших Ansible-ролях и Terraform-модулях. Среднее время — 2 часа. Например, у одного клиента было 15 поддоменов — после настройки время обслуживания сертификатов сократилось до нуля, а число инцидентов из-за просрочки упало с 3 в квартал до 0.

Ротация приватного ключа

Wildcard TLS покрывает много доменов — компрометация приватного ключа означает компрометацию всех поддоменов сразу. Хранить приватный ключ нужно аккуратно:

• Не коммитить в git
• Не хранить в чатах, тикетах
• Доступ к /etc/letsencrypt/live/ только для root
• В Kubernetes — Secret должен иметь RBAC с ограниченным доступом

cert-manager по умолчанию ротирует приватный ключ при каждом обновлении сертификата (privateKey.rotationPolicy: Always). Это хорошо с точки зрения безопасности, но может вызвать кратковременный downtime при обновлении — Ingress controller должен подхватить новый ключ.

Когда wildcard не подходит

Wildcard удобен, но не универсален. Если у поддоменов разные владельцы или команды, один скомпрометированный сервис под *.company.com может использовать TLS-ключ для перехвата трафика другого поддомена. Для сервисов с разными уровнями доверия лучше выпускать TLS отдельно. Также некоторые CI/CD и облачные сервисы не поддерживают wildcard в своих конфигах и ожидают явного указания домена.

Что входит в работу

• Выпуск wildcard TLS через DNS-01 (certbot или cert-manager)
• Настройка автоматического обновления (cron или cert-manager)
• Репликация Secret по неймспейсам (reflector / kubernetes-replicator)
• Мониторинг обновления (алерты на expiry за 30 дней)
• Документация и runbook для команды

Настройка wildcard TLS с DNS-01 и автообновлением — 2–4 дня. Стоимость: от $220–320 (certbot + Cloudflare) до $540–780 (cert-manager + мультипровайдер). Свяжитесь с нами для оценки вашего проекта. Получите консультацию инженера.