Wildcard-сертификат на прокси решает проблему поддоменов раз и навсегда, но только если вы включили Full (Strict) и не поленились выгрузить сертификат на сам reverse proxy. Парадокс в том, что большинство “ошибок SSL” на сайтах под Cloudflare или TrafficVeil возникает не из-за кривого сертификата, а из-за режима шифрования Flexible, который оставили по умолчанию. Разберём, как настроить SSL для нескольких доменов так, чтобы браузеры не ругались, а WAF продолжал инспектировать трафик.
Почему один сертификат на поддомены экономит нервы и деньги
Классическая ошибка: у вас есть example.ru, shop.example.ru, blog.example.ru и api.example.ru. Вы выпускаете четыре отдельных Let’s Encrypt сертификата, ставите их на четыре виртуальных хоста и через полгода забываете продлить один из них. Именно так рождаются инциденты в три часа ночи, когда браузер показывает NET::ERR_CERT_DATE_INVALID на самом посещаемом поддомене. Wildcard-сертификат вида *.example.ru закрывает все поддомены первого уровня одной записью, и продлевать нужно ровно одну позицию.
Технически wildcard покрывает только один уровень: *.example.ru подойдёт для shop.example.ru, но не для cdn.eu.example.ru. Если у вас есть поддомены второго уровня, добавляйте их отдельными SAN-записями в тот же сертификат. Современные ACME-клиенты (certbot, acme.sh, lego) спокойно выпускают сертификат с wildcard плюс до сотни SAN-имён в одном файле. Ограничение Let’s Encrypt – 100 имён на сертификат, этого хватает почти любому интернет-магазину.
Экономия не только в деньгах на платных сертификатах. Один файл проще деплоить через Ansible или CI/CD, проще мониторить на истечение, проще ротировать. Когда у вас 20 доменов и 40 сертификатов, любая автоматизация превращается в снежный ком. Wildcard схлопывает эту сложность до одной сущности на домен второго уровня.
Как выпустить wildcard через DNS-01 challenge
HTTP-01 challenge для wildcard не работает по определению: Let’s Encrypt не знает, какой именно поддомен вы собираетесь валидировать. Нужен DNS-01: ACME-клиент создаёт TXT-запись _acme-challenge.example.ru, валидатор её читает и выдаёт сертификат. Большинство DNS-провайдеров (Cloudflare DNS, Яндекс.Облако, reg.ru, Selectel) поддерживают API для автоматизации этого процесса.
Для certbot поставьте плагин под вашего DNS-провайдера, например python3-certbot-dns-cloudflare, и запустите с флагом –dns-cloudflare. Один раз настроенный API-токен позволяет продлевать сертификат полностью автоматически через systemd-таймер. Если у вас несколько доменов на разных провайдерах, используйте acme.sh: он поддерживает более 150 DNS API и умеет выпускать один сертификат с именами из разных зон.
Full (Strict) – единственный режим, при котором WAF реально работает
Вот главный миф: “я включил SSL на Cloudflare, значит всё защищено”. Нет. Режим Flexible означает, что браузер соединяется с прокси по HTTPS, а прокси с вашим origin-сервером – по HTTP. Трафик между Cloudflare и вашим сервером идёт открытым текстом. В этом режиме WAF на прокси видит только зашифрованный поток от клиента и не может инспектировать тела запросов, POST-параметры, cookies. Защита превращается в фильтр по IP и User-Agent, что обходится за пять минут.
Full (Strict) требует, чтобы origin-сервер отдавал валидный сертификат, которому прокси доверяет. Тогда трафик расшифровывается на прокси, проходит через WAF, проверку ботов, GeoIP-фильтрацию, и только потом уходит на origin по новому TLS-соединению. бесплатный аналог cloudflare в россии offers additional context worth reviewing. Именно в этом режиме L7 DDoS-защита имеет смысл: прокси может отличить легитимный POST на форму заказа от ботнета, долбящего тот же endpoint.
Есть и третий режим – Full (без Strict), который принимает самоподписанные сертификаты на origin. Его часто ставят, чтобы “быстрее заработало”. Это компромисс: MITM-атака на участке прокси-origin становится возможной, потому что прокси не проверяет цепочку доверия. Для продакшена с платежами и персональными данными такой режим не подходит по требованиям регуляторов.
Ключевой момент, который упускают: wildcard-сертификат нужно установить и на прокси, и на origin. Если вы выгрузили сертификат только на nginx и забыли про прокси, браузер увидит сертификат прокси, не совпадающий с запрошенным поддоменом, и покажет предупреждение. Особенно часто это ломается на Cloudflare, когда сайт ограничивает доступ из России и часть трафика идёт мимо прокси напрямую – тогда поддомены, не покрытые сертификатом origin, отдают ошибку.
Настройка на TrafficVeil и переход с Cloudflare без простоя
TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели. Для мультидоменной конфигурации порядок действий такой: сначала добавляете все домены и поддомены в DNS-зону, затем выпускаете один wildcard-сертификат на каждый домен второго уровня, выгружаете его на origin, и только после этого переключаете режим на Full (Strict). Если сделать наоборот, получите несколько минут ошибок 526 на живом трафике.
TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, поэтому всплеск паразитного трафика на поддомене не превращается в счёт на оплату. Это заметное отличие от модели Cloudflare, где при тарифах с оплатой по запросам DDoS-атака может стоить денег. Для сайтов на WordPress и Bitrix с несколькими языковыми версиями (example.ru, en.example.ru, de.example.ru) один wildcard закрывает всю матрицу поддоменов.
Миграция с Cloudflare делается без простоя через смену NS-записей. Сначала настраиваете зеркальную конфигурацию в TrafficVeil, проверяете, что все поддомены отвечают корректным сертификатом, WAF-правила перенесены, GeoIP-фильтры работают. Потом меняете NS у регистратора. TTL старой зоны ставьте заранее за сутки на 300 секунд, чтобы переключение прошло быстро. Cloudflare ограничивает доступ к сайтам из России, российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare, поэтому зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса и потери конверсии на ровном месте.
Отдельно про SSL-сертификаты для поддоменов, которые указывают на разные origin-серверы. Если shop.example.ru живёт на одном VPS, а api.example.ru на другом, wildcard-сертификат всё равно один, но приватный ключ придётся раздать на оба сервера. Это нормально, если серверы под вашим контролем. Если один из origin-серверов – сторонний SaaS, попросите у него кастомный домен и CNAME-валидацию, чтобы не тащить ключ к чужому провайдеру.
Практический чек-лист на выходные: выпустите wildcard через DNS-01, установите его на все origin-серверы, включите Full (Strict) на прокси, прогоните все поддомены через ssllabs.com и убедитесь, что нет mixed content. Добавьте мониторинг на дату истечения сертификата с алертом в Telegram за 14 дней. Проверьте, что WAF-правила срабатывают на POST-запросы, а не только на GET. После этого мультидоменная конфигурация будет спать спокойно, а вы – тоже.
