Стандартные ошибки: Метод DCV с практической демонстрацией HTTP

Чтобы выполнить проверку администрирования доменов используются несколько различных способов, один из них - метод DCV с практической демонстрацией HTTP. Процесс DCV с использованием практической демонстрации HTTP разработан в целях предотвращения использования доменов неавторизованными лицам домена,  для проверки и получения сертификата для домена, который они не контролируют.

Вам требуется разместить специальный код, предоставленный сертификационным центром ( произвольное значение) и разместить его на вашем веб-сайте в текстовом файле fileauth.txt   по определенному URL-адресу http://[your-domain]/.well-known/pki-validation/fileauth.txt.

URL-адрес выполняет две функции:

• Он содержит FQDN (полное доменное имя) домена, который сертификационный центр должен проверить перед тем как  выпустить сертификат на указанный домен.
• Он информирует нас о том, где ЦС может найти файл fileauth.txt, в котором находится код.

Ниже рассматриваются некоторые стандартные проблемы, с которыми мы столкнулись при поиске и устранении причин ошибок при проверках с использованием практической демонстрации HTTP.

1 Не изменяйте предоставленный URL-адрес

Если вы каким-либо образом изменили URL-адрес (изменили FQDN, воспользовались вместо строчной буквы прописной, забыли добавить точку и т. д.), мы не сможем найти файл fileauth.txt, содержащий код. Например, если мы указываем вам следующий URL-адрес: [http://your-domain]/.well-known/pki-validation/fileauth.txt, не добавляйте www к нему ([http://www.your-domain]/.well-known/pki-validation/fileauth.txt) и не заменяйте на прописные какие-либо буквы, которые не являются прописными в исходном URL-адресе ([http://your-domain]/.well-known/PKI-validation/fileauth.txt).

2.Не помещайте файл fileauth.txt в другой домен или субдомен

Для завершения процедуры проверки контроля над доменом (DCV) для[your-domain], поместите файл fileauth.txt именно в тот домен, который вы хотите проверить; это домен, для которого мы сгенерировали URL-адрес. Мы не будем просматривать другие домены или субдомены для поиска нашего случайным образом сгенерированного токена. Мы будем просматривать только домен, который вы хотите проверить (например, домен, указанный в вашем заказе сертификата).

Например, при необходимости проверки[your-domain] мы генерируем URL-адрес для этого домена —[http://yourdomain]/.well-known/pki-validation/fileauth.txt. Не размещайте файл fileauth.txt file на[sub.your-domain] и не изменяйте URL и не размещайте его на[your-other-domain] — это не будет работать. Мы не сможем найти файл fileauth.txt на этих доменах. Мы ищем его на[your-domain], домене из вашего заказа на сертификат или на домене, который вы представили для предварительной проверки.

[your-domain] и www.[your-domain]

Если вы хотите, чтобы мы проверили достоверность www.[your-domain] и[your-domain], разместите файл fileauth.txt file на[your-domain]. При этом будут проверяться[your-domain], и www. [your-domain]. Мы не будем искать на www.[your-domain] файл fileauth.txt.

Бесплатный SAN  базового домена Если вы получили бесплатное доменное SAN в вашем сертификате SSL, вы должны поместить файл fileauth.txt в базовый домен. Мы должны проверить домен, указанный в заказе сертификата SSL/TLS.

3. Не включайте никакой дополнительный контент в файл fileauth.txt

При создании файла fileauth.txt скопируйте значение сгенерированного кода, предоставленное сертификационным центром, и вставьте его в файл. Не добавляйте слово "токен" или какой-либо другой текст. Поскольку мы осуществляем чтение только первых 2 кБ файла fileauth.txt, дополнительный текст будет мешать выполнению нами подтверждения управления вами доменом.

4. Не помещайте файл fileauth.txt на страницу с множественными переадресациями

При использовании метода практической демонстрации HTTP для проверки домена файл fileauth.txt можно поместить на страницу, на которой имеется не более одной переадресации.

При наличии одной переадресации мы все еще способны обнаружить файл fileauth.txt и подтвердить, что вы управляете доменом. Например, вам требуется сертификат для http://example.com, но страница выполняет переадресацию на https://www.example.com. Это нормально. Поместите файл fileauth.txt на страницу http://example.com. Мы сможем выполнить одну переадресацию и подтвердить ваше управление доменом http://example.com.

Но если вы разместите файл fileauth.txt на странице с множественными переадресациями, мы не сможем найти его. Множественные переадресации не позволяют нам определить местонахождение файла fileauth.txt и подтвердить, что вы управляете доменом. Например, вам требуется сертификат для http://multiple-redirect.com, но страница выполняет переадресацию на https://www.multiple-redirect.com, а затем переадресацию обратно на https://www.single-redirect.com. В данном случае вы должны просто оставить файл fileauth.txt на странице http://multiple-redirect.com. При этом вам необходимо запретить вторую переадресацию (https://www.single-redirect.com) на достаточно продолжительное время, чтобы мы могли найти файл fileauth.txt и подтвердить ваше управление доменом http://multiple-redirect.com.