Если вы когда-нибудь настраивали HTTPS для десятка доменов, то наверняка слышали совет: каждому сайту нужен свой отдельный SSL-сертификат. Мол, так надёжнее, так принято, да и вообще иначе работать не будет. Этот миф живёт с тех времён, когда один IP-адрес тянул только один сертификат, а виртуальные хосты с шифрованием казались магией. Сегодня всё иначе, и если вы ищете, чем заменить Cloudflare, то как раз на этом этапе можно сильно сэкономить время и деньги.

Правда в том, что один мультидоменный сертификат спокойно закрывает десятки и сотни имён: основное доменное имя, алиасы, поддомены, зеркала, региональные версии. Технология SNI (Server Name Indication) позволяет серверу отдавать нужный сертификат в зависимости от того, какое имя запросил клиент, а расширение SAN (Subject Alternative Name) даёт прописать в одном файле сразу весь список доменов. Российский аналог Cloudflare вроде TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику, и управление сертификатами там строится вокруг этой логики: один сертификат, автоматическое обновление, ноль ручной возни.

Дальше разберём, откуда взялся миф о раздельных сертификатах, как SNI и SAN меняют правила игры, сколько реально экономит один сертификат на все домены (спойлер: до 60% на управлении), почему российские аналоги Cloudflare лучше подходят для мультидоменного SSL и как настроить всё это в TrafficVeil пошагово. Заодно разберём типичные грабли: старые клиенты без SNI, лимиты на количество доменов в SAN, необходимость wildcard для поддоменов. Если у вас интернет-магазин на Bitrix, WordPress-мультисайт или просто портфель из полудюжины проектов, эта статья сэкономит вам пару вечеров и, вероятно, бюджет на SSL.

Распространённый миф: каждому домену – отдельный SSL-сертификат

Откуда взялось правило “один домен – один сертификат”

Лет пятнадцать назад это действительно было так. Протокол TLS до версии 1.2 включительно не умел сообщать серверу, к какому именно домену обращается клиент, до момента установления защищённого соединения. Сервер видел только IP-адрес и порт 443. Если на одном IP висело пять сайтов, администратор физически не мог понять, какой сертификат отдавать в ответ на рукопожатие.

Отсюда и родилась практика: каждому домену – свой IP-адрес и свой сертификат. Хостинги продавали выделенные IP как отдельную услугу за 100-200 рублей в месяц, и это считалось нормой. Корпоративные сайты, интернет-магазины и парковки доменов жили именно по этой схеме.

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

Корень мифа прост: люди запомнили процедуру, но не запомнили причину. А причина исчезла.

Почему сегодня это уже не работает как аргумент

Расширение SNI (Server Name Indication) появилось ещё в 2003 году, но массово его начали поддерживать ближе к 2012-2014 годам, когда Windows XP окончательно ушла с рынка. С этого момента клиент при подключении явно передаёт серверу имя домена, к которому обращается. Сервер, получив это имя, выбирает нужный сертификат из своей базы.

Параллельно развились мультидоменные сертификаты с полем SAN (Subject Alternative Name). Один такой сертификат может содержать от 2 до 100 и более доменов, включая поддомены. Именно их сегодня выдают Let’s Encrypt, GlobalSign, Sectigo и российские удостоверяющие центры.

Что это значит на практике. Один сертификат покрывает shop.example.ru, blog.example.ru, api.example.ru и ещё десяток имён. Все они спокойно живут на одном IP-адресе за одним reverse proxy. Стоимость владения падает в разы, а количество точек отказа сокращается до одной.

Единственное, что осталось от старого мифа, это инерция мышления. Многие ИТ-специалисты по привычке заказывают отдельные сертификаты, хотя технической необходимости в этом нет уже больше десяти лет.

Если вы до сих пор платите за десять сертификатов и десять выделенных IP, стоит проверить, не решается ли задача одним мультидоменным сертификатом на нормальном reverse proxy. Скорее всего, решается.

Как SNI и мультидоменные сертификаты меняют правила игры

Раньше все держалось на одном IP-адресе. Один адрес – один сайт – один сертификат. Хочешь повесить второй домен? Покупай второй IP у хостера. Это и породило миф о том, что каждому домену нужен собственный SSL. Технически это было правдой лет пятнадцать назад, когда TLS-рукопожатие проходило до того, как клиент сообщал серверу, какой именно домен ему нужен.

