Acme challenge что это

Challenge Types

When you get a certificate from Let’s Encrypt, our servers validate that you control the domain names in that certificate using “challenges,” as defined by the ACME standard. Most of the time, this validation is handled automatically by your ACME client, but if you need to make some more complex configuration decisions, it’s useful to know more about them. If you’re unsure, go with your client’s defaults or with HTTP-01.

HTTP-01 challenge

This is the most common challenge type today. Let’s Encrypt gives a token to your ACME client, and your ACME client puts a file on your web server at http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN> . That file contains the token, plus a thumbprint of your account key. Once your ACME client tells Let’s Encrypt that the file is ready, Let’s Encrypt tries retrieving it (potentially multiple times from multiple vantage points). If our validation checks get the right responses from your web server, the validation is considered successful and you can go on to issue your certificate. If the validation checks fail, you’ll have to try again with a new certificate.

Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates (since this challenge is intended to bootstrap valid certificates, it may encounter self-signed or expired certificates along the way).

The HTTP-01 challenge can only be done on port 80. Allowing clients to specify arbitrary ports would make the challenge less secure, and so it is not allowed by the ACME standard.

• It’s easy to automate without extra knowledge about a domain’s configuration.
• It allows hosting providers to issue certificates for domains CNAMEd to them.
• It works with off-the-shelf web servers.

• It doesn’t work if your ISP blocks port 80 (this is rare, but some residential ISPs do this).
• Let’s Encrypt doesn’t let you use this challenge to issue wildcard certificates.
• If you have multiple web servers, you have to make sure the file is available on all of them.

DNS-01 challenge

This challenge asks you to prove that you control the DNS for your domain name by putting a specific value in a TXT record under that domain name. It is harder to configure than HTTP-01, but can work in scenarios that HTTP-01 can’t. It also allows you to issue wildcard certificates. After Let’s Encrypt gives your ACME client a token, your client will create a TXT record derived from that token and your account key, and put that record at _acme-challenge.<YOUR_DOMAIN> . Then Let’s Encrypt will query the DNS system for that record. If it finds a match, you can proceed to issue a certificate!

Since automation of issuance and renewals is really important, it only makes sense to use DNS-01 challenges if your DNS provider has an API you can use to automate updates. Our community has started a list of such DNS providers here. Your DNS provider may be the same as your registrar (the company you bought your domain name from), or it might be different. If you want to change your DNS provider, you just need to make some small changes at your registrar. You don’t need to wait for your domain to be close to expiration to do so.

Note that putting your full DNS API credentials on your web server significantly increases the impact if that web server is hacked. Best practice is to use more narrowly scoped API credentials, or perform DNS validation from a separate server and automatically copy certificates to your web server.

Since Let’s Encrypt follows the DNS standards when looking up TXT records for DNS-01 validation, you can use CNAME records or NS records to delegate answering the challenge to other DNS zones. This can be used to delegate the _acme-challenge subdomain to a validation-specific server or zone. It can also be used if your DNS provider is slow to update, and you want to delegate to a quicker-updating server.

Most DNS providers have a “propagation time” that governs how long it takes from the time you update a DNS record until it’s available on all of their servers. It can be hard to measure this because they often also use anycast, which means multiple servers can have the same IP address, and depending on where you are in the world you might talk to a different server (and get a different answer) than Let’s Encrypt does. The best DNS APIs provide a way for you to automatically check whether an update is fully propagated. If your DNS provider doesn’t have this, you just have to configure your client to wait long enough (often as much as an hour) to ensure the update is propagated before triggering validation.

You can have multiple TXT records in place for the same name. For instance, this might happen if you are validating a challenge for a wildcard and a non-wildcard certificate at the same time. However, you should make sure to clean up old TXT records, because if the response size gets too big Let’s Encrypt will start rejecting it.

• You can use this challenge to issue certificates containing wildcard domain names.
• It works well even if you have multiple web servers.

• Keeping API credentials on your web server is risky.
• Your DNS provider might not offer an API.
• Your DNS API may not provide information on propagation times.

TLS-SNI-01

This challenge was defined in draft versions of ACME. It did a TLS handshake on port 443 and sent a specific SNI header, looking for certificate that contained the token. It was disabled in March 2019 because it was not secure enough.

