Wildcard SSL или Multi-Domain SSL: какой сертификат выбрать

В двух словах

Выбор wildcard SSL или multi-domain SSL связан не только с сертификатом, но и с тем, как устроены wildcard DNS и поддомены и базовый SSL для домена.

Wildcard SSL и Multi-Domain SSL решают разные задачи. Wildcard удобен, когда нужно покрыть множество поддоменов внутри одной доменной зоны. Multi-Domain или SAN-сертификат полезен, когда нужно собрать несколько конкретных имён в один сертификат. Ошибка возникает тогда, когда сертификат выбирают «по звучанию», а не по реальной структуре проекта.

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

если у VPN-сервиса уже есть сайт, кабинет, API и несколько служебных хостов;
если вы выбираете сертификат для растущей доменной схемы;
если хотите избежать лишней ручной поддержки SSL на каждом новом поддомене.

Когда лучше wildcard

Wildcard SSL удобен для однотипных поддоменов, но он не должен компенсировать плохую структуру. Сначала стоит разобраться, зачем поддомены вообще нужны.

Wildcard особенно удобен там, где много однотипных поддоменов в пределах одного домена. Например, если есть:

`app.example.com`
`api.example.com`
`help.example.com`
и другие поддомены, которые могут появляться дальше

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

Но wildcard не покрывает всё подряд. Он не решает задачу для других независимых доменов и не всегда хорошо подходит там, где архитектура более разнородная.

Когда лучше Multi-Domain SSL

Заранее известный набор имён проще контролировать через multi-domain сертификат и отдельную проверку, что SSL продлевается и реально отдаётся на сайте.

Multi-Domain или SAN-сертификат удобен, когда у проекта есть ограниченный и понятный список имён:

основной домен;
`www`;
кабинет;
отдельный help-хост;
ещё пара фиксированных адресов.

В такой ситуации удобнее собрать их в один сертификат с понятным списком SAN. Это хорошо работает, если инфраструктура стабильная и новые имена добавляются не каждую неделю.

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

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

Для VPN-сервиса это особенно важно, потому что доменная структура часто растёт вместе с продуктом. Сегодня есть только сайт и кабинет, завтра добавляются API, help, support и другие служебные зоны. Сертификатная схема должна соответствовать реальной жизни проекта, а не картинке из первого дня.

Что проверить руками

Проверить покрытие сертификата можно так:

```bash

openssl s_client -connect example.com:443 -servername example.com </dev/null

openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null

```

Что смотреть:

соответствует ли сертификат имени хоста;
есть ли нужные SAN;
покрывает ли выбранная схема реальные поддомены.

Таблица: что выбирать

| Вариант | Когда использовать | Когда лучше не делать |

|---|---|---|

| Wildcard SSL | Когда много однотипных поддоменов одной зоны | Когда имён мало и они фиксированы |

| Multi-Domain / SAN | Когда набор имён стабилен и известен | Когда поддомены быстро растут и постоянно меняются |

| Отдельные сертификаты | Когда нужен максимальный контроль по зонам | Когда проекту важнее упростить сопровождение |

Та же осторожность нужна и в DNS: wildcard-запись может быть удобной, но легко расширяет поверхность ошибок.

Кейс из практики

У VPN-проекта были основной сайт, кабинет и help-раздел. Сначала команда хотела взять SAN-сертификат, потому что хостов было немного. Но в процессе стало ясно, что доменная схема расширяется: появляются новые поддомены, служебные хосты и дополнительные зоны. После этого перешли на более удобную модель, где wildcard закрыл однотипный пласт поддоменов, а отдельные особые случаи оставили под отдельным контролем.

Быстрая самопроверка

Перед выбором ответьте:

1. сколько поддоменов уже есть;

2. сколько из них появится в ближайшее время;

3. это один домен или несколько независимых имён;

4. важнее ли вам простота сопровождения или жёсткая точечная схема.

Если структура живая и растущая, wildcard часто удобнее. Если она маленькая и чёткая, SAN обычно выглядит спокойнее.

Wildcard помогает только при понятной архитектуре

Wildcard SSL не должен скрывать беспорядок в поддоменах. Если у проекта нет понятной схемы кабинета, API, help-раздела и служебных зон, wildcard лишь упрощает выпуск, но не делает архитектуру безопаснее. Иногда лучше SAN-сертификат с заранее выбранными именами: он дисциплинирует список публичных входов и не поощряет случайное создание поддоменов. Выбор зависит не от количества адресов сегодня, а от того, как команда управляет их жизненным циклом.

После выбора сверяют реальные имена

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

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

Составьте список конечных узлов

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

Не смешивайте роли сертификатов

Сертификат пользователя VPN используется для клиентской аутентификации, если она предусмотрена. Корневой сертификат VPN определяет доверие к центру, а не покрытие имён конечного сервера. SSL VPN требует согласованных настроек клиента и сервера. VPN и HTTPS не становятся одной системой только из-за одинакового формата сертификата.

Распространение и обновление

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

Клиенты и эксплуатация

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

FAQ

Wildcard всегда удобнее?

Нет. Он хорош там, где действительно много однотипных поддоменов.

Multi-Domain — это универсальное решение?

Не совсем. Он хорош для фиксированного списка имён, но хуже масштабируется в хаотичном росте.

Можно ли сочетать разные подходы?

Да. Во многих проектах это как раз и даёт самую удобную схему.

Какой сертификат для VPN выбрать, если узлы обслуживают разные команды?

Если протокол использует TLS, выбирайте схему по границам управления ключами. Один wildcard удобен, но передача его ключа нескольким командам увеличивает последствия компрометации. Раздельные сертификаты на известные имена позволяют независимо менять узлы и отзывать доступ без общей замены ключа.

Wildcard-сертификат подходит для всех адресов VPN сервера?

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