Wildcard-сертификат SSL: когда нужен и как получить

Что такое wildcard-сертификат

Обычный SSL-сертификат выпускается на конкретное доменное имя или явно перечисленный список имён (например, example.ru и www.example.ru). Wildcard-сертификат вместо этого покрывает шаблон вида *.example.ru — звёздочка означает «любое имя на этом уровне», что позволяет одному сертификату защищать неограниченное количество поддоменов без необходимости перевыпускать его при добавлении нового.

Практический пример: для проекта с поддоменами shop.example.ru, blog.example.ru, admin.example.ru и api.example.ru обычный подход потребовал бы либо четырёх отдельных сертификатов, либо одного сертификата с явным перечислением всех четырёх имён (SAN-сертификат) — и в любом случае добавление пятого поддомена потребовало бы перевыпуска. Wildcard-сертификат *.example.ru покрывает все текущие и будущие поддомены первого уровня одним махом.

Wildcard-сертификаты решают проблему масштаба, а не проблему безопасности — они не более и не менее безопасны технически, чем обычные сертификаты, но концентрируют больше ответственности в одном приватном ключе.

Общая рекомендация в руководствах по управлению SSL-сертификатами

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

Когда wildcard действительно нужен

Главный практический сценарий — проекты, которые создают новые поддомены динамически или часто: SaaS-платформы с персональным поддоменом для каждого клиента (client1.example.ru, client2.example.ru), витрины с множеством отдельных магазинов на поддоменах, среды разработки с поддоменами для каждой feature-ветки (feature-123.dev.example.ru).

Для таких сценариев без wildcard-сертификата пришлось бы либо выпускать новый сертификат для каждого нового клиента или ветки вручную (что не масштабируется), либо интегрировать автоматический выпуск отдельных сертификатов через HTTP-01 при создании каждого поддомена — рабочий, но более сложный в реализации подход.

Для типичного сайта с фиксированным небольшим набором поддоменов (например, только www и mail) wildcard избыточен — обычный сертификат с явным перечислением нужных имён через SAN (Subject Alternative Names) решает задачу проще, без необходимости в DNS-подтверждении и более широкой зоны риска компрометации ключа.

Wildcard vs SAN-сертификат: в чём разница

SAN-сертификат (иногда называемый multi-domain) явно перечисляет конкретный список доменных имён, которые он покрывает — например, example.ru, www.example.ru и shop.example.ru в одном сертификате. Список фиксирован на момент выпуска, и добавление нового имени требует перевыпуска сертификата с обновлённым списком.

Wildcard-сертификат покрывает шаблон, а не список — *.example.ru автоматически становится действителен для любого нового поддомена первого уровня без перевыпуска. Технически ничто не мешает объединить оба подхода в одном сертификате: например, запросить сертификат сразу для example.ru и *.example.ru, что покрывает и голый домен, и все его поддомены первого уровня одновременно.

certbot certonly --manual --preferred-challenges dns \
  -d example.ru -d "*.example.ru"

Ограничение: только один уровень вложенности

Важное ограничение, которое иногда упускают из виду: wildcard-сертификат *.example.ru покрывает только один уровень поддоменов — shop.example.ru покрывается, а api.shop.example.ru (поддомен поддомена) уже не покрывается тем же сертификатом.

Для покрытия второго уровня вложенности потребовался бы отдельный wildcard-сертификат именно для *.shop.example.ru — с точки зрения стандарта X.509, на котором строятся SSL-сертификаты, звёздочка в имени соответствует ровно одному сегменту доменного имени между точками, а не произвольному числу сегментов.

Это ограничение стоит учитывать на этапе проектирования схемы поддоменов проекта — если планируется многоуровневая структура (например, отдельные поддомены для каждого клиента, а внутри них ещё и технические поддомены вроде api.client1.example.ru), потребуется либо явно предусмотреть выпуск сертификатов на каждый нужный уровень вложенности отдельно, либо изначально спроектировать более плоскую схему адресации без глубокой вложенности.

