Wildcard vs SAN-сертификат: когда какой выбрать в 2026

Wildcard vs SAN-сертификат: когда какой выбрать в 2026

Wildcard и SAN (Subject Alternative Name) — два способа покрыть несколько доменов одним проверку SSL. Выбор между ними влияет на стоимость, безопасность и простоту автоматизации. В этой статье разберём, чем они различаются, когда каждый из них уместен и почему для большинства современных проектов SAN-сертификат от Let's Encrypt выгоднее, чем платный wildcard.

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

Wildcard — это сертификат с маской *.example.com в поле Common Name или SAN. Он покрывает все поддомены первого уровня: www.example.com, api.example.com, mail.example.com и т.д. Но НЕ покрывает:

• Сам apex-домен example.com (нужен отдельный SAN).
• Поддомены второго уровня: a.b.example.com под *.example.com не попадает.
• Другие домены: example.org, example.net.

Правильная wildcard-конфигурация обычно содержит два имени: example.com + *.example.com. Проверить покрытие текущего сертификата можно через SSL Checker enterno.io — он покажет все SAN и CN.

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

SAN (Subject Alternative Name) — расширение X.509, позволяющее в одном сертификате перечислить много конкретных доменов. Пример:

Subject Alternative Name:
    DNS:example.com
    DNS:www.example.com
    DNS:api.example.com
    DNS:admin.example.com
    DNS:example.org
    DNS:example.net

По сути, все современные сертификаты — это SAN-сертификаты, потому что CN-only больше не поддерживается браузерами (с Chrome 58). Даже сертификат на один домен использует SAN-поле. Когда говорят «SAN-сертификат», обычно имеют в виду multi-domain с 2+ SAN.

Сравнение: ключевые отличия

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

• Много поддоменов, которые создаются/удаляются динамически (SaaS multi-tenant: acme.example.com, globex.example.com).
• У вас DNS-провайдер с API (Cloudflare, Route 53, DigitalOcean) — это нужно для автоматической DNS-валидации.
• Нужен один ключ на все сервисы одного домена — проще для CDN-интеграций.
• Вы не можете предсказать список поддоменов заранее.

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

• Фиксированный и небольшой список доменов (до 100 в одном сертификате).
• Нужно покрыть несколько разных TLD (example.com + example.ru).
• Безопасность: хотите минимизировать радиус поражения при компрометации ключа.
• Простая автоматизация: HTTP-01 не требует доступа к DNS.
• Let's Encrypt даёт бесплатно — экономия на платных wildcard-сертификатах.

Автоматизация: certbot + Let's Encrypt

SAN через HTTP-01 (простейший случай):

sudo certbot certonly --webroot -w /var/www/html \
    -d example.com -d www.example.com \
    -d api.example.com -d admin.example.com

Wildcard через DNS-01 (на Cloudflare):

# /etc/letsencrypt/cloudflare.ini
dns_cloudflare_api_token = YOUR_TOKEN

# Запуск
sudo certbot certonly \
    --dns-cloudflare \
    --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
    -d "*.example.com" -d example.com

Автообновление одинаково для обоих типов — certbot renew подставит сохранённые параметры. Подробнее — в статье «Let's Encrypt: установка certbot».

Безопасность: почему wildcard рискованнее

Главный риск wildcard — один приватный ключ защищает все поддомены. Если ключ утёк (бекдор на сервере, небезопасный CI/CD, разработчик скачал на домашний ноутбук) — атакующий может выдавать себя за любой поддомен вашей компании, включая bank.example.com и oauth.example.com. С SAN-сертификатом радиус поражения локализован конкретным списком.

Best practices для wildcard:

• Храните ключ в HSM или Secrets Manager, не на дисках веб-серверов.
• Используйте отдельные wildcard-сертификаты для prod/staging/dev.
• Ротируйте каждые 60–90 дней (Let's Encrypt естественно так и делает).
• Мониторьте новые поддомены и сертификаты через Certificate Transparency.

Комбинированный подход

Крупные проекты часто используют оба типа: wildcard на публичных поддоменах (*.example.com) + отдельные SAN-сертификаты для критичных сервисов (oauth, admin, payments). Это снижает риск: компрометация wildcard не затрагивает критичные пути, у которых свои, более строго защищённые ключи.

Часто задаваемые вопросы

Wildcard покрывает apex-домен?

Нет. *.example.com не покрывает сам example.com. Нужно в SAN явно добавить example.com.

Сколько SAN можно в одном сертификате?

Стандарт X.509 не лимитирует, но на практике CA ставят лимит 100–250. Let's Encrypt — 100 SAN. Если нужно больше — нужно несколько сертификатов или wildcard.

Wildcard работает с a.b.example.com?

Нет. *.example.com покрывает только один уровень. Для *.a.example.com нужен отдельный wildcard на этот уровень.

Что выбрать для микросервисов в k8s?

Обычно wildcard + cert-manager. Let's Encrypt DNS-01 с автоматизацией через cert-manager — де-факто стандарт. SAN подходит, если микросервисы стабильны и их мало.

Заключение

Для 90% проектов подойдёт SAN-сертификат от Let's Encrypt: бесплатно, безопаснее, автоматизируется через HTTP-01. Wildcard нужен только там, где поддомены создаются динамически и их количество заранее неизвестно. Проверьте свой текущий сертификат через SSL Checker enterno.io — убедитесь, что SAN покрывает все домены, и Monitors присмотрит за сроком действия всех вариантов.

X.509 SAN — RFC 5280, §4.2.1.6. Certificate Transparency — crt.sh. Let's Encrypt rate limits — letsencrypt.org/docs/rate-limits.