Виды проверок

Последнее обновление: | Вся документация

Внимание! Английская версия сайта была обновлена, перевод неактуален () Просмотреть на английском

Когда вы запрашиваете новый сертификат у Let’s Encrypt, наши серверы проверяют права на доменные имена в сертификате, используя “испытания” (или “проверки”), согласно стандарту ACME. Проверки выполняются с помощью ACME-клиента и не требуют дополнительной настройки, но для сложных конфигураций будет полезным узнать о проверках чуть больше. Если нет уверенности, какую именно проверку применять - используйте настройки по-умолчанию для вашего ACME-клиента, или проверку HTTP-01.

Проверка HTTP-01

Этот тип проверки используется чаще всего. Let’s Encrypt выдаёт ACME-клиенту токен, а ACME-клиент записывает этот токен в файл на web-сервере по пути http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>. В этом файле содержится сам токен, плюс отпечаток ключа вашего аккаунта. Как только ACME-клиент сообщит Let’s Encrypt, что файл готов, Let’s Encrypt будет пытаться получить этот файл по URL (возможно, несколько раз, с различных адресов). Если полученный ответ будет верным, проверка считается успешной, и сертификат для выбранного домена готов к использованию. Если проверка прошла неудачно, требуется повторить попытку с новым сертификатом.

Реализация проверки HTTP-01 разрешает редиректы запросов, общим числом не более 10. Редиректы принимаются только на адреса, начинающиеся с “http:” или “https:”, и только на порты 80 или 443. Редиректы на IP-адреса не принимаются. Если редирект выполнялся на URL c HTTPS, то сертификат не считается подтверждённым (т.к. проверка для новых сертификатов, может обнаружить самоподписанные или просроченные сертификаты).

Проверка HTTP-01 выполняется только с использованием порта 80. Произвольный порт для проверки снижает надёжность, и потому запрещён стандартом ACME.

Плюсы:

Минусы:

Проверка DNS-01

Эта проверка требует подтверждения прав на домен с помощью специальной TXT-записи для доменного имени. Это сложнее в настройке, чем для проверки HTTP-01, но покрывает сценарии использования, недоступные для проверки HTTP-01. Кроме того, проверка DNS-01 разрешает выпускать сертификаты с подстановкой (wildcard-сертификаты). После того, как Let’s Encrypt передаёт ACME-клиенту токен, клиент создаёт содержимое TXT-записи на основе токена и ключа аккаунта, и записывает её в _acme-challenge.<YOUR_DOMAIN>. Далее, Let’s Encrypt запрашивает TXT-запись в DNS-зоне домена. Если значения совпадают - сертификат готов к использованию!

Крайне важно автоматизировать процессы выпуска и отзыва сертификатов, поэтому проверку DNS-01 имеет смысл использовать, когда DNS-провайдер предоставляет API для автоматических обновлений. Наше сообщество поддерживает список таких DNS-провайдеров. DNS-провайдер может быть либо регистратором доменов (компанией, у которой вы купили доменное имя), либо сторонней организацией. Если вы захотите сменить DNS-провайдера, нужно будет сделать незначительные изменения у регистратора доменов. Ожидать окончания срока действия сертификатов при этом не требуется.

Обратите внимание, что размещение полноправной учётной записи для DNS API на web-сервере увеличивает возможный ущерб при взломе. Лучше использовать учётную запись с ограниченными возможностями, или выполнять проверку DNS-01 на отдельном сервере, с последующим копированием сертификатов на web-сервер.

Let’s Encrypt придерживается стандартов DNS для поиска TXT-записи при проверке DNS-01, поэтому можно задействовать записи CNAME или NS для делегирования права ответа за другие DNS-зоны. Например настроив субдомен _acme-challenge для специального сервера валидации. Или, если DNS-провайдер медленно обновляется, и вы хотите использовать более производительный сервер.

Для большинства DNS-провайдеров характерен “период обновления данных”, показывающий, сколько времени пройдёт с момента изменения DNS-записи до обновления всех DNS-серверов провайдера. Этот период сложно оценить, особенно когда DNS-провайдеры применяют anycast. В этом случае, в зависимости от геолокации, вы и Let’s Encrypt будете взаимодействовать с разными серверами, и получать различные результаты. Продуманные DNS API содержат методы автоматического уведомления о полном обновлении записей на всех серверах провайдера. Если DNS-провайдер такой информации не даёт, придётся настроить ACME-клиент на длительное (не менее часа) ожидание перед запуском валидации.

Для одного и того же доменного имени допускается несколько TXT-записей. Например, когда требуется одновременно выполнить проверку и для обычного сертификата, и для wildcard-сертификата. Удаляйте неактуальные TXT-записи, т.к. из-за большого размера ответа сервера при проверке
Let’s Encrypt признает проверку неудачной.

Плюсы:

Минусы:

TLS-SNI-01

Проверка была описана в черновиках протокола ACME. Согласно ей, вначале выполняется TLS handshake на порте 443, и посылается специальный SNI заголовок для поиска сертификата, содержашего токен. Проверка TLS-SNI-01 отключена в марте 2019 по причине недостаточной безопасности.

TLS-ALPN-01

Разработана после признания проверки TLS-SNI-01 устаревшей, как отдельный стандарт. Как и TLS-SNI-01, проверка TLS-ALPN-01 выполняется через TLS handshake на порте 443. Но в данном случае применяется специальный протокол ALPN, чтобы на запросы валидации отвечали только серверы, знающие о таком типе проверки. Кроме того, становится возможным использовать SNI-поле, совпадающее с именем домена, для которого проводится валидация, для увеличения надёжности проверки.

Эта проверка не подходит для массового использования. Скорее, она предназначена для владельцев TLS-концевых обратных прокси-серверов, для выполнения проверки типа HTTP-01, но внутри слоя TLS, для разделения ответственности. Как правило, это относится к большим хостинг-провайдерам, но распространённые web-серверы типа Apache и Nginx, однажды, поддержат протокол ALPN (а Caddy уже поддерживает).

Плюсы:

Минусы: