Сайт запускает региональные поддомены — moskva.example.ru, spb.example.ru, ekb.example.ru — и с каждым новым городом повторяется одна и та же рутина: заказать SSL-сертификат, дождаться выпуска, прописать в конфиге веб-сервера, добавить DNS-запись. При пяти городах это терпимо, при пятидесяти — превращается в узкое место, которое тормозит запуск каждого нового региона на дни, а иногда провоцирует ошибки: забытую DNS-запись, просроченный сертификат на одном из поддоменов, разъехавшийся конфиг vhost.
Технически задача решается один раз: wildcard SSL-сертификат на *.example.ru и wildcard DNS-запись, после чего добавление нового города — это одна строка в конфиге веб-сервера, без повторного выпуска сертификата и без правки DNS. Ниже — пошаговая техническая настройка от DNS до автопродления, применимо к серверу с 1С-Битрикс на Nginx или Apache. Материал опирается на нашу практику системы региональных поддоменов на 1С-Битрикс и настройки Nginx/Apache под Битрикс.
Коротко
- Wildcard-сертификат для
*.example.ruможно получить только через DNS-01 challenge — HTTP-01 для него не подходит технически. - Wildcard-запись
* A ...в DNS-зоне избавляет от добавления отдельной A/CNAME-записи на каждый новый город. - Сертификат
*.example.ruне покрывает самexample.ru— апекс-домен нужно добавить в SAN сертификата отдельно. - Let's Encrypt выдаёт сертификаты на 90 дней — без автоматического продления через DNS API это гарантированный инцидент.
- Веб-сервер конфигурируется один раз с одним server-блоком на wildcard-имя — новый город не требует правки vhost.
Задача: один сертификат на все города вместо десятков
Прежде чем переходить к настройке, стоит явно сформулировать, какую проблему решает wildcard-подход. Без него для каждого регионального поддомена нужен собственный сертификат (или все поддомены нужно перечислять как SAN в одном мультидоменном сертификате и перевыпускать его при каждом добавлении города), собственная DNS-запись и, если поддомены обслуживаются разными server-блоками — правка конфигурации веб-сервера.
При десятке городов это управляемо вручную. При масштабировании до полусотни и больше регионов — а именно к этому стремится бизнес с мультирегиональной структурой на 1С-Битрикс — ручной процесс начинает давать сбои: то забыли добавить DNS-запись перед запуском, то сертификат для одного города просрочен, потому что его выпускали отдельно и не включили в общий процесс продления. Wildcard-сертификат и wildcard DNS-запись переносят всю эту инфраструктурную работу с «на каждый город» на «один раз на весь домен».
Wildcard DNS-запись: A и CNAME для *.example.ru
Первый шаг — не сертификат, а DNS: без записи, которая резолвит региональные поддомены на IP-адрес сервера, ни один способ выпуска сертификата не имеет смысла — браузер посетителя просто не найдёт сервер, к которому предъявлять этот сертификат.
Wildcard DNS-запись создаётся в панели управления DNS-зоной домена одной из двух типовых форм:
| Тип записи | Пример | Когда уместна |
|---|---|---|
| Wildcard A-запись | * A 203.0.113.10 | Все поддомены ведут на один и тот же IP-адрес сервера |
| Wildcard CNAME-запись | * CNAME example.ru. | Поддомены должны следовать за основным доменом (например, при смене IP или использовании CDN) |
Символ * в имени записи означает «любое имя первого уровня перед основным доменом», то есть запись * A 203.0.113.10 в зоне example.ru автоматически резолвит moskva.example.ru, spb.example.ru, любой-новый-город.example.ru — без необходимости создавать отдельную запись под каждое имя. Важное ограничение: wildcard-запись покрывает только один уровень вложенности — она резолвит moskva.example.ru, но не test.moskva.example.ru (для второго уровня понадобится собственная wildcard-запись вида *.moskva).
Почему wildcard-сертификат требует именно DNS-01 challenge
Чтобы удостовериться, что вы действительно владеете доменом, прежде чем выпустить сертификат, центр сертификации (Let's Encrypt и аналогичные) проводит challenge — проверку владения. Для обычного (не wildcard) сертификата на конкретное имя чаще всего используется HTTP-01 challenge: ACME-клиент размещает специальный файл по определённому пути на сайте, и центр сертификации обращается по HTTP именно к этому имени, чтобы файл найти.
Для wildcard-сертификата этот механизм принципиально не работает: HTTP-01 подтверждает владение одним конкретным именем, а wildcard-сертификат покрывает потенциально бесконечное множество ещё не существующих имён (любой будущий город). Проверить каждое из них по HTTP физически невозможно — часть из них ещё не существует на момент выпуска сертификата. Поэтому центры сертификации требуют для wildcard DNS-01 challenge: ACME-клиент создаёт TXT-запись определённого вида (_acme-challenge.example.ru) в DNS-зоне домена, а центр сертификации проверяет её через DNS. Успешное создание такой записи доказывает контроль над всей DNS-зоной целиком — а значит, и над любым её поддоменом, включая ещё не созданные.
Выпуск wildcard-сертификата через certbot пошагово
На практике для Let's Encrypt чаще всего используется клиент certbot с плагином под конкретного DNS-провайдера (или универсальный ручной режим, если API провайдера не поддерживается плагином напрямую). Общая последовательность одинакова независимо от конкретного провайдера:
- Установите certbot и DNS-плагин под вашего провайдера. Для популярных DNS-хостингов существуют готовые плагины (
certbot-dns-*), которые умеют создавать TXT-записи через API провайдера автоматически. - Получите API-ключ DNS-провайдера. Плагину нужны права на создание/удаление TXT-записей в зоне — обычно отдельный API-токен с ограниченными правами, а не полный доступ к аккаунту.
- Запустите выпуск сертификата с указанием wildcard-имени и апекс-домена. Команда вида
certbot certonly --dns-provider -d example.ru -d *.example.ru— важно указать оба имени явно, апекс-домен не подставляется автоматически. - Дождитесь прохождения DNS-01 challenge. Плагин создаёт TXT-запись, центр сертификации проверяет её (с учётом пропагации DNS, см. раздел про типичные ловушки), затем плагин удаляет временную запись.
- Проверьте выпущенные файлы сертификата. Полная цепочка (fullchain.pem) и приватный ключ (privkey.pem) появляются в стандартной директории certbot, готовые к подключению в конфиг веб-сервера.
- Настройте автопродление до того, как перейдёте к следующему шагу. Это не «сделаем потом» — без автопродления вся конструкция рассчитана только на первые 90 дней (подробнее — в разделе про автопродление).
--manual с ручным добавлением TXT-записи по инструкции при каждом выпуске — но тогда автоматическое продление без участия человека невозможно, и придётся либо переходить на API-совместимого провайдера, либо строить собственный скрипт-обёртку над API провайдера.
Конфигурация веб-сервера под все поддомены сразу
После получения сертификата второй шаг — настроить веб-сервер так, чтобы он принимал соединения по HTTPS для любого регионального поддомена, используя один и тот же сертификат, и передавал запрос в 1С-Битрикс с сохранением исходного имени хоста (для дальнейшего определения региона на уровне приложения).
В Nginx это типично решается одним server-блоком с wildcard-именем сервера вместо перечисления каждого города отдельно:
| Директива | Значение | Назначение |
|---|---|---|
server_name | *.example.ru example.ru | Один блок обслуживает все поддомены и апекс-домен |
ssl_certificate | путь к fullchain.pem | Полная цепочка сертификата, единая для всех поддоменов |
ssl_certificate_key | путь к privkey.pem | Приватный ключ сертификата |
proxy_set_header Host | $host | Передаёт исходное имя поддомена в приложение Битрикс для определения региона |
Для Apache аналогичная логика реализуется через ServerAlias *.example.ru в связке с VirtualHost, использующим тот же сертификат. Ключевой принцип один и тот же независимо от веб-сервера: конфигурация не должна перечислять города по одному — добавление нового региона должно требовать изменений только на уровне данных 1С-Битрикс (запись о новом городе), а не в конфиге веб-сервера или в сертификате.
Автопродление: cron, systemd timer и DNS API
Сертификаты Let's Encrypt действуют 90 дней — короткий срок выбран намеренно, чтобы вынудить автоматизацию продления, а не ручное разовое действие раз в год, которое легко забыть. Автопродление реализуется одним из двух штатных механизмов планировщика на сервере:
- Cron-задача. Классический вызов
certbot renewпо расписанию (обычно дважды в сутки — certbot сам определяет, нужно ли реально продлевать конкретный сертификат, и ничего не делает, если срок действия ещё далёк от истечения). - Systemd timer. Современная альтернатива cron на системах с systemd — устанавливается пакетом certbot по умолчанию на многих дистрибутивах и не требует отдельной настройки.
Критичное условие для wildcard-сертификатов: продление должно проходить тот же DNS-01 challenge, что и первичный выпуск, а значит без доступа certbot к API DNS-провайдера автопродление технически невозможно — challenge пришлось бы проходить вручную каждые 60–90 дней (продление обычно запускают заранее, не дожидаясь истечения срока). Именно поэтому выбор DNS-провайдера с поддерживаемым certbot-плагином — не второстепенная деталь, а условие, без которого вся схема с wildcard-сертификатом не автоматизируется до конца.
Реализация в 1С-Битрикс: сайты и обработка поддоменов
Wildcard SSL и DNS решают транспортный уровень — «как соединение вообще доходит до сервера по HTTPS». Дальше 1С-Битрикс должен понять, какой регион обслуживать по имени хоста запроса, и это уже уровень модуля «Многосайтовость»: каждый региональный поддомен привязывается к своему SITE_ID (или к одному сайту с определением региона по домену через дополнительную таблицу соответствия), чтобы вывести нужные цены, контакты филиала и локальный контент.
Типичные ловушки: apex-домен, опечатки, propagation delay
Даже при технически верной схеме на практике встречается несколько повторяющихся проблем, специфичных именно для wildcard-конфигурации:
- Забытый apex-домен. Сертификат
*.example.ruне покрываетexample.ruбез поддомена — если на апекс-домене тоже открывается сайт (например, головной или общероссийская версия), его нужно явно добавить в SAN при выпуске отдельной опцией-d example.ru. - Поддомены второго уровня. Wildcard первого уровня не покрывает
test.moskva.example.ru— если такая структура нужна, потребуется отдельная wildcard-запись*.moskva.example.ruи включение её в SAN сертификата. - Задержка пропагации DNS. После добавления или изменения wildcard-записи изменение расходится по кэширующим DNS-серверам провайдеров не мгновенно — процесс может занимать от минут до нескольких часов в зависимости от TTL предыдущей записи. Это разовая задержка при первичной настройке wildcard-записи, а не при каждом новом городе.
- Опечатка в имени поддомена на уровне данных Битрикс. Технически домен резолвится и сертификат его покрывает, но привязка SITE_ID к неверно введённому имени хоста («moskva.example.ru » с пробелом, регистр) приводит к тому, что запрос попадает не на тот сайт или на страницу 404.
- Смешение HTTP и HTTPS редиректов между города́ми. Если редирект с HTTP на HTTPS не учитывает wildcard-имя сервера, часть новых поддоменов может остаться без принудительного перехода на защищённое соединение.
Мониторинг срока действия сертификата
Автопродление снижает риск, но не исключает его полностью: сбой cron-задачи, истёкший API-ключ DNS-провайдера, изменение политики центра сертификации — любая из этих причин может остановить автопродление незаметно, и о проблеме станет известно только когда сертификат уже просрочен и все поддомены одновременно показывают пользователям предупреждение браузера.
| Способ мониторинга | Что даёт |
|---|---|
| Внешний мониторинг срока действия SSL | Независимая от сервера проверка «снаружи», не зависит от исправности cron на самом сервере |
| Уведомления Let's Encrypt на e-mail | Штатное письмо-предупреждение за 20 и 7 дней до истечения непродлённого сертификата |
| Лог certbot renew | Показывает, реально ли отработало последнее плановое продление и с каким результатом |
Безопасность: приватный ключ wildcard-сертификата
У wildcard-сертификата есть оборотная сторона, о которой часто забывают: компрометация одного приватного ключа означает компрометацию TLS для всех поддоменов сразу, а не одного города. Это следствие самой природы wildcard-сертификата — один ключ обслуживает неограниченное число имён.
- Ограничьте доступ к файлу приватного ключа. Права на чтение — только для процесса веб-сервера и учётной записи, от которой запускается certbot; никаких групповых прав «на всякий случай».
- Не копируйте приватный ключ на дополнительные серверы без необходимости. Если нужна балансировка нагрузки между несколькими серверами, продумайте механизм безопасной синхронизации сертификата, а не ручное копирование по SFTP «между делом».
- Ограничьте права API-ключа DNS-провайдера. Токен, который использует certbot для DNS-01 challenge, должен иметь права только на управление записями нужной зоны, а не полный доступ к аккаунту регистратора.
- Ведите план на случай компрометации. Отзыв (revoke) и срочный перевыпуск сертификата — процедура, которую стоит знать заранее, а не изучать в момент инцидента.
Частые ошибки настройки
- Выпускают сертификат только на
*.example.ru, забывая добавить апекс-доменexample.ruотдельным SAN — головной сайт остаётся без покрытия. - Настраивают выпуск сертификата вручную через
--manualбез DNS-плагина и не продумывают, как это будет продлеваться каждые 60–90 дней. - Забывают дать API-ключу DNS-провайдера права на редактирование записей — плагин не может создать TXT-запись, и выпуск/продление падает с ошибкой.
- Не настраивают независимый от сервера мониторинг срока действия сертификата, полагаясь только на факт когда-то настроенной cron-задачи.
- Добавляют новый город в данные 1С-Битрикс, но забывают, что при отсутствии wildcard DNS-записи (если выбрана схема с точечными записями) нужна ещё и отдельная A/CNAME-запись — сайт не открывается до её добавления.
- Хранят приватный ключ wildcard-сертификата с избыточными правами доступа или копируют его без нужды на серверы, где он не используется.
- Путают TTL старой DNS-записи с моментальным вступлением изменений в силу и объявляют город «запущенным», не дождавшись реальной пропагации.
- Не тестируют HTTPS-редирект на реальном новом поддомене после его первого запуска — полагаются, что раз работает на существующих городах, сработает и на новом автоматически.
Чек-лист внедрения
- Wildcard DNS-запись настроена.
* Aили* CNAMEрезолвит любой будущий поддомен без ручных правок. - Сертификат выпущен с апекс-доменом в SAN. Покрыты и
*.example.ru, иexample.ru. - DNS-01 challenge проходит через API-плагин, а не вручную. Автопродление технически возможно без участия человека.
- Веб-сервер настроен одним wildcard server-блоком. Новый город не требует правки vhost/конфига.
- Cron/systemd timer автопродления работает и проверен. Плановый прогон
certbot renewотработал успешно хотя бы раз. - Настроен независимый мониторинг срока действия. Уведомление приходит до истечения, а не после.
- Приватный ключ защищён. Права доступа ограничены, план на случай компрометации существует.
- Первый новый город протестирован end-to-end. DNS, сертификат, редирект HTTPS и привязка SITE_ID в Битрикс проверены на реальном поддомене, а не только «в теории».
Вывод
Wildcard SSL и DNS переводят добавление регионального поддомена из инфраструктурной задачи «на каждый город заново» в задачу «один раз настроили — дальше только данные». Ключевые технические решения — wildcard-запись в DNS, выпуск сертификата через DNS-01 challenge с API-доступом к DNS-провайдеру и один server-блок веб-сервера на все поддомена — принимаются один раз, но требуют аккуратности: забытый апекс-домен, невозможность автопродления или незащищённый приватный ключ обходятся дороже, чем время, потраченное на правильную настройку с первого раза.
