Что такое проверка контроля домена (DCV)? Полное руководство по методам проверки SSL-сертификатов

Когда вы заказываете SSL/TLS-сертификат, Удостоверяющий центр не просто выдаст его вам. Ему необходимо доказательство того, что вы действительно контролируете домен, который защищаете. Именно здесь на сцену выходит проверка контроля над доменом (Domain Control Validation, DCV). Это процесс верификации, который подтверждает право владения доменом перед выпуском любого сертификата.

Это не просто бюрократическая формальность. DCV предотвращает получение злоумышленниками действительных сертификатов для доменов, которыми они не владеют, что могло бы полностью подорвать модель доверия, обеспечивающую безопасность HTTPS. CA/Browser Forum, отраслевой орган, устанавливающий базовые требования к выпуску сертификатов, требует применения определённых методов DCV, которым должны следовать все Удостоверяющие центры.

В этом руководстве мы разберём, что такое DCV, рассмотрим различные доступные методы проверки и поможем вам выбрать подходящий подход для вашей инфраструктуры.

---

Содержание

1. Что такое проверка контроля над доменом (DCV)?
2. Методы проверки домена на основе электронной почты
3. Методы DCV на основе DNS
4. Методы проверки на основе файлов HTTP/HTTPS
5. Особые сценарии проверки
6. Выбор подходящего метода DCV для ваших нужд
7. Частые проблемы с DCV и их быстрое решение

---

---

Что такое DCV (проверка контроля над доменом)?

Проверка контроля над доменом (DCV) — это процесс, который Удостоверяющие центры используют для подтверждения права владения доменом перед выпуском SSL/TLS-сертификата. Она подтверждает контроль, требуя от заявителя ответить по электронной почте, загрузить файл на домен или настроить DNS-записи, чтобы доказать свои полномочия над доменом.

Процесс работает следующим образом: CA генерирует уникальный вызов (обычно случайную буквенно-цифровую строку), и вы демонстрируете контроль, отвечая через инфраструктуру своего домена. Это может быть через DNS-записи, ваш веб-сервер или административные адреса электронной почты. После проверки CA понимает, что выпускает сертификат законному владельцу домена, а не тому, кто пытается выдать себя за ваш сайт.

Отраслевые стандарты и соответствие требованиям

Базовые требования CA/Browser Forum точно определяют, как должна выполняться DCV. Это не рекомендации, а строгие правила, которым CA должны следовать, иначе рискуют потерять доверенный статус в браузерах.

Текущие стандарты включают:

• Проверка должна использовать один из одобренных методов DCV (рассмотрены ниже)
• Подтверждение выпуска с нескольких точек зрения (Multi-Perspective Issuance Corroboration, MPIC) требует проверки с нескольких сетевых точек, чтобы предотвратить локализованные атаки
• Проверка может использоваться повторно в течение 397 дней для сертификатов Organization Validated (OV) и Extended Validation (EV)
• Сертификаты Domain Validated (DV) не могут повторно использовать проверку — вам нужно проверять домен при каждом продлении

Вот что важно: эти требования становятся строже. Отрасль сокращает максимальные сроки действия сертификатов и периоды проверки.

CA/Browser Forum установил чёткий график сроков действия сертификатов: теперь они ограничены 200 днями с 15 марта 2026 года, с дальнейшим сокращением до 100 дней с 15 марта 2027 года и до 47 дней начиная с 15 марта 2029 года.

Это ужесточение также затрагивает циклы проверки, делая частую повторную проверку и автоматизацию SSL-сертификатов всё более необходимыми.

---

Методы проверки домена на основе электронной почты

1. Проверка через сконструированный адрес электронной почты

Проверка по электронной почте — самый распространённый метод DCV, поскольку он прост и не требует технических изменений в вашей инфраструктуре. CA отправляет электронное письмо со ссылкой или кодом проверки на определённые адреса вашего домена.

CA попробует следующие общие адреса электронной почты:

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

Вам не нужно настраивать их все — достаточно одного рабочего адреса из списка. CA проверяет MX-записи вашего домена, чтобы убедиться, что письмо может быть доставлено, а затем отправляет запрос на проверку.

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

Этот метод отлично работает, если:

• У вас настроена почтовая инфраструктура для вашего домена
• Вы заказываете сертификаты время от времени, а не в больших масштабах
• Вы хотите самый простой процесс проверки без изменений DNS или веб-сервера

Недостаток? Вы не можете легко автоматизировать этот процесс, и если ваша почта не работает или адреса не отслеживаются, проверка не пройдёт.

2. Электронная почта через контактный адрес в DNS TXT

Этот вариант сочетает электронную почту с DNS. Вместо использования общих адресов вы публикуете конкретный адрес электронной почты в DNS TXT-записи по адресу _validation-contactemail.yourdomain.com. CA считывает эту запись и отправляет проверку на этот адрес.

Почему стоит использовать этот подход?

• Повторное использование: после настройки запись остаётся действительной в течение всего периода проверки
• Централизованный контроль: вы точно решаете, какая почта получает запросы на проверку
• Удобство для команды: направьте её на список рассылки, а не в личный почтовый ящик кого-то одного

Вот практическая настройка:

_validation-contactemail.yourdomain.com. IN TXT "mailto:[email protected]"

Просто создайте эту DNS TXT-запись с предпочитаемым контактным адресом электронной почты, и CA будет использовать её автоматически. Это особенно полезно для организаций, управляющих несколькими сертификатами. Вы можете стандартизировать проверку для всех доменов через один отслеживаемый почтовый ящик.

---

Методы DCV на основе DNS

1. Проверка через DNS TXT-запись

Проверка через DNS TXT-запись популярна благодаря своей гибкости и потенциалу для автоматизации. Когда вы заказываете сертификат, CA предоставляет конкретное имя хоста и токен проверки, которые вы добавляете как TXT-запись в DNS вашего домена.

Базовый процесс:

1. CA предоставляет имя хоста (обычно _dvsauth.yourdomain.com) и токен во время заказа сертификата
2. Вы создаёте TXT-запись с этим токеном в качестве значения
3. CA запрашивает ваш DNS, чтобы подтвердить существование записи
4. После проверки они выпускают сертификат

Запись обычно выглядит так:

_dvsauth.yourdomain.com. IN TXT "ab1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q"

Проверка через DNS TXT идеально подходит для:

• Автоматизации — DNS API делают это скриптуемым через ACME-клиенты или пользовательские инструменты
• Сред без веб-серверов — вам нужен только доступ к DNS
• Wildcard-сертификатов — мы рассмотрим это требование в разделе особых сценариев

На что стоит обратить внимание: время распространения DNS. Если у ваших серверов имён высокие значения TTL или медленное распространение, проверка может занять больше времени. Большинство CA будут повторять попытки в течение 24 часов, но лучше установить более низкие значения TTL перед добавлением записей проверки.

2. Метод через DNS CNAME-запись

Проверка через CNAME использует другой тип записи, но достигает той же цели. Вместо хранения токена проверки напрямую вы создаёте CNAME, который указывает на цель проверки, контролируемую CA.

Пример конфигурации:

_dnsauth.yourdomain.com. IN CNAME random-token.dcv.digicert.com.

Ключевое отличие: CNAME указывает на запись, которую контролирует CA, что означает, что они могут обновлять цель проверки без изменения DNS с вашей стороны. Некоторые CA также разрешают это для предварительной проверки домена — вы настраиваете CNAME один раз, и они могут проверять домен каждый раз, когда вы заказываете сертификаты.

Проверка через CNAME хорошо работает, когда:

• Ваш DNS-провайдер делает управление CNAME проще, чем TXT-записями
• Вы хотите возможность предварительной проверки домена для сертификатов OV/EV
• Вы работаете с CA, которые поддерживают процессы проверки на основе CNAME

Не все CA предлагают проверку через CNAME, поэтому уточните это у своего провайдера. Но там, где она доступна, это надёжный вариант для команд, предпочитающих этот тип DNS-записи.

---

---

Методы проверки на основе файлов HTTP/HTTPS

1. Практическая демонстрация через HTTP

Проверка на основе файлов требует размещения определённого файла на вашем веб-сервере по указанному пути. Затем CA получает доступ к этому файлу через HTTP или HTTPS, чтобы подтвердить, что вы контролируете сервер, на котором размещён домен.

Стандартный путь: http://yourdomain.com/.well-known/pki-validation/fileauth.txt

CA предоставляет как точное имя файла, так и его содержимое. Вы создаёте этот файл на своём сервере, обеспечиваете доступ к нему, а CA проверяет его, получая доступ к файлу.

Важные моменты реализации:

• Файл должен быть доступен через порт 80 (HTTP) или порт 443 (HTTPS)
• Каталог .well-known — это стандартное расположение, определённое в RFC 8615
• Это требуется для проверки IP-адреса. Если вы получаете сертификат для IPv4 или IPv6-адреса, HTTP-проверка обычно является единственным вариантом

Проверка на основе файлов проста, если у вас есть прямой доступ к веб-серверу. Она менее удобна, если вы используете хостинг-услуги с ограниченным доступом к файловой системе или CDN, которые могут кэшировать запросы проверки или мешать им.

Советы по устранению неполадок:

• Убедитесь, что перенаправления не мешают процессу. CA должен получить доступ к точному URL проверки
• Проверьте, разрешают ли брандмауэры доступ по HTTP/HTTPS
• Отключите кэширование для каталога проверки
• Убедитесь, что права доступа к файлу разрешают публичное чтение

