acme challenge что это

Let’s Encrypt начал выдавать wildcard сертификаты

Let’s Encrypt перешагнул важную веху — с 14 марта каждый может получить бесплатный SSL/TLS сертификат вида *.example.com. Пример установленного сертификата:

Вчера Let’s Encrypt официально объявил о запуске ACMEv2 (Automated Certificate Management Environment), который наконец позволяет получить wildcard сертификат. Изначально планировалось начать их выдачу в январе, однако запуск перенесли из-за обнаруженных проблем.

Получение wildcard сертификата сейчас возможно только через DNS challenge, где необходимо временно создать TXT запись вида _acme-challenge.example.com с определенным значением.

Официальный клиент Certbot и некоторые другие клиенты для автоматического обновления сертификатов уже поддерживают staging ACMEv2, версии для production на подходе. И чтобы автоматически пройти DNS challenge уже есть несколько специальных Certbot плагинов. Разумеется, скоро их будет еще больше, в том числе и для сторонних клиентов.

В качестве простейшего примера я вручную получил сертификат на домен, которым владею — baur.im, через браузерный клиент https://www.sslforfree.com. Если я хочу использовать один и тот же сертификат как для суб-доменов, так и для самого домена, то это надо указать явно: baur.im *.baur.im (картинки кликабельны):

Пройдя дальше, предлагается пройти два DNS challenge.

Добавляем обе запрашиваемые TXT записи на суб-домен _acme-challenge.baur.im

И можно скачивать сертификат, который будет действовать 3 месяца.

Источник

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

Последнее обновление: 25 февр. 2019 г. | Вся документация

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

Проверка HTTP-01

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

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

Проверка DNS-01

Крайне важно автоматизировать процессы выпуска и отзыва сертификатов, поэтому проверку 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 уже поддерживает).

Все письма и запросы направляйте по адресу:

Источник

Обеспечение автоматизации проверки владения доменом на основе 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-записи автоматически генерируемых случайных поддоменов. В нём нет методов для запроса утерянных учетных данных, обновления или добавления других записей. Он предоставляет две конечные точки:

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

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

Вывод

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

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

Источник

Использование Let’s Encrypt для внутренних серверов

Let’s Encrypt — это центр сертификации, который предоставляет бесплатные сертификаты в полностью автоматизированном процессе. Эти сертификаты выдаются по протоколу ACME. За последние два года в Интернете широко использовалась технология Let’s Encrypt — более 50% веб-сертификатов SSL / TLS теперь выдает Let’s Encrypt.

В этом посте описывается, как выдавать сертификаты Let’s Encrypt для внутренних серверов.

Хотя и существует множество инструментов для автоматического обновления сертификатов для общедоступных веб-серверов (certbot, simp_le, я писал о том, как это сделать), трудно найти какую-либо полезную информацию о том, как выдавать сертификаты для внутренних серверов, не подключенных к Интернету, и / или устройства с Let’s Encrypt.

В Datto мы выдали сертификат на каждую из наших 90 000+ устройств BCDR, использующих именно этот механизм.

Hello Hacker News, впервые на главной странице HN! Для меня это большая честь! Я ответил на все вопросы в разделе комментариев.

Если вы ищете реализацию этой идеи, вам может быть интересен localtls. Я сам не тестировал, но похоже, что он делает то же самое, что я здесь описываю.

Итак, действительно волшебными ингредиентами для выдачи сертификатов для внутренних компьютеров, не подключенных к Интернету, являются:

Выделенная зона DNS для всех ваших внутренних устройств, например xi8qz.example.com и динамический DNS-сервер для управления этой зоной (здесь: example.com )

Клиент ACME, способный использовать DNS-запрос Let’s Encrypt для подтверждения права собственности на домен.

Пример: внутренний сервер 10.1.1.4, он же. xi8qz.example.com

На следующей диаграмме показано, как мы реализовали интеграцию Let’s Encrypt для наших устройств резервного копирования Datto. Каждое устройство (читайте: внутренний сервер) находится за NAT и имеет собственный локальный IP-адрес.

