SSL-сертификаты wildcard, multiSAN и per-service: как выбрать под свою инфраструктуру

SSL/TLS-сертификаты уже давно не про «сделать зелёный замочек». Для админа или DevOps это вопрос управляемости инфраструктуры: сколько сертификатов выпускать, куда их разворачивать, как автоматизировать продление и не словить массовый отказ по просрочке.

Ключевой выбор в реальных проектах обычно сводится к трём моделям:

• wildcard-сертификат на целую зону;
• SAN / multiSAN-сертификат на набор конкретных имён;
• per-service: отдельный TLS-сертификат на каждую службу или домен.

Дальше — подробный разбор, когда имеет смысл выбирать wildcard, когда multiSAN, а когда проще жить с per-service, плюс типовые грабли и схемы комбинирования.

Кратко про терминологию: SSL, TLS, SAN и wildcard

Формально сегодня корректнее говорить «TLS-сертификат», но в документации и панелях по инерции чаще употребляется «SSL». В контексте статьи будем использовать оба термина как синонимы, имея в виду современные версии TLS (1.2/1.3).

Два ключевых понятия:

• wildcard — сертификат вида *.example.com, покрывающий все поддомены первого уровня: api.example.com, www.example.com, app1.example.com и т.п. Сам домен example.com при этом не покрывается, его нужно добавлять отдельно (через SAN или отдельный сертификат);
• SAN / multiSAN — сертификат с несколькими именами в полях subjectAltName. Например: example.com, www.example.com, api.example.com, client.example.net и т.д.

Под per-service далее будем понимать модель, когда на каждый сервис или домен выдаётся отдельный сертификат, часто — отдельный ACME-клиент или отдельный Issuer (в Kubernetes).

Wildcard-сертификаты: когда удобно, а когда опасно

Wildcard воспринимается как «один сертификат на всё» — и это действительно мощный инструмент. Но за удобство приходится платить как деньгами, так и рисками.

Плюсы wildcard

• Гибкость DNS. Можно свободно поднимать новые поддомены без перевыпуска сертификатов. Это удобно для динамических окружений (dev/stage/feature-ветки), мультиарендных SaaS с шаблоном clientN.example.com, субдоменов вроде cdn1.example.com, api2.example.com и т.д.
• Простое масштабирование через reverse proxy. Один wildcard можно положить на фронт Nginx/HAProxy/Envoy и терминировать HTTPS сразу для всех сервисов в зоне *.example.com. Добавление нового backend-а не требует трогать TLS.
• Меньше записей в CT-логах. Само по себе это не security-фича, но кто-то не любит светить все служебные сабдомены в Certificate Transparency. С wildcard вы публикуете только сам факт существования *.example.com, а не каждого internal-jenkins-01.example.com.

Минусы wildcard

• Единая точка компрометации. Утекший приватный ключ wildcard-сертификата означает компрометацию всей зоны поддоменов сразу. Если ключ разошёлся по десятку серверов, аудит и отзыв превращаются в квест.
• DNS-01 для выпуска. Для большинства ACME-клиентов wildcard требует DNS-01-челлендж. Это значит, что автоматизация сильно завязана на API DNS-провайдера. Если у вас нет API или зона на корпоративном DNS без автоматики, жизнь усложняется.
• Не покрывает домен второго уровня. *.example.com не валиден для example.com. Либо добавляем example.com в SAN при выпуске, либо выпускаем отдельный сертификат.
• Обычно дороже у коммерческих CA по сравнению с DV-сертификатами одного домена.

Где wildcard — хороший выбор

• Фронтовый балансировщик / reverse proxy для нескольких десятков поддоменов одной зоны, когда TLS-терминация централизована;
• Staging окружения и preview-ветки: feature-123.branch.example.com, qa.example.com, perf.example.com;
• Мелкий или средний SaaS с выдачей поддомена арендаторам: clientX.example.com.

Если всё это живёт на одном-двух фронтовых узлах, где хранится единая копия ключа, риски легче контролировать.

Когда wildcard лучше избегать

• Если вы не контролируете все сервера, где нужен TLS (например, сабдомены обслуживают сторонние подрядчики);
• Если ключ придётся развозить по большому зоопарку машин и сервисов (микросервисы без SNI-aware балансировщика прямо в интернет);
• Если у вас строгие требования по разделению зон доверия: разные команды или бизнес‑юниты не должны иметь доступ к единому ключу.

