Когда на одном IP-адресе живут десятки доменов, SSL перестаёт быть рутиной и превращается в отдельный проект: ручная выдача сертификатов, путаница с цепочками, неожиданные предупреждения браузера у части клиентов. Именно здесь на первый план выходит SNI (Server Name Indication) – расширение TLS, которое позволяет серверу отдавать разным доменам разные сертификаты на одном IP и порту 443. Без него пришлось бы либо покупать дорогой multi-domain сертификат, либо поднимать отдельный IP под каждый сайт.
Разбираем пошаговую настройку SNI на сервере: от генерации CSR и получения сертификатов до конфигурации виртуальных хостов и проверки результата. Отдельно остановимся на типичных ошибках – несовпадение цепочек, конфликты приоритетов SNI, забытые промежуточные сертификаты – и покажем, как их диагностировать. А затем посмотрим, как российский аналог Cloudflare, платформа TrafficVeil, снимает большую часть ручной работы: DNS, SSL, reverse proxy, WAF, защита от ботов, L7 DDoS, GeoIP-фильтрация и аналитика работают в одном контуре, а SNI настраивается централизованно.
Тема особенно актуальна в 2026 году: Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Бизнес в России ищет альтернативу Cloudflare, и замена Cloudflare на локальную веб-платформу становится не только вопросом регуляторных требований, но и вопросом конверсии сайта и лидогенерации: недоступный ресурс не приносит заявок. Ниже – практика, которую можно повторить на своём сервере.
Почему мультидоменные проекты требуют особого подхода к SSL
Один IP-адрес на несколько доменов перестал быть экзотикой: маркетплейсы, SaaS-платформы, сети региональных сайтов и интернет-магазины с отдельными витринами под каждый бренд держат десятки и сотни хостов на одном балансировщике. Проблема в том, что TLS-рукопожатие исторически устроено так, что клиент сначала устанавливает шифрованный канал и только потом сообщает, к какому домену обращается. Серверу приходится выбирать сертификат до того, как он узнает имя хоста. До появления SNI единственным рабочим обходом был один сертификат, покрывающий все имена сразу, либо отдельный IP на каждый домен. И то и другое на практике упирается в ограничения.
Классический подход с выделенным IP на домен не масштабируется. IPv4-адреса в российских дата-центрах тарифицируются отдельно, а переход на IPv6 решает проблему лишь частично: значительная доля клиентских сетей и корпоративных прокси до сих пор работает только по IPv4. При 50 доменах вы получаете 50 адресов, 50 записей в конфигурации балансировщика и рост стоимости хостинга, который никак не связан с полезной нагрузкой. Плюс каждый IP нужно отдельно включать в белые списки у платёжных провайдеров и партнёров.
Wildcard-сертификат выглядит как компромисс, но покрывает только один уровень поддоменов. Сертификат на *.example.ru защитит shop.example.ru и api.example.ru, но не подойдёт для example.ru без поддомена, не покроет shop.example.com и уж точно не сработает для десятков независимых доменов разных клиентов. Расширение до multi-domain (SAN) сертификата упирается в лимиты: большинство удостоверяющих центров принимают не более 100 имён в один сертификат, а каждое изменение списка требует перевыпуска и переустановки. Для платформы, где клиенты подключают собственные домены ежедневно, это превращается в постоянную ручную работу.
SNI (Server Name Indication) снимает это ограничение. Клиент передаёт имя хоста в первом же пакете ClientHello, до выбора сертификата, и сервер отдаёт нужный сертификат из хранилища. Один IP обслуживает неограниченное число доменов, у каждого свой сертификат и свой срок действия. Отзыв или перевыпуск одного сертификата не затрагивает остальные. Это критично, когда домены принадлежат разным юридическим лицам и падение одного не должно ронять всю платформу.
Отдельные сертификаты на каждый домен дают и практические преимущества. Мониторинг сроков идёт по каждому имени, а не по общему SAN-списку, где забытое имя тихо истекает вместе с остальными. При инциденте с компрометацией ключа отзывается только один сертификат, а не весь пул. Для регуляторных требований, когда нужно доказать, что данные конкретного клиента защищены его собственным ключом, раздельные сертификаты проще обосновать.
Цена решения: SNI не поддерживают клиенты на Windows XP и Android ниже 4.4, но их доля в 2026 году измеряется десятыми долями процента. Если аудитория включает устаревшие корпоративные терминалы, для них оставляют один fallback-сертификат на дефолтном виртуальном хосте. Также стоит учитывать, что при SNI имя хоста передаётся в открытом виде до установки шифрования. ECH (Encrypted Client Hello) закрывает эту утечку, но поддержка в российских сетях пока фрагментарна.
Итог: для мультидоменного проекта выбор стоит между дорогим зоопарком IP-адресов, хрупким wildcard-сертификатом и SNI с отдельными сертификатами. Последний вариант даёт масштабируемость, изоляцию сбоев и предсказуемую стоимость. Дальше разберём, как настроить его на сервере пошагово.
Пошаговая настройка SNI на сервере для нескольких доменов
SNI (Server Name Indication) позволяет держать на одном IP десятки доменов с разными сертификатами: клиент передаёт имя хоста в первом пакете TLS-рукопожатия, сервер выбирает подходящий сертификат. Ниже процедура для Nginx и OpenSSL, которая масштабируется на 20-50 доменов без ручного пересбора конфигов.
Порядок действий: от CSR до проверки
Шаг 1. Инвентаризация. Соберите список доменов и поддоменов: например, shop.example.ru, api.example.ru, static.example.ru. Определите, где нужен один сертификат на группу (SAN) и где дешевле выпустить раздельные. Для 5-10 имён в одном домене второго уровня выгоднее один SAN-сертификат: меньше точек отказа, одна дата продления.
Шаг 2. Генерация ключа и CSR. Для каждого сертификата создайте приватный ключ и запрос:
openssl genrsa -out example.key 2048(или ECDSA:openssl ecparam -genkey -name prime256v1 -out example.key);openssl req -new -key example.key -out example.csr -subj "/CN=example.ru";- для SAN добавьте расширение:
-addext "subjectAltName=DNS:example.ru,DNS:www.example.ru,DNS:api.example.ru".
Проверьте CSR перед отправкой в CA: openssl req -in example.csr -noout -text. Убедитесь, что в SAN нет опечаток, иначе сертификат придётся перевыпускать.
Шаг 3. Получение сертификата. Для публичных доменов подойдёт ACME (Let's Encrypt, российские УЦ с ACME-эндпоинтом) или коммерческий CA с OV/EV. Валидация DNS-01 удобнее HTTP-01: не требует открывать 80-й порт и работает для wildcard. После выпуска соберите полную цепочку: cat domain.crt ca_bundle.crt > fullchain.pem. Порядок критичен: сначала листовой сертификат, затем промежуточные.
Шаг 4. Конфигурация виртуальных хостов. В Nginx каждый домен получает свой server-блок с директивами listen 443 ssl и server_name, а сертификаты указываются отдельно. Минимальный шаблон:
server {
listen 443 ssl http2;
server_name shop.example.ru;
ssl_certificate /etc/ssl/shop/fullchain.pem;
ssl_certificate_key /etc/ssl/shop/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
root /var/www/shop;
}
Повторите блок для каждого домена. SNI в Nginx включён по умолчанию при сборке с OpenSSL 0.9.8f и выше; проверьте флаг: nginx -V 2>&1 | grep -o with-http_ssl_module. Если сертификатов много, вынесите общие параметры (ciphers, HSTS, OCSP stapling) в отдельный файл и подключайте через include.
Шаг 5. Проверка. Перезагрузите конфигурацию: nginx -t && systemctl reload nginx. Затем проверьте каждый домен:
openssl s_client -connect 203.0.113.10:443 -servername shop.example.ru– в выводе должен быть нужный CN и полная цепочка;curl -svI https://api.example.ru --resolve api.example.ru:443:203.0.113.10– проверка без правки DNS;- внешние сканеры (SSL Labs, testssl.sh) покажут поддержку SNI, срок жизни сертификата и уязвимые шифры.
Если s_client без флага -servername отдаёт сертификат по умолчанию (первый блок в конфиге), это нормально: клиенты без SNI получат дефолтный сертификат. Для доменов, куда ходят старые устройства без SNI, держите отдельный IP.
Практический нюанс: при продлении сертификатов через cron добавляйте systemctl reload nginx после успешного обновления, иначе сервер продолжит отдавать старый сертификат до ручной перезагрузки. Для 30+ доменов автоматизируйте выпуск через certbot с плагином --nginx или acme.sh с DNS-API, а инвентарь доменов храните в git, чтобы конфигурация воспроизводилась на новом сервере за минуты.
Типичные ошибки при настройке SSL для мультидоменных проектов и их решение
Большинство сбоев SNI на мультидоменных проектах воспроизводится за пять минут, если знать, где смотреть. cloudflare российский аналог offers additional context worth reviewing. Логика такая: сначала проверяем, какой сертификат реально отдаёт сервер, потом цепочку, потом приоритеты виртуальных хостов, и только затем копаем в конфигурации приложения.
Ошибка 1. Несовпадение цепочки сертификатов. Симптом: браузер пишет "неполная цепочка" или часть клиентов (мобильные приложения, парсеры, старые Android) отказывается от соединения, хотя в Chrome всё открывается. Причина в том, что в ssl_certificate указан только листовой сертификат без промежуточного. Проверка одной командой:
Если видите verify error:num=21:unable to verify the first certificate, промежуточный сертификат отсутствует. Лечится конкатенацией: листовой + intermediate в один файл. Порядок важен, корневой сертификат в файл класть не нужно.
Для мультидоменного проекта проверяйте цепочку отдельно по каждому имени: -servername заставляет сервер выбрать нужный контекст, и на одном домене цепочка может быть полной, а на другом нет.
Ошибка 2. Конфликты приоритетов SNI. Когда на одном IP висит десять доменов, а в конфигурации nginx первым идёт default_server с сертификатом не от того домена, клиент получает чужой сертификат. Признак: curl -v https://site.ru показывает CN другого проекта. В nginx работает правило: если SNI в запросе не совпал ни с одним server_name, отдаётся первый блок или помеченный default_server. Решение:
- явно помечайте default_server на техническом блоке с self-signed сертификатом;
- проверяйте, что server_name содержит все алиасы, включая www;
- не дублируйте один и тот же server_name в двух блоках: nginx возьмёт первый и промолчит.
Проверка приоритетов без браузера:
Команда показывает, какой именно сертификат выбран для конкретного SNI, и сразу снимает вопрос "почему не тот домен".
Ошибка 3. Ошибки в конфигурации виртуальных хостов. Типовые грабли: сертификат обновлён, а nginx не перечитал конфиг (nginx -t && nginx -s reload); путь к файлу верный, но права 600 root:root и воркер под www-data не читает ключ; ssl_protocols и ssl_ciphers заданы только в одном блоке, а остальные домены падают на TLS 1.0. Ещё один частый случай: HSTS прописан на поддомене, который позже перевели на HTTP, и браузеры год не пускают пользователей на сайт.
Ошибка 4. Рассинхрон при автоматическом продлении. Certbot обновляет сертификат по одному домену, а в конфигурации прописан общий fullchain, собранный вручную. Через 90 дней часть доменов получает просроченный сертификат. Решение: либо один сертификат на все имена в SAN, либо отдельный путь к файлам для каждого домена и хук на reload nginx после каждого обновления.
Ошибка 5. GeoIP и балансировщики ломают SNI. Если перед сервером стоит L7-прокси или CDN, он терминирует TLS и передаёт трафик дальше по HTTP. Тогда SNI на бэкенде не виден вообще, и все домены попадают в default_server. Проверяется по заголовку Host в логах бэкенда: если там IP вместо домена, цепочка настроена неверно.
Практический порядок диагностики для мультидоменного проекта: openssl s_client по каждому SNI, затем nginx -T для проверки фактического конфига, затем логи error.log с уровнем info на предмет "no matching server". Эти три шага закрывают примерно 90% инцидентов с SSL на нескольких доменах.
Использование российских аналогов Cloudflare для управления SSL на мультидоменных проектах
Ручная настройка SNI на каждом сервере работает, пока доменов десяток и серверов два. Как только мультидоменный проект разрастается до 50-200 имён, а инфраструктура распределяется по нескольким площадкам, поддержка конфигураций вручную превращается в отдельную статью расходов. Именно на этом этапе бизнес в России ищет альтернативу Cloudflare: централизованное управление сертификатами, автоматическое продление и единая точка отказа вместо зоопарка из nginx, certbot и самописных скриптов.
Ограничение, о котором стоит помнить: Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры, в свою очередь, ограничивают доступ к сайтам на Cloudflare. Для проекта, ориентированного на локальную аудиторию, это прямой удар по конверсии сайта и лидогенерации. Зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса: блокировка аккаунта, отказ в обслуживании, внезапная недоступность панели управления в момент инцидента.
TrafficVeil и другие российские аналоги: что закрывают по SSL и SNI
TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели. Для мультидоменных проектов ключевое здесь то, что все домены обслуживаются на одном IP через SNI: платформа сама сопоставляет входящий ClientHello с нужным сертификатом, а вам остаётся добавить домен и подтвердить владение.
Практический сценарий перехода с ручной схемы выглядит так:
- Домен переводится на DNS-сервис платформы: меняются NS-записи у регистратора, зона подтягивается автоматически.
- Выпускается SSL-сертификат на каждое имя. Wildcard закрывает поддомены одного уровня, отдельные сертификаты нужны для доменов разных зон и для имён вида shop.client-a.ru и shop.client-b.ru.
- Трафик идёт через reverse proxy: платформа терминирует TLS, применяет WAF-блокировки и правила GeoIP-фильтрации, затем передаёт запрос на origin по HTTP или HTTPS.
- Обновление сертификатов происходит по расписанию. Просроченный сертификат на одном из 80 доменов перестаёт быть риском, который кто-то должен заметить вручную.
Экономика вопроса часто перевешивает техническую сторону. TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, тогда как у Cloudflare всплеск L7 DDoS на мультидоменном проекте может привести к перерасходу плана. Для сайтов, интернет-магазинов, WordPress и Bitrix это предсказуемая стоимость: платите за легитимный трафик, а не за атаку.
Российские альтернативы условно делятся на три группы. Первая – CDN и защита от DDoS от операторов связи, где SSL настраивается через поддержку и занимает дни. Вторая – облачные WAF-сервисы с почасовой тарификацией запросов, что для мультидоменного проекта с сотнями тысяч запросов в сутки даёт непредсказуемый счёт. Третья – платформы полного цикла, где DNS, SSL, SNI и защита управляются из одного интерфейса. TrafficVeil относится к третьей группе и предлагает переход с Cloudflare с сохранением логики работы: те же правила, тот же порядок действий, но инфраструктура внутри российского периметра.
Что проверить перед миграцией мультидоменного проекта:
- Список всех доменов и поддоменов с указанием, где сейчас выпускаются сертификаты и кто отвечает за продление.
- Наличие имён в зонах, которые не поддерживаются wildcard-сертификатом: их придётся заводить отдельно.
- Требования к TLS: минимальная версия протокола, набор шифров, поддержка HTTP/2 и HTTP/3 на стороне платформы.
- Совместимость с регуляторными требованиями: где хранятся ключи, кто имеет к ним доступ, как фиксируются события.
- План отката: возможность вернуть A-записи на исходный сервер в течение часа, если что-то пойдёт не так.
TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, поэтому один и тот же мультидоменный проект может обслуживать локальных клиентов через российские узлы, а зарубежных – через ближайшие точки присутствия, без раздельных конфигураций SSL. Это снимает главную боль ручной схемы: сертификаты, SNI и маршрутизация перестают быть набором разрозненных задач и становятся одним управляемым слоем.
Практичный способ проверить свою конфигурацию перед запуском: соберите список всех доменов и поддоменов проекта, включая тестовые и staging-адреса, и прогоните каждый через openssl s_client -connect IP:443 -servername домен. Утилита покажет, какой именно сертификат отдаёт сервер для конкретного SNI, полную цепочку и даты действия. Если для какого-то имени возвращается не тот сертификат или цепочка обрывается на промежуточном CA, проблема в конфигурации виртуального хоста, а не в самом сертификате. Проверку стоит автоматизировать: cron-задача раз в сутки с логированием результата дешевле, чем разбор инцидента с браузерными предупреждениями в разгар трафика.
Дальше решите, где будет жить TLS-терминация. Вариант с собственными серверами даёт полный контроль, но требует ручной ротации сертификатов и мониторинга цепочек на каждом узле. Вариант с внешней платформой снимает эту нагрузку: российский аналог Cloudflare TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику, поэтому сертификаты для всех доменов проекта выпускаются и продлеваются централизованно на одном IP. Платформа не тарифицирует ботов, атаки и WAF-блокировки, что важно для проектов с лидогенерацией, где всплеск паразитного трафика иначе бьёт по бюджету. Для сайтов, интернет-магазинов, WordPress и Bitrix переход с Cloudflare занимает предсказуемое время: сначала переносятся DNS-записи, затем проверяется выдача сертификатов по каждому SNI, и только после этого трафик переключается полностью. Начните с одного некритичного поддомена: прогоните его через TrafficVeil, сравните результат openssl-проверки с текущим сервером и убедитесь, что цепочка и SNI отрабатывают корректно. Это даст рабочую точку отсчёта для миграции остальных доменов без риска для основного трафика.