Почему wildcard требует именно DNS-01, а не HTTP-01

Обычный сертификат Let's Encrypt чаще всего подтверждается через HTTP-01 challenge: certbot размещает специальный файл в директории сайта, и сервер Let's Encrypt проверяет его доступность по конкретному доменному имени через обычный HTTP-запрос — это подтверждает, что запрашивающий сертификат контролирует именно этот конкретный домен.

Для wildcard-сертификата такой подход не работает в принципе — Let's Encrypt не может обратиться по HTTP к «любому поддомену», поскольку это не конкретный адрес. Вместо этого используется DNS-01 challenge: certbot должен создать специальную TXT-запись с конкретным значением в DNS-зоне домена (_acme-challenge.example.ru), и Let's Encrypt проверяет её наличие через DNS-запрос, что доказывает контроль над всей DNS-зоной домена, а не отдельным HTTP-сервером.

_acme-challenge.example.ru.  TXT  "значение-подтверждения-от-certbot"

Именно эта особенность делает автоматизацию wildcard-сертификатов сложнее обычных — нужен либо ручной доступ к панели управления DNS при каждом продлении (неприемлемо для production без участия человека), либо плагин certbot, умеющий создавать и удалять такие записи автоматически через API конкретного DNS-провайдера.

Автоматизация через DNS-плагин certbot

Certbot поддерживает плагины для автоматизации DNS-01 challenge у множества популярных DNS-провайдеров — Cloudflare, AWS Route53, DigitalOcean и других. Если ваш домен обслуживается одним из поддерживаемых провайдеров, автоматизация сводится к установке плагина и указанию API-токена.

apt install python3-certbot-dns-cloudflare -y

dns_cloudflare_api_token = ваш_api_токен_cloudflare

certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d example.ru -d "*.example.ru"

При таком подходе certbot самостоятельно создаёт нужную TXT-запись через API, дожидается её распространения, проходит проверку Let's Encrypt, а затем удаляет запись — весь процесс, включая последующие автоматические продления каждые 90 дней, происходит без участия человека, как и с обычными сертификатами через HTTP-01.

Если DNS-провайдер не поддерживается плагином

Если используемый DNS-провайдер не имеет готового плагина certbot, остаётся несколько путей: написать собственный hook-скрипт, который вызывает API конкретного провайдера через универсальный механизм --manual-auth-hook и --manual-cleanup-hook, перенести DNS-зону к провайдеру с готовой поддержкой (например, на Cloudflare, который часто используется именно ради такой автоматизации), или отказаться от wildcard в пользу отдельных сертификатов через HTTP-01.

certbot certonly --manual \
  --preferred-challenges dns \
  --manual-auth-hook /usr/local/bin/dns-add-record.sh \
  --manual-cleanup-hook /usr/local/bin/dns-remove-record.sh \
  -d "*.example.ru"

Написание собственного hook-скрипта требует программного доступа к API конкретного DNS-провайдера (не все провайдеры вообще предоставляют такой API) и определённой аккуратности — скрипт должен не просто создать запись, но и дождаться её реального распространения по DNS прежде, чем вернуть управление certbot, иначе проверка Let's Encrypt может завершиться раньше, чем запись станет видна из интернета.

Практический способ дождаться распространения записи — периодически опрашивать публичные DNS-серверы (например, 8.8.8.8) командой dig на предмет появления ожидаемого значения TXT-записи, вместо фиксированной паузы произвольной длины, которая может оказаться как излишне долгой, так и недостаточной в зависимости от конкретного провайдера и текущей скорости распространения изменений по глобальной системе DNS.

until dig +short TXT _acme-challenge.example.ru @8.8.8.8 | grep -q "ожидаемое-значение"; do
  sleep 5
done

Настройка Nginx с wildcard-сертификатом