Правило здравого смысла: если вы не можете перечислить все места, куда попадёт приватный ключ wildcard, — не используйте wildcard как универсальное решение.

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

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

Подробнее

SAN / multiSAN-сертификаты: оптимум между удобством и безопасностью

MultiSAN- или просто SAN-сертификат — это один сертификат, в котором перечислено сразу несколько FQDN. Например:

CN=example.com
subjectAltName = DNS:example.com,
                  DNS:www.example.com,
                  DNS:api.example.com,
                  DNS:client.example.net

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

Сильные стороны multiSAN

• Гибкость по зонам. В один сертификат можно включить домены из разных зон: example.com, example.net, example.org.
• Меньше ключей и файлов в конфигурации. На одном балансировщике или фронтовом веб-сервере вы держите один ключ и один сертификат, обслуживающий несколько доменов.
• Удобен для «набора витрин»: корпоративный сайт, блог, документация, панель клиента — всё это чаще всего размещается на одном или нескольких фронт-узлах и может быть покрыто одним SAN-сертификатом.
• Контролируемая поверхность компрометации. В отличие от wildcard, компрометация ключа затрагивает только конкретный список имён, а не всю зону поддоменов.

Ограничения и подводные камни multiSAN

• Нужно знать список имён заранее. Каждое добавление нового домена или поддомена требует перевыпуска сертификата. В динамичных инфраструктурах это неудобно.
• Размер сертификата. Большие SAN-списки увеличивают размер handshake и могут влиять на время установления соединения (обычно не критично, но в high‑latency сценариях может быть заметно).
• Лимиты CA. Некоторые центры сертификации ограничивают число SAN-записей в одном сертификате или берут доплату за каждый SAN сверх базового лимита.

Типичные сценарии для SAN / multiSAN

• Маркетинговые витрины: example.com, www.example.com, blog.example.com, docs.example.com;
• Группа небольших проектов, которыми управляет одна команда и которые живут на одном кластере/балансировщике;
• Точечная замена wildcard, когда нужны всего 3–5 предсказуемых имён, а полноценный wildcard избыточен и дороже.

Per-service TLS: максимум изоляции и автоматики

Per-service (по одному сертификату на домен/сервис) — наиболее гибкая модель, которая хорошо сочетается с ACME-автоматизацией и современными оркестраторами.

Выглядит это так:

• www.example.com — свой сертификат;
• api.example.com — отдельный сертификат;
• static.example.com — ещё один сертификат;
• client1.example.com, client2.example.com и т.д. — у каждого свой.

Плюсы per-service модели

• Минимальная blast radius. Утечка ключа затрагивает только один домен. Подходит под строгие требования по разделению контуров.
• Простая интеграция с ACME. Многие ACME-клиенты (certbot, lego, acme.sh, cert-manager, Traefik) по умолчанию работают в per-domain парадигме.
• Удобно для микросервисов и Kubernetes. В k8s per-service TLS через ресурсы Ingress и Certificate — фактический стандарт де-факто.
• Локальная ротация. Одному сервису можно сменить сертификат или ключ, не трогая остальные.

Минусы per-service TLS

• Больше объектов управления. Вместо одного wildcard — десятки и сотни сертификатов, если у вас разветвлённая инфраструктура.
• Усложнение мониторинга. Нужно следить за сроком действия каждого сертификата. Это решается централизованным мониторингом, но его надо настроить.
• Больше handshake-вариантов. На одном балансировщике может быть множество SNI-профилей, и их нужно синхронизировать при деплоях.

Где per-service — лучший выбор

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

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Wildcard vs SAN vs per-service: практическое сравнение

Удобнее всего думать через несколько параметров: безопасность, стоимость, удобство DNS, автоматизация, масштабируемость.

Безопасность и зона поражения

• Wildcard: максимальная зона поражения — вся зона поддоменов. Требует аккуратного обращения и минимизации числа хостов, где лежит ключ.
• SAN / multiSAN: компрометация затрагивает фиксированный набор имён. Риски зависят от того, насколько разные по критичности сервисы вы в один список положили.
• Per-service: наименее критичный сценарий утечки. Хорошо ложится в модель Zero Trust и строгий контроль секретов.