2. Интеграция с ACME Challenge

Протокол ACME (Automated Certificate Management Environment) использует вызовы HTTP-01 и DNS-01 для автоматизированной DCV. Если вы используете Let’s Encrypt или другой совместимый с ACME CA, ваш ACME-клиент автоматически обрабатывает весь процесс проверки.

Вызов HTTP-01: размещает файл проверки по адресу /.well-known/acme-challenge/ (аналогично стандартной HTTP-проверке)

Вызов DNS-01: создаёт TXT-запись по адресу _acme-challenge.yourdomain.com

Ваш клиент (например, Certbot, acme.sh или встроенные инструменты в таких платформах, как cPanel) обрабатывает проверку и продление сертификата без ручного вмешательства. ACME стал стандартом для автоматизированного управления сертификатами, особенно для организаций, управляющих большими пулами сертификатов.

---

Особые сценарии проверки

1. Проверка мультидоменных сертификатов и SAN-сертификатов

Если вы заказываете мультидоменный сертификат (также называемый SAN- или UCC-сертификатом), вы должны проверить каждый домен отдельно. Одна проверка DCV не покрывает все домены в сертификате.

Пример: Сертификат для example.com, www.example.com и shop.example.com требует три отдельные проверки, даже несмотря на то, что это связанные домены.

Хорошая новость? Вы можете сочетать методы проверки. Используйте проверку по электронной почте для одного домена и проверку через DNS для другого, если это соответствует вашей инфраструктуре. Платформа CA будет отслеживать статус проверки для каждого домена и выпустит сертификат только после того, как все домены будут проверены.

2. Проверка wildcard-доменов

Wildcard-сертификаты (покрывающие *.example.com) требуют методов проверки на основе DNS. Большинство CA не принимают проверку по электронной почте или через HTTP для wildcard-сертификатов из соображений безопасности.

Почему для wildcard-сертификатов нужна проверка через DNS?

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

Если вам нужен wildcard-сертификат, планируйте использовать проверку через DNS TXT или CNAME. Обычно это единственные доступные варианты.

3. Особенности проверки субдоменов

Вы можете проверять на уровне субдомена или родительского домена, в зависимости от метода проверки. Для HTTP-проверки файл должен быть доступен по конкретному субдомену, который вы проверяете. Для DNS-проверки вы создаёте записи на соответствующем уровне субдомена.

Одно важное отличие: проверка родительского домена (example.com) не проверяет автоматически субдомены (blog.example.com) для большинства методов проверки. Каждый субдомен нуждается в собственной проверке, если только вы не используете wildcard-сертификат.

---

Выбор подходящего метода DCV для ваших нужд

Подберите метод, соответствующий вашей инфраструктуре:

Сравнение всех методов DCV в одном месте

Метод проверки	Время выполнения	Возможность автоматизации	Технический навык	Поддержка wildcard	Возможность повторного использования (OV/EV)	Лучше всего подходит для
Email (общий)	5-30 минут	❌ Низкая	⭐ Минимальный	✅ Да	❌ Нет	Единичные сертификаты, небольшие развёртывания
Email (DNS TXT)	15-60 минут	❌ Низкая	⭐⭐ Низкий-средний	✅ Да	✅ Да (397 дней)	Команды с несколькими сертификатами, налаженная почта
DNS TXT-запись	10-60 минут	✅ Высокая	⭐⭐⭐ Средний	✅ Да	✅ Да (397 дней)	Автоматизация, wildcard, крупные развёртывания
DNS CNAME	15-60 минут	✅ Высокая	⭐⭐⭐ Средний	✅ Да	✅ Да (397 дней)	Предварительная проверка домена, управляемые CA токены
HTTP-файл	5-20 минут	⚠️ Средняя	⭐⭐ Низкий-средний	❌ Нет	❌ Нет	Прямой доступ к серверу, IP-адреса
ACME (HTTP-01)	2-10 минут	✅ Очень высокая	⭐⭐⭐⭐ Средний-высокий	❌ Нет	Н/П (автопродление)	Полная автоматизация, Let’s Encrypt
ACME (DNS-01)	2-10 минут	✅ Очень высокая	⭐⭐⭐⭐ Средний-высокий	✅ Да	Н/П (автопродление)	Полная автоматизация с wildcard

Выбор метода по сценарию

Используйте проверку по электронной почте, если:

• У вас простые, единичные заказы сертификатов
• Общие административные адреса электронной почты отслеживаются
• Вам не нужна автоматизация

Используйте проверку через DNS TXT/CNAME, если:

• Вам нужны wildcard-сертификаты
• Вы управляете несколькими сертификатами
• У вас нет доступа к веб-серверу
• Вам нужны возможности автоматизации

Используйте проверку через HTTP-файл, если:

