SSL-сертификаты: CN, SAN и wildcard на практике

Если вы давно выдаёте себе «быстрый ответ» про TLS-сертификаты в духе: «ну там есть обычный, wildcard и ещё какой‑то multi-domain», а затем в конфиге Nginx судорожно выбираете, какой из трёх файлов crt подходит под новый поддомен — эта статья для вас.

Разберёмся, что сейчас реально значат поля CN и SAN, чем wildcard отличается от multi-domain (SAN) сертификатов, и как не пострелять себе в ногу на живом проекте.

Базовые термины: CN, SAN, wildcard, multi-domain

Начнём с терминологии, иначе дальше всё будет смешиваться.

CN (Common Name)

Common Name — исторически главное поле X.509-сертификата, в которое раньше записывали доменное имя: например, www.example.com. Браузеры сверяли имя хоста в URL именно с CN.

Сейчас для публичных SSL/TLS-сертификатов правило изменилось:

• браузеры и клиенты ориентируются на расширение Subject Alternative Name (SAN);
• CN может быть заполнен, но его значение не считается источником истины;
• публичные CA обязаны перечислять все домены именно в SAN.

На практике: если в сертификате нужного домена нет в SAN, его не примут, даже если он указан в CN.

SAN (Subject Alternative Name)

Subject Alternative Name — расширение сертификата, в котором перечисляются все дополнительные имена, на которые он действителен. Типичный вид:

DNS:example.com
DNS:www.example.com
DNS:api.example.com

Именно наличие домена (или подстановочного домена) в SAN определяет, будет ли шифрованное соединение по TLS считаться валидным.

Ключевые моменты для SAN:

• в сертификате может быть один или много записей DNS: — отсюда «multi-domain»;
• допускаются wildcard-записи вида *.example.com;
• некоторые клиенты смотрят только в SAN и вообще игнорируют CN.

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

Wildcard-сертификат — это сертификат с подстановочным именем, например *.example.com. Он покрывает все поддомены одного уровня:

• www.example.com — да;
• api.example.com — да;
• dev.api.example.com — нет (это уже второй уровень поддоменов);
• example.com (голый домен) — нет, нужен отдельный SAN.

Wildcard обычно записывают именно в поле SAN как DNS:*.example.com. Наличие такой записи не делает сертификат «магическим», это просто шаблон, который клиент корректно обрабатывает при валидации имени.

Multi-domain / SAN-сертификаты

Multi-domain (или SAN-сертификат) — это сертификат, в котором в SAN перечислено несколько конкретных доменов и/или поддоменов, каждый отдельной записью DNS:. Например:

DNS:example.com
DNS:www.example.com
DNS:shop.example.net
DNS:cdn.images.example.org

Важно понимать: wildcard и multi-domain — это не взаимоисключающие вещи. Wildcard тоже живёт в SAN. Часто один и тот же сертификат:

• формально является SAN-сертификатом (в нём несколько записей в SAN);
• и содержит 1–2 wildcard-записи;
• и для простоты его всё равно называют «wildcard».

Что сейчас реально важно: роль CN и SAN в TLS

В документации и старых статьях часто встречается фраза «домен должен быть в CN или SAN». Для современной практики публичных сайтов это устарело по двум причинам:

• современные браузеры обязаны сверять домен только с SAN;
• правила отрасли требуют от публичных CA всегда указывать домены в SAN.

Для публичных сайтов смотрите только на SAN. Поле CN можно игнорировать как с точки зрения валидации доменов, так и при выборе типа сертификата.

Реальные последствия для админа:

• если вы видите в CRT-файле нужный домен только в CN, а SAN пустой или там другие имена — такой сертификат для публичного сайта использовать нельзя;
• для внутренних сервисов и self-signed CA поведение зависит от клиента: часть утилит и библиотек до сих пор могут смотреть на CN, но лучше придерживаться той же практики — всё важное должно быть в SAN.

Типы сертификатов с точки зрения доменной структуры

Не будем уходить в валидацию (DV/OV/EV), сконцентрируемся на том, какие домены может покрыть сертификат.

Одиночный домен (single-domain)

Классический вариант: сертификат выписан на один домен, например www.example.com. В SAN при этом тоже один домен.

Плюсы:

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

Минусы:

• при росте числа поддоменов/сервисов быстро становится неудобно управлять множеством отдельных сертификатов;
• каждый новый домен — отдельный процесс выпуска/продления.

Wildcard: когда уместен, а когда нет