Стоимость

• Wildcard: дороже одного DV, но чаще всего выгоднее, чем десятки отдельных коммерческих сертификатов при большом количестве сабдоменов.
• SAN: базовая цена + стоимость SAN-записей (в зависимости от CA). При 3–10 доменах обычно экономичнее, чем набор отдельных коммерческих сертификатов.
• Per-service: при использовании бесплатного ACME финансовая стоимость близка к нулю, но есть операционная стоимость по настройке и поддержке автопродления и мониторинга.

DNS и ACME-челленджи

• Wildcard почти всегда = DNS-01. Нужен автоматизированный DNS или возможность быстро и безопасно управлять TXT-записями. Подробнее про автоматизацию DNS-01 для wildcard можно посмотреть в материале о выпуске wildcard-сертификатов по DNS-01.
• Обычные/SAN-сертификаты могут использовать HTTP-01 или TLS-ALPN-01, что упрощает автоматизацию на веб-сервере или балансировщике.
• Per-service особенно удобно автоматизировать с HTTP-01, если у вас централизованный reverse proxy, который принимает челленджи за все сервисы.

Управляемость и масштабируемость

• Wildcard: один сертификат — просто при малом числе фронтов; сложно, когда ключ нужно развезти по множеству узлов и сервисов.
• SAN: хорошо при умеренном числе доменов, когда вы редко добавляете новые.
• Per-service: отлично масштабируется, если изначально заложено централизованное наблюдение и автоматизация. Плохо, если всё делается руками.

Типичные архитектуры и оптимальный выбор

1. Малый/средний сайт или витрина

Набор имён:

• example.com
• www.example.com
• blog.example.com

Хостится всё на одном или двух веб-серверах или фронтовом балансировщике.

Адекватный выбор:

• либо один SAN-сертификат на перечисленные имена;
• либо два: основной (example.com, www.example.com) и отдельный на блог (если он на другом стеке/хостинге).

Wildcard здесь избыточен, если в планах нет роста числа поддоменов.

2. Монофронт + много сервисов за reverse proxy

Схема: один Nginx/HAProxy на фронте, за ним — несколько backend-сервисов по HTTP. Пользовательские имена:

• www.example.com → frontend
• api.example.com → API
• static.example.com → статика
• clientX.example.com → отдельные арендаторы

Золотая середина — wildcard *.example.com на фронтовый балансировщик (TLS-терминация на нём). Внутри — HTTP, mTLS или внутренние сертификаты от своей CA.

Если есть опасения по единой точке компрометации, можно разделить:

• wildcard на зону *.clients.example.com для арендаторов;
• отдельный SAN или per-service для www.example.com, api.example.com, static.example.com.

3. Микросервисы и Kubernetes

Тут по умолчанию выигрывает per-service модель. Чаще всего:

• на внешний трафик: отдельный сертификат на каждый домен/поддомен, который описан в Ingress;
• внутри кластера: своя PKI или Issuer, который выдаёт сервисные сертификаты для mTLS.

Wildcard иногда используют как bootstrap на внешний Ingress-контроллер (например, *.example.com), но это стоит делать только при хорошей автоматизации и строгом контроле доступа к секретам в namespace.

Комбинированные стратегии: когда один формат — не ответ

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

Стратегия «wildcard на фронте, per-service внутри»

Модель:

• На публичном балансировщике: wildcard *.example.com (или два-три wildcard для разных зон).
• На сервисах в internal-сегменте: отдельные сертификаты (per-service) от внутреннего CA, чаще всего с mTLS.

Плюсы:

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

Стратегия «SAN для витрин, per-service для критичных сервисов»

Модель:

• Маркетинговые сайты и лендинги собираются в 1–2 SAN-сертификата, обновляемые централизованно.
• Платёжный шлюз, админские панели, API — только per-service, чтобы минимизировать blast radius и упростить аудит.

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

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

1. Начните с инвентаризации доменов

Перед тем как решать, нужен ли wildcard или «просто сделаем Let’s Encrypt на каждый домен», составьте список:

• основных продакшн-доменов и поддоменов;
• технических и служебных имён, которые действительно должны быть доступны по HTTPS извне;
• окружений (dev, stage, test, preview) и шаблонов имён для них;
• разных команд и владельцев доменов.