• У вас есть прямой доступ к веб-серверу
• Вы проверяете IP-адреса
• Изменения DNS затруднены в вашей организации

---

Частые проблемы с DCV и их быстрое решение

Сбои проверки случаются. Вот наиболее частые ошибки, с которыми вы столкнётесь, и способы их быстрого устранения.

HTTP-проверка файла: «404 Not Found»

Ошибка: «The system queried for a temporary file at http://example.com/.well-known/pki-validation/[filename].txt, but the web server responded with the following error: 404 (Not Found).»

Быстрые решения:

• Вручную создайте структуру каталогов: /public_html/.well-known/pki-validation/
• Установите права доступа: 755 для каталогов, 644 для файлов
• Проверьте правила .htaccess, которые могут блокировать путь /.well-known/
• Если домен был только что добавлен, подождите 24-48 часов для распространения
• Проверьте доступность: curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

Частая причина: путь к файлу проверки не существует или недоступен публично.

HTTP-проверка: «Forbids DCV HTTP Redirections»

Ошибка: «cPanel (powered by Sectigo) forbids DCV HTTP redirections.»

Быстрые решения:

• Временно отключите перенаправления на HTTPS во время проверки
• Исключите путь /.well-known/* из правил перенаправления
• Проверьте .htaccess, правила страниц Cloudflare или конфигурацию сервера на предмет перенаправлений
• Если используется CDN, временно отключите его или добавьте исключение

Частая причина: ваш сайт перенаправляет HTTP на HTTPS или на другой домен, блокируя попытку проверки со стороны CA.

DNS-проверка: «No TXT Record That Matches»

Ошибка: «The DNS query to ‘_dvsauth.example.com’ for the DCV challenge returned no ‘TXT’ record that matches the value ‘[expected-value]’.»

Быстрые решения:

• Подождите 1-24 часа для распространения DNS (зависит от TTL)
• Проверьте точное имя хоста и значение: dig _dvsauth.example.com TXT +short
• Проверьте, нет ли ошибок копирования/вставки в токене проверки
• Если используется делегированный DNS (NS-записи), добавьте TXT-запись у правильного провайдера
• Снизьте TTL до 300 секунд (5 минут) перед добавлением записей проверки

Частая причина: DNS ещё не распространился, или в записи есть опечатки.

DNS-проверка: записи CAA блокируют выпуск

Ошибка: «Certificate authority encountered a multiple perspective CAA check error.»

Быстрые решения:

• Проверьте существующие записи CAA: dig example.com CAA
• Добавьте своего CA в список разрешённых эмитентов: example.com. CAA 0 issue «digicert.com»
• Убедитесь, что записи CAA разрешаются глобально, используя инструмент ping.pe
• Если записей CAA не существует, вам не нужно ничего добавлять (отсутствие записей разрешает всех CA)

Частая причина: записи CAA ограничивают, какие CA могут выпускать сертификаты для вашего домена.

Проверка по электронной почте: письмо не получено

Быстрые решения:

• Сначала проверьте папки со спамом/нежелательной почтой
• Убедитесь, что эти адреса существуют и получают почту: admin@, administrator@, webmaster@, hostmaster@, postmaster@
• Проверьте MX-записи: dig example.com MX
• Добавьте домены отправки CA в белый список вашего спам-фильтра
• Запросите повторную отправку письма из панели управления CA

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

Особенности платформы: сбои AutoSSL в cPanel

Ошибка: «Local HTTP DCV error: An internal error occurred.»

Быстрые решения:

• Проверьте логи WHM > Manage AutoSSL для получения подробностей
• Подождите 30 минут и повторите попытку (часто решается автоматически)
• Переключитесь между провайдерами Sectigo и Let’s Encrypt
• Очистите очередь AutoSSL: WHM > Manage AutoSSL > Clear pending queue

Быстрые диагностические команды

Прежде чем обращаться в поддержку, выполните эти проверки:

# Verify DNS propagation
dig yourdomain.com +short
dig _dvsauth.yourdomain.com TXT +short

# Test HTTP file accessibility
curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

# Check CAA and MX records
dig yourdomain.com CAA
dig yourdomain.com MX

---

Упростите управление SSL-сертификатами с SSL Dragon

Правильная проверка контроля над доменом крайне важна для бесперебойного развёртывания сертификата. SSL Dragon предлагает сертификаты от доверенных Удостоверяющих центров со всеми необходимыми методами проверки, будь то электронная почта, DNS или проверка на основе HTTP.

Наша команда поможет вам разобраться с требованиями DCV для сертификатов Domain Validated, Organization Validated и Extended Validation. Мы подскажем метод проверки, соответствующий вашей инфраструктуре, и ответим на вопросы, если возникнут проблемы с проверкой.

Хватит бороться с проверкой сертификатов. Просмотрите наши варианты SSL-сертификатов!