SSL-сертификат для поддомена: что проверить до выпуска

Поддомен должен существовать не только в плане

SSL-сертификат для поддомена начинают не с выпуска, а с проверки того, что поддомен уже имеет понятную роль. `app.example.com`, `api.example.com`, `panel.example.com` и `blog.example.com` могут жить на разных серверах, за CDN или на одном Nginx. Ошибка появляется, когда сертификат выпускают раньше, чем решено, куда именно будет указывать имя и какой сервер его обслуживает.

Первый слой — DNS. Нужно понять, будет ли поддомен A/AAAA-записью, CNAME на другой хост или записью за CDN. Если поддомен указывает не туда, HTTP-валидация не пройдёт или сертификат будет установлен не на том сервере. Если используется DNS-валидация, важно заранее знать, где редактируется зона и кто имеет доступ к TXT-записям.

Общая логика выбора сертификата для основного домена разобрана в материале SSL для домена. Для поддомена добавляется вопрос назначения: зачем он нужен и кто будет отвечать за его инфраструктуру.

HTTP challenge или DNS challenge

Для поддомена часто используют HTTP challenge: центр сертификации обращается к `http://sub.example.com/.well-known/acme-challenge/...` и проверяет файл. Такой способ прост, если поддомен уже ведёт на сервер, где работает веб-сервер. Но он ломается, если порт 80 закрыт, CDN перехватывает запрос, редиректы настроены странно или поддомен ещё не привязан к нужному vhost.

DNS challenge удобен для wildcard и случаев, когда HTTP недоступен. Он требует добавить TXT-запись в DNS-зону. Здесь главный риск — редактировать не тот DNS-провайдер или забыть о TTL. Если зона делегирована в Cloudflare, TXT в панели хостинга не поможет. Если CAA ограничивает выпуск сертификатов, нужно убедиться, что выбранный центр сертификации разрешён.

Перед выпуском полезно проверить материал поддомены: когда они реально нужны. Иногда отдельный поддомен создают ради порядка, но потом забывают, что его нужно сопровождать: DNS, SSL, vhost, мониторинг, редиректы и доступы.

SAN, wildcard и точное имя

Сертификат должен покрывать именно то имя, которое откроет пользователь или приложение. Если нужен `api.example.com`, сертификат для `example.com` не подойдёт. Wildcard `*.example.com` покроет один уровень поддоменов, но не закроет `a.b.example.com`. SAN-сертификат может включить несколько точных имён, но их нужно перечислить заранее.

Для поддомена важно не забыть `www`, если он используется, и не добавлять лишние имена без причины. Чем больше имён в сертификате, тем внимательнее нужно следить за продлением и инфраструктурой. Если разные поддомены обслуживают разные команды, один общий сертификат может стать неудобной точкой зависимости.

Техническая часть TLS и имени связана со статьёй что такое TLS: где заканчивается сайт и начинается транспорт. Сертификат для поддомена должен не просто существовать, а фактически отдаваться нужным virtual host через SNI.

Перед выпуском проверьте сервер

Даже если сертификат успешно выпущен, сайт может не заработать. На сервере должен быть настроен virtual host для поддомена, открыт 80 или 443 в зависимости от validation method, корректно прописан `server_name`, а после установки сертификата веб-сервер должен быть перезагружен. Если поддомен ведёт за CDN, нужно понимать, где завершается TLS: на edge, на origin или в обоих местах.

Практический чек: проверить DNS-ответ, доступность порта 80, будущий редирект на HTTPS, наличие vhost, CAA-записи, выбранный способ валидации и путь установки сертификата. После выпуска проверить браузер, `openssl s_client -servername`, цепочку и срок. Если поддомен нужен для API, отдельно проверить клиентское приложение, а не только главную страницу.

CAA-записи стоит проверить до запуска автоматизации. Материал CAA-записи и выпуск SSL-сертификатов помогает избежать ситуации, когда всё готово, но центр сертификации не имеет права выпустить сертификат.

Кейс: api-поддомен не прошёл проверку

Команда решила выпустить сертификат для `api.example.com`. DNS уже указывал на новый сервер, но HTTP challenge не проходил. Владелец несколько раз запускал выпуск заново и подозревал проблему у центра сертификации. Проверка показала, что Nginx принимал запрос на 80 порт, но для `api.example.com` не было отдельного server block. Запрос попадал в default-конфигурацию, где путь `.well-known` не обслуживался.

После добавления vhost и проверки challenge-файла выпуск прошёл сразу. Сертификат установили, затем отдельно проверили SNI и ответ API по HTTPS. Вывод: для поддомена сертификат выпускается не в вакууме. Имя, DNS, validation path и web server должны быть согласованы до запуска Certbot или другого ACME-клиента.

Как проверить сертификат поддомена до выпуска

Список имён

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

DNS и выпуск

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

Устройства

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

Проверка

VPN и HTTPS используют разные роли. VPN соединение проверяют после загрузки сертификата процессом. Проверить VPN соединение нужно на каждом важном типе клиента. Надежный VPN хранит журнал выпуска и точечный план возврата.

В этой схеме отдельно проверяют vpn сервер, потому что от него зависит следующий шаг настройки.

FAQ по SSL для поддомена

Нужно ли создавать поддомен до выпуска сертификата?

Да. ACME-проверка должна увидеть правильный DNS и нужный сервер или DNS challenge. Если поддомен указывает на старый IP, выпуск пойдёт не туда.

Можно ли одним сертификатом закрыть сайт и API?

Можно, если оба имени внесены в SAN или покрываются wildcard. Но для API, кабинета и служебных зон часто удобнее осознанно разделять имена.

Когда CAA мешает выпуску сертификата?

Когда CAA разрешает выпуск только определённым центрам сертификации, а ваш ACME-клиент обращается к другому CA. Тогда DNS выглядит нормальным, но сертификат не выпускается.

Чем wildcard отличается от сертификата на поддомен?

Wildcard покрывает группу имён вида `*.example.com`, а отдельный сертификат закрывает конкретный поддомен. Выбор зависит от контроля, частоты изменений и рисков.

Можно ли выпустить сертификат для VPN на поддомен, где нет веб-сайта?

Если VPN-протокол использует TLS, публичный сертификат можно получить подходящим способом подтверждения владения именем. Например, DNS-проверка не требует размещать обычный сайт на этом узле. При этом клиент должен проверять нужное имя, а закрытый ключ следует хранить только там, где он необходим.

Нужен ли отдельный сертификат для ВПН на каждом поддомене?

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