Общий подход прост: устройство регулярно обращается к нашему серверу управления, чтобы обеспечить доступ к нему через его собственный поддомен. Если его локальный IP-адрес изменяется, он запускает обновление своего собственного поддомена. Кроме того, он регулярно проверяет, действителен ли сертификат, и запрашивает обновление, если он устарел.

Вот немного подробностей об этом процессе:

Участники этого процесса:

2.1. Предварительные требования: назначение домена для каждой машины (шаги 1-3)

Как упоминалось выше, нам нужно дать каждому устройству правильное доменное имя, чтобы иметь возможность подтвердить право собственности на Let’s Encrypt, поэтому нам нужно купить домен (здесь: example.com ) и делегировать его NS-записи нашему серверу DDNS:

Вдобавок к этому нам нужна возможность динамически добавлять и удалять записи из него (через какой-то API). Я ранее писал о том, как развернуть собственный DDNS-сервер, если вам интересно.

После того, как все это настроено, нам нужно убедиться, что запись A машины обновляется при изменении ее IP-адреса. Для нашей внутренней машины давайте назначим xi8qz.example.com в качестве домена. Если все работает правильно, вы сможете разрешить этот домен по его IP-адресу, используя обычный DNS-запрос:

2.2. Запрос сертификата (шаги 4-14)

Предполагая, что теперь вы полностью контролируете зону DNS для example.com и можете быстро редактировать ее динамически, у вас все готово для фактической выдачи сертификатов для вашего локального домена устройства через Let’s Encrypt.

После авторизации запроса (важный шаг, не показанный на схеме!), Управляющий сервер запрашивает DNS-запрос для данного домена из ACME API через вызов Pre-Authorization / new-authz API (шаг 6). ACME API отвечает запросом DNS (шаг 7). Если все идет хорошо, это выглядит примерно так:

Используя этот ответ, управляющий сервер должен установить запись DNS TXT на _acme-challenge.xi8qz.example.com (шаг 8) и уведомить ACME API о том, что ответ на запрос был размещен (шаг 9).

После того, как ответ на запрос был проверен с помощью Let’s Encrypt (шаг 10-11), сертификат можно, наконец, запросить с помощью CSR (шаг 12-13).

После того, как Let’s Encrypt ответит сертификатом, вы увидите на проводе что-то вроде этого:

Этот сертификат затем возвращается в машину (шаг 14). После перезапуска веб-сервера устройства / сервера к его веб-интерфейсу можно будет получить доступ через HTTPS в браузере или из командной строки:

Рекомендации по развертыванию: ограничения скорости Let’s Encrypt.

Важно отметить, что если вы планируете реализовать этот механизм для большого количества серверов, вы используете staging среды Let’s Encrypt для тестирования и, что более важно, учитываете лимиты выдачи сертификатов.

По умолчанию Let’s Encrypt позволяет выдавать только 20 сертификатов (в 2018 году) в неделю для одного и того же домена или одной и той же учетной записи. Чтобы увеличить это число, вы должны либо запросить более высокий лимит выдачи, либо добавить свой домен в список общедоступных суффиксов (обратите внимание: добавление вашего домена здесь имеет другие последствия!).

Из-за этих ограничений скорости жизненно важно, чтобы вы распределили начальное развертывание настолько, чтобы оставаться ниже ограничения скорости, и чтобы вы оставили достаточно места для добавления будущих серверов. Также рассмотрите возможность продления в первоначальном плане развертывания.

Резюме

Как видите, это не так уж и сложно.

Сначала мы присвоили каждому устройству (так называемому внутреннему серверу) публичное доменное имя, используя наш собственный динамический DNS-сервер и выделенную зону DNS. Используя домен, назначенный серверу (здесь: xi8qz.example.com ), мы затем использовали предложение бесплатного сертификата Let’s Encrypt и их запрос DNS, чтобы выпустить сертификат для этого сервера.

Сделав это для всех внутренних серверов, мы можем обеспечить безопасную связь в нашей внутренней ИТ-инфраструктуре без необходимости развертывания настраиваемого сертификата CA или необходимости платить за сертификаты.

Источник