SAN-сертификат: что это и когда он лучше wildcard

SAN — список конкретных имён в сертификате

SAN-сертификат содержит перечень доменных имён, для которых он действителен. Браузер смотрит не на красивое название сертификата, а на то, есть ли открываемое имя в Subject Alternative Name. Если пользователь открывает `panel.example.com`, это имя должно быть в SAN, иначе появится ошибка несоответствия. Common Name давно не является надёжной опорой для современной проверки.

SAN удобен, когда нужно закрыть несколько конкретных адресов: основной домен, `www`, личный кабинет, API, документацию, промо-домен. В отличие от wildcard, он явно показывает, какие имена включены. Это полезно для аудита, разделения ответственности и аккуратного продления. Но список нужно поддерживать: забытый поддомен не появится в сертификате сам.

Сравнение с wildcard подробно раскрыто в материале wildcard SSL или multi-domain SSL. Здесь фокус уже на решении: когда точный список имён лучше маски.

Когда SAN лучше wildcard

SAN лучше, если поддоменов немного и они важны по отдельности. Например, `example.com`, `www.example.com`, `app.example.com` и `api.example.com` можно держать в одном сертификате, если ими управляет одна команда и они обновляются вместе. Такой подход прозрачен: открываешь сертификат и видишь весь набор имён.

SAN также удобен, когда не хочется выпускать wildcard из-за риска широкого использования. Wildcard закрывает любой поддомен одного уровня, и это может быть чрезмерно для небольшого проекта. Если нужен только кабинет и API, точный список безопаснее организационно. Он не даёт случайному новому поддомену автоматически выглядеть «прикрытым» общей маской.

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

Когда wildcard проще

Wildcard удобен, если поддомены создаются часто и однотипно: клиентские кабинеты, временные окружения, dev/stage, региональные адреса. Он снижает количество перевыпусков, когда появляются новые имена. Но удобство не бесплатно: нужно строже контролировать приватный ключ, доступ к сертификату и сервера, где он установлен.

Wildcard не покрывает всё подряд. `*.example.com` не закрывает `example.com` и обычно не закрывает вложенные уровни вроде `x.y.example.com`. Поэтому даже с wildcard часто нужен отдельный SAN для корневого домена. Если это не учесть, владелец получает сертификат, который вроде «на всё», но главная страница продолжает требовать отдельного имени.

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

Проверка SAN перед установкой

Перед выпуском составьте список точных имён. Не из памяти, а из фактических URL: основной домен, `www`, кабинет, API, платежная страница, документация, служебные панели, если они публичны. Затем уберите лишнее. Сертификат не должен превращаться в склад устаревших имён. Каждое имя в SAN должно иметь владельца и назначение.

После выпуска проверьте сертификат в браузере и через команду с SNI. Важно увидеть, что нужное имя действительно находится в SAN и сервер отдаёт именно новый сертификат. Если один сертификат установлен на несколько серверов, проверяют каждый публичный адрес. Иначе можно получить ситуацию, где один edge уже обновлён, а второй отдаёт старую версию.

CAA-записи тоже влияют на выпуск. Если домен ограничивает центры сертификации, новый SAN-сертификат может не выпуститься автоматически. С этим слоем помогает материал CAA-записи и выпуск SSL-сертификатов.

Кейс: SAN оказался лучше общей маски

Проект хотел выпустить wildcard для всех поддоменов, потому что «так проще». После инвентаризации оказалось, что публичных имён всего четыре: сайт, `www`, кабинет и API. Остальные поддомены были внутренними, временными или не должны были светиться в общем сертификате. Команда выбрала SAN-сертификат с точным списком.

Для проектов с публичными сервисами важно отдельно учитывать пользовательские сценарии: сайт, кабинет, API, инструкции, поддержка и Telegram-каналы могут жить на разных адресах, но восприниматься как единая система. Если у сервиса есть отдельное направление, например VPN для Telegram, у страницы, бота, канала и кабинета должны быть понятные URL, корректные сертификаты и проверяемые официальные источники.

Через месяц добавился новый маркетинговый поддомен. Его не стали автоматически включать в общий сертификат: сначала проверили владельца, DNS, хостинг и необходимость HTTPS. Такой процесс занял больше времени, но сохранил порядок. Вывод: wildcard удобен при большом потоке однотипных имён, а SAN лучше там, где важна прозрачность и контроль списка.

Как SAN-сертификат меняет учёт имён

Покрытие не равно доступу

Сертификат для VPN может содержать несколько имён, но это не выдаёт доступ к каждому сервису. Поддомены VPN перечисляют отдельно. Домен для VPN сервера проверяют по профилю. Сайт VPN сервиса может иметь другой процесс и другой сертификат.

Приватный ключ

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

DNS и клиент

DNS для VPN направляет имя на нужный узел. Профиль VPN должен использовать имя из покрытия SAN. Ошибка сертификата VPN возникает и при правильном выпуске, если клиент запрашивает другое имя. Адрес VPN сервера сверяют с фактической конфигурацией.

Проверка

VPN соединение устанавливают заново после обновления. Проверить VPN соединение нужно на выбранных платформах. VPN для Android и VPN для Windows могут по-разному обрабатывать цепочку. Не отключайте TLS-проверку при несовпадении имени.

В этой схеме серверная часть — vpn сервер; рядом разобраны профиль vpn и клиентские шаги для vpn подписка и vpn для iphone.

FAQ по SAN-сертификатам

Что такое SAN в сертификате?

SAN — список имён, для которых сертификат считается действительным. Браузер проверяет именно этот список, а не только красивое имя в описании сертификата.

Когда SAN лучше wildcard?

Когда нужно закрыть точный набор доменов и не давать общую маску на все поддомены. SAN дисциплинирует список публичных имён.

Можно ли добавить имя в сертификат после выпуска?

Нет. Обычно выпускают новый сертификат с обновлённым SAN. Поэтому список имён нужно собрать до автоматизации и установки.

Почему SAN может раскрывать архитектуру?

Публичный сертификат показывает перечисленные имена. Если туда добавить служебные или тестовые поддомены, они станут видимы при анализе сертификата.

Стоит ли включать корпоративный VPN и публичный кабинет в один SAN-сертификат?

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

SAN-сертификат подходит для кабинета и нескольких VPN серверов?

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