После получения wildcard-сертификата настройка Nginx для конкретных поддоменов не отличается от обычной — единственная особенность в том, что один и тот же файл сертификата используется в нескольких server-блоках для разных поддоменов, вместо отдельного сертификата на каждый.

server {
    listen 443 ssl;
    server_name shop.example.ru;
    ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;
    root /var/www/shop;
}

server {
    listen 443 ssl;
    server_name blog.example.ru;
    ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;
    root /var/www/blog;
}

Такая схема упрощает добавление нового поддомена — не нужно заново запрашивать и продлевать отдельный сертификат для каждого нового server-блока, достаточно указать путь к уже существующему wildcard-сертификату в новой конфигурации.

Безопасность: концентрация риска в одном ключе

Ключевой компромисс wildcard-сертификата — концентрация риска. Приватный ключ обычного сертификата при компрометации даёт злоумышленнику возможность выдавать себя только за тот конкретный домен, для которого он выпущен. Приватный ключ wildcard-сертификата при компрометации даёт возможность выдавать себя за любой текущий и будущий поддомен всего домена — потенциально значительно больший ущерб.

Чем шире область действия ключа, тем выше цена его компрометации — wildcard-сертификаты требуют пропорционально более строгого контроля доступа к приватному ключу, чем обычные сертификаты на одно имя.

Общий принцип управления рисками в криптографии