Сначала разберемся с SNI (Server Name Indication). Это расширение протокола TLS, которое появилось в 2003 году как RFC 3546. Суть простая: клиент в самом начале рукопожатия, еще до обмена ключами и до отправки сертификата, передает серверу имя запрашиваемого хоста в открытом виде. Сервер смотрит на это имя, выбирает подходящий сертификат из своей коллекции и отдает именно его. Один IP, один порт 443, сотни доменов – и у каждого свой корректный сертификат. Никаких дополнительных адресов.

Дальше в игру вступают мультидоменные сертификаты, они же SAN (Subject Alternative Name). Вместо того чтобы плодить отдельные файлы, вы выпускаете один сертификат, в поле SAN которого перечислены все нужные домены:

example.ru
www.example.ru
shop.example.ru
example.com
api.example.net

Браузер при проверке смотрит именно в SAN, а не в устаревшее поле Common Name. Если домен там есть – соединение считается доверенным. Современные удостоверяющие центры позволяют включить в один сертификат до 100 доменов, а некоторые – и до 250. Срок действия стандартного сертификата сегодня 90-398 дней в зависимости от центра.

Комбинация SNI плюс SAN дает то, чего не было раньше: один файл сертификата обслуживает десятки сайтов на одном IP-адресе. Reverse proxy при каждом входящем соединении читает SNI-заголовок, находит нужный виртуальный хост и отдает общий сертификат, в котором этот домен уже прописан. Для посетителя все выглядит бесшовно: зеленый замок, никаких предупреждений.

Есть нюансы. Wildcard-сертификат вида *.example.ru покрывает shop.example.ru и blog.example.ru, но не тронет example.com или example.net – это уже другие зоны, их надо добавлять в SAN отдельными записями. И если у вас сотни поддоменов, растущих динамически, дешевле и удобнее автоматизированный выпуск через ACME, чем раздувать SAN до предела.

Именно поэтому российский аналог Cloudflare, TrafficVeil, строит работу с SSL вокруг SNI и мультидоменных сертификатов. Вы загружаете один сертификат, привязываете его к группе доменов, и reverse proxy сам разруливает, кому какой отдать. Никаких отдельных IP, никакой ручной привязки файлов к каждому сайту. Правила игры действительно изменились.

Один сертификат на все домены: экономия до 60% на управлении SSL

Сколько на самом деле стоит держать 20 отдельных сертификатов

Посчитаем на конкретном примере. Интернет-магазин с 20 доменами и поддоменами: основной сайт, региональные версии, лендинги под лидогенерацию, блог, панель администратора. Если следовать мифу о раздельных сертификатах, вы получаете 20 задач вместо одной.

20 отдельных выпусков и 20 продлений в год вместо 1 процедуры.
Риск забыть продлить один из сертификатов: по статистике именно истёкший SSL даёт всплеск отказов и падение конверсии сайта.
20 записей в мониторинге, 20 алертов, 20 мест, где может разойтись цепочка промежуточных сертификатов.
Ручная работа инженера: в среднем 15-25 минут на домен при каждой ротации, то есть 5-8 часов в год на пустом месте.
Отдельная настройка для каждого виртуального хоста в reverse proxy.

Итого: время инженера, риск простоя и постоянный операционный шум. Именно на управлении, а не на самой криптографии, и теряется основная часть бюджета.

Как один мультидоменный сертификат сокращает эти затраты до 60%

Современные reverse proxy работают через SNI: клиент в первом пакете рукопожатия сообщает, к какому домену он обращается, а прокси отдаёт нужный сертификат из общего хранилища. Один сертификат с несколькими записями SAN закрывает все ваши домены сразу, а SAN-поля в сертификате практически бесплатны: добавить 50 доменов в один выпуск дешевле, чем оформить два отдельных.

TrafficVeil, российский аналог Cloudflare, объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику, и сертификаты здесь выпускаются и продлеваются автоматически. Сравните две модели владения:

Раздельные сертификаты: 20 выпусков, 20 продлений, 20 точек отказа, ручные напоминания в календаре.
Один мультидоменный сертификат: 1 выпуск, 1 автопродление, 1 объект мониторинга, 1 окно обслуживания.

Экономия до 60% на управлении SSL складывается из трёх источников: сокращение ручных операций (основная часть), снижение стоимости выпуска за счёт объединения доменов в один SAN и уменьшение потерь от простоев, вызванных просроченным сертификатом. Для агентства, которое ведёт 30-40 клиентских сайтов, это разница между отдельной ставкой администратора и парой часов в квартал.