Wildcard-сертификат (условный *.example.com) решает проблему с большим числом однотипных поддоменов первого уровня:

• app1.example.com, app2.example.com, app3.example.com;
• арендованные поддомены в мультиарендной SaaS-платформе;
• стендовая инфраструктура: dev.example.com, stage.example.com, test.example.com.

При этом стоит помнить ограничения:

• голый домен example.com придётся добавлять отдельным SAN;
• второй уровень поддоменов (например, app1.dev.example.com) wildcard на *.example.com не покрывает;
• wildcard нельзя использовать для e-mail-серверов (MX) как подстановочный «везде сам за себя» — там другие правила валидации клиентов.

С точки зрения безопасности wildcard-сертификат — более чувствительная штука: компрометация ключа *.example.com компрометирует все поддомены первого уровня. Это главный аргумент против массового раздаивания приватного ключа wildcard-сертификата во все подряд системы и подрядчикам.

SAN / multi-domain: конкретный список имён

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

• example.com;
• www.example.com;
• static.example.com;
• shop.example.net;
• cdn.example.org.

Плюсы multi-domain:

• упрощённое управление: один сертификат для нужного набора доменов;
• удобно для компаний с несколькими брендами/доменами;
• можно комбинировать wildcard и конкретные имена в одном сертификате (например, example.com + *.example.com).

Минусы:

• часто есть верхний предел числа SAN-записей (в зависимости от CA и типа сертификата);
• при добавлении нового домена нужно перевыпускать сертификат, что затрагивает все сервисы, его использующие;
• компрометация такого сертификата затрагивает сразу все перечисленные домены.

Если вы только строите инфраструктуру, имеет смысл сразу продумать схему доменов и поддоменов, чтобы не пришлось через год болезненно переезжать с россыпи single-domain на wildcard или SAN, ломая конфиги и автоматизацию. При этом не забывайте, что хорошие SSL-практики идут рука об руку с правильным выбором площадки: где‑то достаточно классического виртуального хостинга, а где‑то лучше сразу закладываться на отдельный VDS под фронтовые балансировщики.

Практические сценарии и подводные камни

Рассмотрим типичные реалистичные кейсы, с которыми сталкивается админ или девопс.

Кейс 1. Один проект — много поддоменов

Есть основной сайт example.com и куча сервисов:

• www.example.com;
• api.example.com;
• cdn.example.com;
• admin.example.com;
• files.example.com.

Варианты:

• single-domain на каждый поддомен — много сертификатов, много автоматизации;
• wildcard для *.example.com + отдельный SAN или отдельный сертификат для example.com;
• multi-domain SAN-сертификат без wildcard: все конкретные имена перечислены в SAN.

Что обычно выбирают:

• wildcard, если поддомены будут расти и меняться;
• multi-domain, если набор имён стабилен и их немного, а требования безопасности не позволяют использовать один ключ для любого поддомена.

Кейс 2. Несколько брендов и доменов

Компания владеет доменами example.com, example.net, example.org и хочет минимизировать количество сертификатов.

Логичный выбор — multi-domain SAN-сертификат, где перечислены:

• example.com, www.example.com;
• example.net, www.example.net;
• example.org, www.example.org.

Если нужно, можно добавить wildcard-поддомены (например, *.example.com), но тогда сильно вырастает зона поражения при утечке ключа; стоит разделять сертификаты по зонам ответственности.

Кейс 3. Микросервисы, Kubernetes, ingress

Во многих кластерах ingress-контроллер (Nginx, Traefik, Envoy, Caddy и др.) терминирует TLS, а дальше трафик идёт в сервисы в виде plain HTTP или внутреннего TLS.

В таком сценарии подходы:

• один wildcard *.example.com на ingress, который закрывает api.example.com, auth.example.com, billing.example.com и т.д.;
• несколько single-domain сертификатов, если политики безопасности запрещают wildcard для прод-окружения;
• multi-domain, если ingress обслуживает несколько доменов или брендов.

Главный плюс wildcard здесь — упростить манифесты и не думать о выпуске нового сертификата при каждом новом хосте в ingress.

Кейс 4. Внутренние сервисы и self-signed CA

Во внутренних сетях часто поднимают собственный центр сертификации (CA) и выдачу сертификатов автоматизируют через ACME или иные механизмы.

Особенности:

• часть старых клиентов (SDK, агенты, IoT) может продолжать смотреть на CN, а не SAN;
• при этом лучше сразу настроить CA на корректное заполнение SAN (в том числе wildcard) по современным правилам;
• для внутренних микросервисов обычно используют single-domain либо небольшой wildcard на зону.

Совет: даже во внутренней PKI желательно соблюдать те же практики, что и в публичном интернете, чтобы при переносе сервисов наружу не было сюрпризов. Если у вас уже есть обширный зоопарк доменных имён, имеет смысл заранее подумать о защите бренда и доменной зоны в целом и выстроить стратегию, похожую на описанную в материале о защите доменного бренда и связанных имён.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Чем ещё отличаются сертификаты с точки зрения CN/SAN

Отдельные нюансы, которые всплывают в работе.

Ограничения по количеству SAN-записей

Большинство CA ограничивают число доменов в одном SAN-сертификате. В дешёвых коммерческих продуктах и части бесплатных решений лимиты могут быть довольно жёсткими.

Это важно учесть на стадии дизайн‑решения: если вы сейчас закладываетесь на единый multi-domain сертификат на 20 имён, а через год их станет 50, вы можете уткнуться в лимит и будете вынуждены пересобирать схему.

Расширения и специальные случаи

Иногда в SAN, кроме DNS:, встречаются:

• IP: — для сертификатов, выписанных на IP-адрес (актуально для некоторых API или внутренней инфраструктуры);
• URI: и другие типы — реже используются для веба, но важны в специфических протоколах.

При диагностике проблем TLS полезно смотреть на полный список SAN — некорректное или неожиданное имя может объяснить ошибки проверки имени хоста.

Срок действия и перевыпуск multi-domain / wildcard

При перевыпуске SAN-сертификата:

• любое добавление или удаление имени — это новый сертификат, который нужно распространить на все задействованные сервера;
• для wildcard- и multi-domain-сертификатов особенно важно иметь автоматический деплой и ротацию ключей;
• при ошибке (забыли имя, удалили лишнее) вы рискуете «уронить» HTTPS одновременно на нескольких критичных доменах.

Поэтому архитектурно безопаснее разбивать сертификаты по зонам ответственности и критичности: не держать условный *.corp.example.com и banking.example.com в одном SAN.

Рекомендации по выбору схемы для проекта

Подведём итог в виде практических рекомендаций.

Шпаргалка выбора по структуре доменов

• Один домен, максимум один поддомен — берите single-domain на каждый, меньше рисков.
• Много поддоменов первого уровня в одной зоне, структура меняется — wildcard *.example.com плюс отдельный сертификат для example.com.
• Несколько доменов или брендов, набор имён стабильный — multi-domain SAN-сертификат с перечислением всех FQDN.
• Высокие требования к сегментации и безопасности — больше мелких single-domain сертификатов, минимум wildcard, multi-domain только внутри одного контура.

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

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Политика обращения с ключами wildcard и SAN

Чтобы не превращать wildcard и большие SAN-сертификаты в точку тотального риска:

• минимизируйте число мест, где лежит приватный ключ;
• используйте централизованный TLS-терминатор (балансировщики, ingress) вместо распространения ключа по всем бэкендам;
• жёстко логируйте доступ к ключам и процедурам выпуска и ротации;
• разделяйте сертификаты по средам (prod/stage/dev) и по доменным зонам.

Автоматизация: залог того, что SAN не станет проблемой

Что бы вы ни выбрали — single-domain, wildcard или multi-domain — без автоматизации выпуск и продление сертификатов быстро превращаются в ручной ад.

Минимальный набор практик:

• «истинный список доменов» хранится в коде (инфраструктура как код), а не в голове администратора;
• процесс выпуска и перевыпуска сертификата воспроизводим и документирован;
• деплой новых сертификатов на фронтовые сервера выполняется автоматически и проверяется health‑чеками;
• есть мониторинг срока действия сертификатов и алерты с запасом времени.

Понимание роли CN и SAN, а также осознанный выбор между single-domain, wildcard и multi-domain-схемами экономит кучу времени в эксплуатации и снижает риски «внезапно» истекшего или неправильно выпущенного сертификата. Для современного HTTPS важно смотреть на SAN как на основной источник истины и проектировать доменную структуру и политику TLS-сертификатов заранее, а не постфактум, когда у вас уже десятки FQDN и разрозненных конфигов. А подобрать подходящие SSL-сертификаты под выбранную стратегию и разместить их на надёжной площадке вы всегда можете вместе с сервисами Fastfox.