Практические меры: хранить приватный ключ только на серверах, где он действительно необходим, ограничивать права доступа к файлу ключа минимально необходимым пользователем (обычно root или пользователь веб-сервера), не копировать ключ на дополнительные серверы без явной необходимости, и рассматривать более короткий срок действия сертификата (у Let's Encrypt он и так составляет 90 дней) как дополнительный фактор снижения окна риска при возможной незамеченной компрометации.

Дополнительная мера предосторожности — мониторинг Certificate Transparency логов (публичных реестров всех выпущенных публично доверенных сертификатов) на предмет неожиданного выпуска сертификатов для поддоменов вашего домена, которые вы не запрашивали сами, — это может быть ранним признаком компрометации либо самого приватного ключа wildcard-сертификата, либо учётной записи в панели управления DNS, дающей возможность пройти DNS-01 challenge от вашего имени без вашего ведома.

Проверка полученного wildcard-сертификата

После получения сертификата стоит убедиться, что он действительно покрывает нужные поддомены и корректно принимается браузерами — команда openssl позволяет посмотреть содержимое сертификата, включая список имён, для которых он выпущен, не открывая браузер.

openssl x509 -in /etc/letsencrypt/live/example.ru/fullchain.pem -noout -text | grep -A2 "Subject Alternative Name"

Для проверки того, как сертификат выглядит с точки зрения реального посетителя сайта, удобны онлайн-инструменты вроде SSL Labs — они показывают не только сам список покрываемых имён, но и корректность цепочки доверия, поддерживаемые версии TLS и известные уязвимости конфигурации, если таковые есть, оценивая итоговую настройку общей буквенной оценкой от A до F.

echo | openssl s_client -servername shop.example.ru -connect shop.example.ru:443 2>/dev/null | openssl x509 -noout -dates

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

Wildcard-сертификаты и CDN

Если сайт использует CDN или сервис защиты от DDoS вроде Cloudflare в режиме проксирования, ситуация с сертификатами меняется — сам CDN обычно выпускает и обслуживает собственный сертификат (часто тоже wildcard) для соединения между браузером посетителя и своими серверами, а на участке между CDN и происхождением сайта (origin) может использоваться отдельный сертификат или упрощённая схема шифрования.

В такой конфигурации управление wildcard-сертификатом Let's Encrypt на собственном сервере может вообще не требоваться для внешних посетителей — CDN уже решает эту задачу на своей стороне. Originating-сертификат на сервере тогда нужен в первую очередь для шифрования трафика именно между CDN и сервером, где требования к публичному доверию браузеров не так важны, поскольку конечный пользователь напрямую с этим сертификатом не взаимодействует.

Стоит уточнить конкретную схему работы используемого CDN перед тем, как вкладывать усилия в настройку wildcard-сертификата и его автоматического продления на собственном сервере — возможно, эта задача уже полностью решена на уровне CDN, и повторные усилия с настройкой на своей стороне попросту не нужны.

Типичные ошибки при работе с wildcard-сертификатами

Ожидание, что *.example.ru покроет также голый домен example.ru — для этого нужно явно запросить сертификат сразу на оба имени в одном запросе, а не полагаться на то, что wildcard автоматически включает базовый домен.

Попытка использовать HTTP-01 challenge для wildcard-сертификата — Let's Encrypt отклонит такой запрос, поскольку для wildcard подтверждение возможно только через DNS-01, что стоит учитывать при выборе метода в конфигурации certbot заранее.

Отсутствие автоматизации продления через DNS-плагин при использовании wildcard в production — без него продление каждые 90 дней требует ручного вмешательства, и легко пропустить срок, особенно если ответственный администратор сменился или отвлёкся на другие задачи.

Хранение и копирование приватного ключа wildcard-сертификата шире необходимого — на серверы, где он реально не используется, в системы резервного копирования без должного шифрования, в общие репозитории кода по ошибке.

Проектирование многоуровневой структуры поддоменов (api.client1.example.ru) без понимания, что один wildcard-сертификат покрывает только один уровень вложенности — это выясняется уже на этапе настройки, когда сертификат неожиданно не подходит для части нужных адресов.

Чек-лист получения wildcard-сертификата

Шаг 1. Оцените, действительно ли нужен именно wildcard — для фиксированного небольшого набора поддоменов SAN-сертификат с явным перечислением имён может быть проще в сопровождении.

Шаг 2. Проверьте, поддерживает ли ваш DNS-провайдер готовый плагин certbot для автоматизации DNS-01 — от этого зависит, насколько просто будет настроить автоматическое продление.

Шаг 3. При необходимости перенесите DNS-зону к провайдеру с готовой поддержкой автоматизации, если текущий провайдер не имеет плагина и написание собственного hook-скрипта нежелательно.

Шаг 4. Запросите сертификат сразу на голый домен и wildcard (-d example.ru -d "*.example.ru"), если планируется использовать оба варианта.

Шаг 5. Настройте ограниченные права доступа к файлу приватного ключа и минимизируйте число серверов, где он хранится.

Шаг 6. Проверьте, что автоматическое продление реально работает — запустите certbot renew --dry-run и убедитесь в успешном прохождении DNS-01 без ручного вмешательства.

Итог: инструмент для конкретной задачи масштаба

Wildcard-сертификат решает конкретную практическую задачу — управление SSL для множества, особенно динамически создаваемых, поддоменов без необходимости выпускать и продлевать отдельный сертификат на каждый. Технология выпуска бесплатна через Let's Encrypt наравне с обычными сертификатами, но требует обязательного подтверждения через DNS и, для полноценной автоматизации, поддержки со стороны DNS-провайдера.

Для типичного сайта с фиксированным небольшим набором доменных имён wildcard скорее избыточен — обычный сертификат проще в получении и продлении. Если у вашего проекта уже есть или предвидится потребность во множестве поддоменов — оставьте заявку внизу страницы, поможем настроить wildcard-сертификат и автоматическое продление под конкретный DNS-провайдер.

Главный практический вывод: прежде чем настраивать wildcard, честно оцените, действительно ли текущая или обозримая будущая структура проекта нуждается в неограниченном числе поддоменов — если ответ да, вложенные усилия в автоматизацию DNS-01 окупятся уже на втором-третьем добавленном поддомене; если нет, простой сертификат с явным списком имён сэкономит время на настройке без потери в безопасности или удобстве.

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