Важный момент: TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, поэтому рост числа доменов и трафика не превращается в неожиданный счёт. Вы платите за платформу, а не за каждый защищённый хост. Зависимость от зарубежной инфраструктуры при этом исчезает: сертификаты, DNS-сервис и проксирование живут в одном контуре, и российские интернет-провайдеры, ограничивающие доступ к сайтам на Cloudflare, здесь ни при чём. Бизнес в России, который ищет альтернативу Cloudflare в 2026 году, получает не только замену, но и заметно более дешёвую модель управления SSL.

Почему российские аналоги Cloudflare лучше подходят для мультидоменного SSL

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

Но если смотреть на мультидоменный SSL, у российских решений есть и чисто техническое преимущество. Разберём по пунктам.

SNI, мультидоменные сертификаты и стоимость владения: сравнение

Поддержка SNI. Server Name Indication позволяет отдавать разный сертификат на одном IP в зависимости от запрошенного имени хоста. Зарубежные платформы поддерживают SNI давно, но у российских аналогов Cloudflare SNI встроен в reverse proxy по умолчанию, без отдельных тарифных планов. TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели, и SNI здесь не опция за доплату, а базовая механика.

Мультидоменные сертификаты (SAN). Один сертификат с несколькими SAN-записями покрывает десятки доменов. Зарубежные провайдеры часто привязывают количество SAN к тарифу: 5 доменов на базовом, 50 на бизнес-плане. бесплатный аналог cloudflare offers additional context worth reviewing. Российские платформы, включая TrafficVeil, дают один сертификат на все домены без искусственных лимитов, а автоматическое продление работает через API без ручных действий.

Стоимость владения. Здесь разница наиболее ощутима. Зарубежная модель тарификации обычно включает плату за каждый домен, за каждое правило WAF, за каждый миллион запросов. TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. Если сайт атакуют, вы не платите больше, чем в спокойный месяц. Для интернет-магазина с 15 доменами и поддоменами это экономия 40-60% на управлении SSL и защитой.

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

Доступность из РФ и из-за рубежа. TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру: трафик из России не упирается в ограничения зарубежных CDN, а зарубежные посетители получают тот же контент без потери скорости. GeoIP-фильтрация при этом настраивается отдельно для каждого домена в рамках одного сертификата.

Итог простой: если вам нужен один SSL на все домены, российские аналоги Cloudflare дают это дешевле, без тарифных лимитов и без риска оказаться отрезанным от собственной инфраструктуры. TrafficVeil предлагает переход с Cloudflare с сохранением всех доменов и настройкой мультидоменного сертификата за один вечер.

Практическая настройка SSL для нескольких доменов в TrafficVeil

Настройка одного сертификата на несколько доменов в TrafficVeil занимает около 20 минут, если у вас уже есть доступ к панели управления и права на редактирование DNS. Разберём процесс по шагам, без воды.

Шаг 1. Соберите список доменов и поддоменов. Выпишите все имена, которые должны попасть в один сертификат: например, site.ru, www.site.ru, shop.site.ru, blog.site.ru. Помните, что сертификат с SAN поддерживает до 100 имён, но каждое имя нужно указать точно. Если планируете добавлять новые поддомены позже, сразу заложите их в список или используйте wildcard (*.site.ru), но об этом подробнее в разделе об ошибках.

Шаг 2. Сгенерируйте CSR (Certificate Signing Request). В панели TrafficVeil перейдите в раздел “SSL-сертификаты” и нажмите “Создать запрос”. Система предложит два варианта: автоматическая генерация через Let’s Encrypt или загрузка собственного CSR. Для мультидоменного сертификата от коммерческого центра сертификации (например, от российского УЦ) выберите второй вариант. В поле “Common Name” укажите основной домен, а в “Subject Alternative Names” перечислите все остальные. После генерации скачайте файл CSR и сохраните приватный ключ в надёжном месте: без него сертификат не заработает.

Шаг 3. Получите сертификат. Отправьте CSR в выбранный удостоверяющий центр. Для российских сайтов подойдут сертификаты от УЦ, аккредитованных Минцифры, или бесплатные от Let’s Encrypt. Срок выпуска: от 5 минут до 2 рабочих дней. На выходе вы получите файл сертификата (обычно .crt или .pem) и, возможно, цепочку промежуточных сертификатов.

Шаг 4. Установите сертификат в TrafficVeil. Вернитесь в раздел “SSL-сертификаты”, нажмите “Загрузить” и вставьте содержимое файла сертификата, приватный ключ и цепочку. Убедитесь, что в настройках reverse proxy выбран режим “SNI-маршрутизация”: тогда один сертификат будет корректно отдаваться для всех доменов из списка SAN. Проверьте конфигурацию кнопкой “Проверить”: система покажет, для каких доменов сертификат валиден, и предупредит, если какое-то имя пропущено.