TLS-ALPN-01

This challenge was developed after TLS-SNI-01 became deprecated, and is being developed as a separate standard. Like TLS-SNI-01, it is performed via TLS on port 443. However, it uses a custom ALPN protocol to ensure that only servers that are aware of this challenge type will respond to validation requests. This also allows validation requests for this challenge type to use an SNI field that matches the domain name being validated, making it more secure.

This challenge is not suitable for most people. It is best suited to authors of TLS-terminating reverse proxies that want to perform host-based validation like HTTP-01, but want to do it entirely at the TLS layer in order to separate concerns. Right now that mainly means large hosting providers, but mainstream web servers like Apache and Nginx could someday implement this (and Caddy already does).

• It works if port 80 is unavailable to you.
• It can be performed purely at the TLS layer.

• It’s not supported by Apache, Nginx, or Certbot, and probably won’t be soon.
• Like HTTP-01, if you have multiple servers they need to all answer with the same content.
• This method cannot be used to validate wildcard domains.

Let’s Encrypt is a free, automated, and open certificate authority brought to you by the nonprofit Internet Security Research Group (ISRG).

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

Когда вы запрашиваете новый сертификат у 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 (это редко, но это делают некоторые провайдеры).
• Не подходит для сертификатов с подстановкой (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-серверов.

• Хранение учётной записи для API на web-сервере достаточно рискованно.
• У Вашего провайдера 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-сервера.

  Let’s Encrypt — это бесплатный, автоматизированный и открытый Центр Сертификации, созданный для вас некоммерческой организацией Internet Security Research Group (ISRG).

  Sorry, you have been blocked

  This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

  What can I do to resolve this?

  You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.

  Cloudflare Ray ID: 7a2695ee1f4324b6 • Your IP: Click to reveal 88.135.219.175 • Performance & security by Cloudflare

  Обеспечение автоматизации проверки владения доменом на основе DNS-записей в протоколе ACME [перевод]

  От переводчика: Это перевод статьи от EFF
  A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation.
  Автор оригинальной статьи: Joona Hoikkala.
  Дата оригинальной публикации: 23 февраля 2018

  Ранее в этом месяце, Let’s Encrypt (бесплатный, автоматизированный, открытый центр сертификации, который EFF помог запустить два года назад) преодолел важный рубеж: выдачу более 50 миллионов активных сертификатов. И это число будет продолжать расти, потому что через несколько недель Let’s Encrypt также начнет выдавать wildcard-сертификаты, о которых просили многие системные администраторы.

  Что такое wildcard-сертификат?

  Чтобы проверить сертификат HTTPS, браузер пользователя проверяет, действительно ли доменное имя веб-сайта указано в сертификате. Например, сертификат от www.eff.org должен фактически включать в себя www.eff.org как действительный домен для этого сертификата. Сертификаты также могут содержать несколько доменов (например, www.eff.org, ssd.eff.org, sec.eff.org и т.д.), если владелец просто хочет использовать один сертификат для всех своих доменов.

  Wildcard-сертификат — это сертификат, который гласит: «Я действителен для всех поддоменов в этом домене», а не явно перечисляя их все. (В сертификате это указывается с помощью символа подстановки, обозначенного звездочкой. Поэтому, если Вы сейчас проверите сертификат для eff.org, он скажет, что он действителен для *.eff.org.) Таким образом, системный администратор может получить сертификат для всего своего домена и использовать его в новых поддоменах, о которых он даже не думал, когда получал сертификат.

  Для выдачи wildcard-сертификатов Let’s Encrypt будет требовать от пользователей подтверждения своего контроля над доменом, используя проверку(challenge) на основе DNS, системы доменных имен, которая переводит доменные имена, такие как www.eff.org, в IP-адреса, такие как 69.50.232.54. С точки зрения центра сертификации, такого как Let’s Encrypt, нет лучшего способа доказать, что Вы управляете доменом, чем путем изменения его записей DNS, поскольку управление доменом является одной из основ DNS.

  Однако, одна из ключевых идей Let’s Encrypt заключается в том, что получение сертификата должно быть автоматическим процессом. Но, чтобы автоматизировать его, программное обеспечение, запрашивающее сертификат, также должно будет иметь возможность изменять записи DNS для этого домена. В целях реализации этой возможности программное обеспечение также должно иметь доступ к учетным данным для службы DNS (например, логин и пароль или криптографический токен), а эти учетные данные должны храниться там, где происходит автоматизированное получение сертификата.

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

  Как работает проверка владения доменом?

  На высоком уровне проверка владения доменом работает, как и все остальные автоматические проверки, которые являются частью протокола ACME, — протокола, который может использовать центр сертификации (CA), например Let’s Encrypt, и клиентское программное обеспечение, например Certbot, для обмена информацией о том, какой сертификат запрашивает сервер, и как сервер должен подтвердить право собственности на соответствующее доменное имя.

  Во время проверки владения доменом пользователь запрашивает сертификат из CA с помощью клиентского программного обеспечения ACME, такого как Certbot, который поддерживает данный тип проверки. Когда клиент запрашивает сертификат, CA запрашивает у клиента подтверждение права собственности на домен, путем добавления конкретной TXT-записи в свою зону DNS. Более подробно: CA отправляет уникальный случайный токен ACME-клиенту, и тот, кто имеет контроль над доменом, должен поместить этот токен как TXT-запись в свою зону DNS, в предопределенный поддомен с именем «_acme-challenge» того домена, контроль над которым пытается доказать пользователь.

  Например, если Вы пытаетесь проверить домен для *.eff.org, поддомен проверки будет «_acme-challenge.eff.org». Когда значение токена добавляется в зону DNS, клиент сообщает CA продолжить проверку владения, после чего CA будет выполнять DNS-запрос к авторитетным серверам для домена. Если авторитетные DNS-серверы ответят DNS-записью, содержащей правильный токен проверки владения, право собственности на домен будет доказано, и процесс выдачи сертификата может быть продолжен.

  DNS служба контролирует цифровую идентичность

  Угрозы, связанные с DNS-зоной делает столь опасными, то, что DNS — это то, на что полагаются браузеры пользователей, чтобы знать, с каким IP-адресом они должны связаться, пытаясь достичь вашего домена. Это относится ко всем службам, использующим разрешаемое имя под вашим доменом, от электронной почты до веб-служб.

  Когда DNS скомпрометирован, злоумышленник может легко перехватить все подключения, направленные к вашей электронной почте или другой защищенной службе, прекратить шифрование TLS (поскольку теперь они могут подтвердить право собственности на домен и получить для них свои действительные сертификаты), дешифровать данные и прочесть их, а затем повторно зашифровать данные и передать их на ваш сервер. Для большинства людей это было бы очень трудно обнаружить.

  Отдельные и ограниченные привилегии

  Строго говоря, для того, чтобы ACME-клиент делал обновления в автоматическом режиме, этот клиент должен иметь доступ только к учетным данным, которые могут обновлять TXT-записи для поддоменов «_acme-challenge». К сожалению, большинство программных продуктов DNS и поставщиков услуг DNS не предлагают подробные средства контроля доступа, которые позволяют ограничить эти привилегии, или просто не предоставляют API для автоматизации этого за пределами основных обновлений или транзакций DNS-зоны. Это оставляет возможные методы автоматизации непригодными или небезопасными.

  Есть простой способ, который может помочь маневрировать мимо таких ограничений: использовать CNAME-запись. CNAME-записи по существу действуют как ссылки на другую запись DNS. Let’s Encrypt проследует по цепочке CNAME-записей и разрешит токен проверки владения для последней записи в цепочке.

  Способы смягчения проблемы

  Даже используя CNAME-записи, основная проблема заключается в том, что ACME-клиенту по-прежнему будет нужен доступ к учетным данным, которые позволят ему изменить некоторую DNS-запись. Существуют различные способы смягчения этой основной проблемы с различными уровнями сложности и последствиями для безопасности в случае компрометации.

  В следующих разделах этот пост представляет некоторые из этих методов, пытаясь объяснить возможные последствия того, что учетные данные будут скомпрометированы. За одним исключением, все они используют CNAME-записи.

  Разрешить обновления только для TXT-записей

  Первый способ — создать набор учетных данных с привилегиями, которые позволяют обновлять TXT-записи.

  В случае компрометации этот метод ограничивает последствия для злоумышленника способностью выдавать сертификаты для всех доменов в зоне DNS (поскольку они могут использовать учетные данные DNS для получения собственных сертификатов), а также прерывание доставки почты. Воздействие на доставку почты происходит из TXT-записей, специфичных для почты, а именно SPF, DKIM и его расширения ADSP и DMARC. Их компрометация также облегчит доставку фишинговых писем, выдающих себя за отправителя из скомпрометированного домена.

  Использовать «throwaway» домен подтверждения

  Второй способ — вручную создать CNAME-записи для поддомена «_acme-challenge» и указать ими на домен проверки, который будет находиться в зоне, контролируемой другим набором учетных данных.

  Например, если Вы хотите получить сертификат для покрытия «yourdomain.tld» и «www.yourdomain.tld», вам придется создать две CNAME-записи — «_ acme-challenge.yourdomain.tld» и «_acme-challenge.www.yourdomain.tld» — а также указать ими на внешний домен для проверки. Домен, используемый для проверки владения, должен быть во внешней зоне DNS или в поддиапазонной зоне DNS, которая имеет свой собственный набор учетных данных для управления. (DNS-зона субделегата определяется с помощью NS-записей и фактически делегирует полный контроль над частью зоны внешнему источнику.)

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

  Ограниченный доступ к зоне DNS

  Если ваше программное обеспечение или поставщик DNS позволяет создавать разрешения, привязанные к поддомену (гранулированные привилегии), это может помочь вам смягчить всю проблему.

  К сожалению, на момент публикации был найден единственный поставщик, который дает данные привилегии — это Microsoft Azure DNS. У Dyn предположительно также есть гранулированные привилегии, но мы не смогли найти более низкий уровень привилегий в их сервисе помимо «Обновление записей», которые все еще оставляют зону полностью уязвимой.

  Route53 и, возможно, другие позволяют своим пользователям создавать зону субделегата, новые учетные данные пользователя, указывать NS-записи в новую зону и указывать поддомены проверки _acme-challenge для них с использованием CNAME-записей. Нужно много работы для того, чтобы корректно сделать распределение привелегий, используя этот метод, так как нужно пройти все эти шаги для каждого домена, для которого необходимо использовать проверку владения.

  Использовать ACME-DNS

  Дисклеймер: программное обеспечение, описанное ниже, написано автором (оригинальной статьи — прим. переводчика), и оно используется в качестве примера функций, необходимых для эффективного управления учетными данными, нужными для автоматизации проверки владения доменом через DNS безопасным образом.

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

  ACME-DNS действует как простой DNS-сервер с ограниченным HTTP API. Сам API позволяет только обновлять TXT-записи автоматически генерируемых случайных поддоменов. В нём нет методов для запроса утерянных учетных данных, обновления или добавления других записей. Он предоставляет две конечные точки:

  • /register — эта конечная точка создает новый поддомен для использования, сопровождаемый именем пользователя и паролем. В качестве необязательного параметра конечная точка регистра принимает список диапазонов CIDR для «белых» обновлений.
  • /update — эта конечная точка используется для обновления текущего токена проверки владения доменом на сервере.

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

  Дополнительные сведения об ACME-DNS см. на странице:
  github.com/joohoi/acme-dns

  Вывод

  Чтобы устранить проблемы с проверкой владения доменом через ACME DNS, обсуждались такие предложения, как assisted-DNS в рабочей группе ACME IETF, но в настоящее время эти проблемы все еще остаются без разрешения. Поскольку единственный способ ограничить воздействие компрометации — это ограничить права доступа учетных записей DNS-зоны до изменения определенных TXT-записей, текущие возможности для надежной реализации автоматизации проверки владения доменом незначетельны.

  Единственным устойчивым вариантом было бы заставить программное обеспечение DNS и поставщиков услуг либо внедрять методы для создания более мелкомасштабных учетных данных зоны, либо предоставлять совершенно новый тип учетных данных для этого специфического варианта использования.

  Похожие публикации:

  1. Патч бармина что это
  2. Android studio как собрать screencap
  3. Windows driver kit что это
  4. Proxmox local lvm где