Часто после такой ревизии оказывается, что:

• часть сабдоменов можно убрать вообще;
• часть — объединить в один SAN-сертификат;
• для динамических окружений всё-таки нужен wildcard.

2. Сразу закладывайте мониторинг истечения TLS

Независимо от формата (wildcard, SAN или per-service), обязательно нужно мониторить:

• срок действия сертификата на уровне доменов (через HTTPS-проверку);
• ошибки продления ACME-клиентов и деплоя сертификатов на серверы.

Даже один-единственный wildcard, если он не продлится вовремя, может положить всю зону. Per-service подход защищает от такого тотального отказа, но зато множит число точек, которые надо наблюдать.

3. Минимизируйте распространение приватных ключей

Ключевой аспект безопасности TLS — не формат сертификата, а то, как вы обращаетесь с приватными ключами:

• старайтесь терминировать TLS на минимальном количестве точек (фронтовые балансировщики, edge);
• не раздавайте один и тот же ключ «во все стороны» без необходимости;
• используйте менеджеры секретов, защищённые хранилища, чёткие ACL к каталогам с ключами;
• журналируйте доступ к ключам и автоматические развёртывания сертификатов.

Для wildcard-сертификатов этот пункт особенно критичен: чем меньше хостов видят ключ, тем лучше.

4. Планируйте ротацию и отзыв

Компрометация возможна всегда, независимо от формата сертификата. Рассмотрите заранее:

• как вы будете отзывать сертификат (CRL/OCSP, перевыпуск);
• как быстро сможете развернуть новый сертификат на все фронтовые точки;
• как уведомить команды/клиентов о внеплановой ротации при необходимости.

Для wildcard и SAN-варианта важно понимать, сколько разных доменов/сервисов останется без TLS в момент отзыва, и как этот риск соотносится с удобством единого сертификата.

5. Не усложняйте без необходимости

Частая ошибка — сразу строить «идеальную» схему с внутренними CA, сложными политиками, десятками Issuer-ов и суровой сегментацией, когда у вас всего пара сайтов на одном сервере.

Если инфраструктура небольшая, вполне нормальный стартовый вариант:

• один SAN-сертификат на 2–5 витринных доменов;
• per-service для пары критичных сервисов;
• минимальный мониторинг истечения (внутренняя система или внешний аптайм-мониторинг).

По мере роста проектов схему можно эволюционировать в сторону wildcard + per-service или полностью per-service с внутренней PKI.

Что учесть при работе с доменами и SSL

Напоследок стоит помнить, что выбор формата сертификата тесно связан с управлением доменами и их жизненным циклом.

• Следите за сроками продления доменов и не доводите до периода redemption: аварийный перенос зоны или смена регистратора в последний момент — частая причина падения TLS. Подробно этот кейс разбирали в статье про сроки продления доменов и grace/redemption-периоды.
• При планировании архитектуры сразу определяйтесь, какие домены будут на отдельных проектах/хостингах, а какие можно держать вместе: это облегчит выбор между wildcard, SAN и per-service.
• Если вы только запускаете проекты, удобно сразу завести домены и разместить сайты на надёжном виртуальном хостинге или VDS с поддержкой автоматического выпуска TLS.

Итого: как быстро принять решение

Если свести всё к нескольким проверочным вопросам:

1. У вас много динамических поддоменов по единому шаблону? Если да — смотрите в сторону wildcard на фронте.
2. Список имён небольшой и предсказуемый (2–10) и редко меняется? MultiSAN — хороший баланс.
3. Строгая сегрегация безопасности, много команд, микросервисы, Kubernetes? Per-service — дефолтный вариант.
4. Есть внутренний трафик, который должен быть зашифрован? Рассмотрите собственный CA и отдельные сервисные сертификаты, не связанные с публичными.
5. Готовы ли вы инвестировать время в автообновление и мониторинг? Если да — легче масштабировать per-service; если нет — старайтесь ограничиться небольшим числом централизованных сертификатов.

Главное — воспринимать формат SSL/TLS-сертификата как элемент архитектуры и безопасности, а не просто как необходимость «чтобы работал HTTPS». Тогда выбор между wildcard, SAN и per-service перестаёт быть теоретическим спором и превращается в осознанное архитектурное решение.