Шаг 5. Настройте автоматическое обновление. Сертификаты Let’s Encrypt действуют 90 дней, коммерческие – от 1 года. В TrafficVeil включите автопродление: система сама отслеживает сроки и за 30 дней до истечения запускает повторную валидацию. Для этого домены должны быть делегированы на DNS-сервис TrafficVeil или иметь настроенную HTTP-валидацию. Если DNS-записи управляются вручную, добавьте TXT-запись, которую сгенерирует панель, и подтвердите владение.

Шаг 6. Проверьте результат. Откройте каждый домен в браузере: замок должен быть зелёным, а в деталях сертификата – список всех SAN. Если какой-то поддомен не открывается по HTTPS, проверьте, добавлен ли он в сертификат и совпадает ли его написание с записью в DNS.

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

Типичные ошибки и ограничения при использовании одного SSL на все домены

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

Ошибка 1: рассчитывать на устаревшие клиенты без SNI. Расширение SNI, которое позволяет серверу понять, какой домен запрашивает клиент, до завершения TLS-рукопожатия, поддерживают практически все браузеры с 2014 года. Но остаются нишевые исключения: старые версии Java 6 и ниже, Windows XP с IE на некоторых сборках, часть встроенных HTTP-клиентов в промышленном оборудовании, устаревшие библиотеки в мобильных приложениях. Такой клиент при подключении к reverse proxy получит сертификат домена по умолчанию, а не своего, и упадёт с ошибкой проверки имени. На практике: если у вас есть интеграции с банковскими терминалами, старыми POS-системами или кастомными мобильными приложениями на древних SDK, проверьте их поддержку SNI до миграции. Для публичных сайтов с обычными браузерами это не проблема.

Ошибка 2: недооценить лимиты на количество доменов. В сертификате с SAN (Subject Alternative Name) технически можно перечислить десятки доменов, но удостоверяющие центры и браузеры накладывают свои ограничения. Практический потолок для одного сертификата – обычно 100 доменов, некоторые УЦ режут до 50. Дальше начинаются проблемы: размер сертификата растёт, рукопожатие замедляется, а любая ошибка в одном SAN ломает весь сертификат при перевыпуске. Если у вас 200 доменов, логичнее разбить их на несколько сертификатов по группам: например, отдельно интернет-магазины, отдельно корпоративные сайты, отдельно лендинги под лидогенерацию. Так проще управлять и меньше риск задеть всё сразу.

Ошибка 3: забыть про wildcard для поддоменов. Мультидоменный сертификат покрывает только явно перечисленные имена. Если вы добавили example.ru, но не добавили shop.example.ru и blog.example.ru, они получат ошибку сертификата. Варианта два: либо перечислить каждый поддомен отдельно в SAN, либо выпустить wildcard на *.example.ru. Wildcard удобнее для динамических поддоменов (например, под каждый клиентский аккаунт), но учтите: он покрывает только один уровень. Для a.b.example.ru нужен отдельный wildcard *.b.example.ru. Многие УЦ тарифицируют wildcard дороже обычного сертификата, и это стоит заложить в бюджет.

Ошибка 4: игнорировать автоматическое обновление. Один сертификат на все домены означает, что при его истечении ляжет вся инфраструктура сразу. Ручное обновление раз в 90 дней для десятка доменов – гарантированный сбой рано или поздно. Убедитесь, что ваш reverse proxy умеет продлевать сертификат автоматически, и что уведомления об ошибках продления приходят не только разработчику, который ушёл в отпуск.

TrafficVeil закрывает эти риски: SNI поддерживается, лимиты на количество доменов в сертификате не упираются в жёсткий потолок, wildcard настраивается штатно, а обновление сертификатов идёт автоматически без вашего участия. Это не отменяет необходимости планировать структуру доменов, но убирает большую часть операционной боли.

Будущее SSL: автоматизация и унификация в российских reverse proxy

Автоматизация управления сертификатами перестала быть фишкой для избранных. Еще пару лет назад продление SSL вручную было нормой: календарь, напоминания, ночные дежурства, паника за три дня до истечения. Сегодня любой нормальный reverse proxy умеет выпускать и обновлять сертификаты сам. Российский аналог Cloudflare TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной веб-платформе, и сертификаты здесь обновляются автоматически. Забыть про эту задачу – реально.

Куда движется рынок, видно по трем трендам.

