Последнее обновление: | Вся документация
Внимание! Английская версия сайта была обновлена, перевод неактуален () Просмотреть на английском
Когда вы запрашиваете новый сертификат у 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.
Плюсы:
- Упрощённая автоматизация процесса, не требующая дополнительных знаний по настройке доменов
- Выпуск сертификатов для доменов хостинг-провайдеров, привязанных по CNAME.
- Совместим с уже настроенными web-серверами.
Минусы:
- Требует открытого порта 80 (редко, но интернет-провайдеры блокируют этот адрес)
- Let’s Encrypt не разрешает использовать эту проверку для сертификатов с подстановкой (wildcard-сертификатов).
- Для каждого web-сервера требуется свой файл.
Проверка 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 признает проверку неудачной.
Плюсы:
- Подходит для сертификатов с подстановкой (wildcard-сертификатов).
- Одна запись для нескольких web-серверов.
Минусы:
- У DNS-провайдера может не быть своего API.
- Хранение учётной записи для DNS API небезопасно.
- DNS API может не быть методов оценки период обновления записей.
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 уже поддерживает).
Плюсы:
- Будет работать даже если порт 80 закрыт.
- Реализована целиком внутри слоя TLS
Минусы:
- Пока не поддерживается Apache, Nginx или Certbot, и, возможно, не будет поддерживаться.
- Как и для проверки HTTP-01, настраивать нужно ответ от каждого web-сервера.