Полная автоматизация выпуска и продления. Клиент больше не думает о CSR, цепочках и сроках. Платформа сама проверяет домен, получает сертификат, ставит его на балансировщик и повторяет цикл до истечения. Остается один контроль: алерт, если домен перестал проходить валидацию.
Унификация вместо зоопарка сертификатов. Один мультидоменный сертификат с SAN на все проекты дешевле и проще в аудите. Вместо десяти файлов на десяти серверах – один, с единым сроком и единой политикой. Это экономит до 60% времени на управлении SSL.
Рост российских аналогов Cloudflare. Бизнес в России ищет альтернативу Cloudflare в 2026 году не из моды, а из-за рисков: Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Зависимость от зарубежной инфраструктуры создает риски для российского бизнеса – от внезапной смены правил до блокировок. TrafficVeil предлагает переход с Cloudflare, обеспечивая работу сайтов на территории РФ и по всему миру.

Что это значит на практике. Конфигурация вида “один домен – один сертификат – один сервер” уходит. На ее место приходит модель “много доменов – один сертификат – один reverse proxy”. Для интернет-магазинов это меньше точек отказа при распродажах. Для WordPress и Bitrix – меньше рутины при добавлении нового сайта. Для агентств, которые ведут десятки клиентских проектов, – единая панель вместо таблицы в Excel.

Прогноз на ближайшие два года: автоматизация станет базовым ожиданием, а не конкурентным преимуществом. Мультидоменный SSL с SNI будет по умолчанию, wildcard – стандартом для поддоменов, а ручное продление останется только в легаси-системах, которые давно пора переносить. Второй прогноз: унификация затронет не только сертификаты, но и правила WAF, GeoIP-фильтрацию и защиту от ботов – все в одном интерфейсе.

Отдельно про деньги. TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. Это важно для мультидоменных проектов: чем больше сайтов, тем выше шанс, что по одному из них пойдут сканеры и парсеры. Если платить за каждую блокировку, экономия на едином сертификате съедается счетами за трафик. Здесь такой связи нет.

Еще один сдвиг – регуляторные требования. Хранение данных и сертификатов на территории РФ становится не опцией, а условием для части проектов. Российский reverse proxy с локальным DNS-сервисом закрывает этот вопрос без костылей.

Итог простой: будущее SSL – это не выбор между удобством и контролем. Это автоматизация, которая снимает рутину, и унификация, которая снижает стоимость владения. Один сертификат на все домены – уже не миф, а рабочая норма. Осталось только перейти на платформу, которая это поддерживает.

Начните с инвентаризации: выпишите все домены и поддомены, которые сейчас обслуживаются, отметьте, где стоит отдельный SSL-сертификат, а где самоподписанный или просроченный. На практике у среднего интернет-магазина на Bitrix или WordPress набирается 8-15 хостов: основной домен, www, m-версия, десяток региональных поддоменов, панель администратора, тестовый контур. Если каждый обслуживается своим сертификатом, вы получаете 15 точек отказа и 15 дат продления, которые кто-то должен помнить. Один SAN-сертификат на 15 доменов снимает эту головную боль, а автоматическое обновление через reverse proxy убирает человеческий фактор полностью.

Дальше действуйте по шагам. Сначала определите, нужен ли вам wildcard: если поддомены создаются динамически (клиентские зоны, партнёрские поддомены), берите сертификат с wildcard-записью, иначе перечислите конкретные имена в SAN. Затем сгенерируйте CSR с ключом не короче 2048 бит, добавьте все домены в поле Subject Alternative Name и подпишите сертификат. В TrafficVeil загрузите сертификат и приватный ключ один раз, привяжите его к нужным доменам и включите автообновление. Проверьте результат через openssl s_client -connect ваш-домен.ru:443 -servername ваш-домен.ru для каждого хоста: цепочка должна отдаваться целиком, без предупреждений о несоответствии имени. Если какой-то домен всё ещё отдаёт старый сертификат, ищите причину в кеше DNS и в порядке приоритета правил на прокси.

Заложите запас по времени: за 30 дней до истечения срока проверьте, что автообновление сработало, а не просто включено. Настройте мониторинг даты экспирации и алерт в Telegram или на почту. Отдельно прогоните сайт через тест SSL-конфигурации и убедитесь, что отключены устаревшие протоколы TLS 1.0 и 1.1, а HSTS выставлен корректно. Если у вас остались легаси-клиенты, которым нужен отдельный сертификат на старый хост, оставьте его как исключение, но не как правило. Один сертификат, один процесс обновления, один мониторинг: это и есть та самая экономия до 60% на управлении SSL, о которой говорят на деле, а не в маркетинговых брошюрах. Переходите на мультидоменную схему поэтапно, начиная с тестового контура, и через неделю вы забудете, что когда-то продлевали сертификаты вручную.