Let’s Encrypt ACME: автоматизация выдачи сертификатов и надежное управление их продлением

Процедура ACME и разделение ролей ключей

ACME стандартизирует обмен данными между клиентом и центром сертификации, а не всю операционную среду в целом. Сначала клиент использует учётную запись ACME, а затем создаёт заявку на один или несколько доменных имён. Для каждого идентификатора сервер запрашивает авторизацию. Только после успешной авторизации клиент может завершить обработку заявки с помощью запроса на подпись сертификата (Certificate Signing Request, сокращённо CSR) и получить выданный сертификат.

1. Создайте ключ учетной записи или используйте существующую учетную запись ACME и создайте ордер.
2. Для каждого запрошенного идентификатора предоставить заданный челлендж и дождаться авторизации.
3. Сгенерировать отдельную пару ключей для сертификата, сформировать на её основе CSR и завершить оформление заказа. Открытый ключ в CSR не должен совпадать с ключом учетной записи, используемым для аутентификации заявки на завершение оформления.
4. Загрузить сертификат и цепочку сертификатов, надежно сохранить их и распространить по назначенным конечным точкам TLS.

Der Ключ учетной записи ACME аутентифицирует клиента для данной учетной записи перед сервером ACME и подписывает сообщения протокола. В то же время частный ключ, используемый в CSR, относится к будущей идентичности TLS. Стандарт RFC 8555 требует использования двух разных классов ключей: открытый ключ CSR не должен соответствовать какому-либо известному ключу учетной записи и, в частности, не должен быть идентичен ключу учетной записи, который аутентифицирует запрос на финализацию. Клиент и сервер должны проверить это разделение.

В случае с DNS-01 добавляется третий уязвимый компонент: авторизационные данные для DNS-API. Let’s Encrypt обращает внимание на то, что наличие полных учетных данных для доступа к DNS-API на веб-сервере значительно увеличивает последствия возможной атаки. Поэтому в целях обеспечения безопасности токен должен иметь право изменять только необходимые записи-вызовы; в качестве альтернативы проверка DNS может осуществляться на отдельной системе.

Ключи учетной записи, ключи сертификатов и доступ к DNS образуют разные зоны доверия. Использование разных пар ключей для учетной записи и сертификата является требованием протокола; кроме того, их раздельное хранение, строго ограниченные права доступа и независимые процессы ротации являются важными эксплуатационными мерами. Таким образом, компрометация токена DNS не обязательно означает получение доступа ни к закрытому ключу сертификата, ни к учетной записи ACME.

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

Подходящий вызов для инфраструктуры

Этот критерий определяет, как центр сертификации проверяет контроль над идентификатором. Поэтому он должен выводиться из сетевого пути, управления DNS и терминации TLS, а не из общего предпочтения в пользу того или иного клиентского инструмента. HTTP-01, DNS-01 и TLS-ALPN-01 описывают различные способы проверки и, соответственно, предъявляют разные требования к инфраструктуре и правам доступа.

Для отдельного веб-сайта, доступного для общественности, HTTP-01 как правило, самый прямой путь. Клиент размещает ресурс под /.well-known/acme-challenge/ готовый, который запрашивает Let’s Encrypt через порт 80. Если домен указывает на несколько адресов A или AAAA, этот ресурс должен быть доступен на всех системах, на которые может попасть запрос проверки. В противном случае возникает ошибка проверки, которая проявляется лишь изредка.

Сертификаты с подстановочными знаками для *.example.org напротив, требуют обязательного DNS-01. Для этого клиент публикует запись TXT по адресу _acme-challenge.example.org. Это подходит для многих динамических субдоменов, распределенных веб-серверов или балансировщика нагрузки, поскольку ни один отдельный экземпляр HTTP не должен предоставлять файл проверки. Однако необходимым условием является надежное и автоматизируемое изменение DNS.

Обратный прокси-сервер без доступного порта 80 может TLS-ALPN-01 использовать, если он контролирует завершение соединения TLS на порту 443 и используемый клиент поддерживает данный вызов. Проверка осуществляется через специальное TLS-соединение, а не через обычный веб-файл. Таким образом, этот метод особенно подходит для специализированной прокси-инфраструктуры или инфраструктуры хостинга, но не может служить универсальной заменой HTTP-01. Здесь также не поддерживаются подстановочные знаки.

Ни один из методов не является универсально лучшим: HTTP-01 сокращает количество запросов к DNS для простого веб-сайта, DNS-01 поддерживает подстановочные знаки и отделяет проверку от веб-пути, а TLS-ALPN-01 целенаправленно использует существующие механизмы контроля TLS. Решающим фактором является то, чтобы выбранный челлендж работал в реальных условиях отработки отказа, а также в сетях IPv4 и IPv6, и чтобы его права доступа соответствовали конкретной модели эксплуатации.

ARI, профили и более короткие сроки действия

С Информация о продлении подписки на ACME (ARI) логика обновления переходит от фиксированной локальной даты к временному интервалу, рекомендованному сервером ACME. Клиент запрашивает эту информацию для существующего сертификата и выбирает случайный момент времени в пределах этого интервала. Это позволяет распределить обновления во времени и целенаправленно ускорить их в случае особых событий.

ARI — это стандартизированное расширение, но оно не является автоматической функцией каждого установленного клиента или панели хостинга. Let’s Encrypt может предоставлять новые, обратно совместимые функции ACME на существующей конечной точке; то, использует ли их конкретная установка, зависит от её версии и реализации. Поэтому для крупных парков серверов необходимо проверить, запрашивает ли клиент ARI, соблюдает ли он временное окно и не синхронизирует ли повторно обновления.

Кроме того, Let’s Encrypt присваивает заказам профили сертификатов. Если профиль явно не указан, по умолчанию используется классический профиль, срок действия которого в настоящее время составляет 90 дней. Профиль tlsserver имеет срок действия 45 дней, более короткие сроки для открытых авторизаций и заказов, а также не более 25 имен DNS. shortlived также использует короткие сроки действия объектов, действует около 160 часов и поддерживает DNS- и IP-идентификаторы.

Выбор профиля также предполагает поддержку со стороны клиента; его не следует определять исключительно на основании документации по серверу. Помимо срока действия и идентификаторов, профили различаются и по другим свойствам. Поэтому приложения и инструменты инвентаризации не должны молчаливо предполагать ни единообразный порядок действий, ни наличие общего имени (Common Name) в каждом сертификате.

Если посчитать, то соотношение между 90 днями и примерно 160 часами составляет около 13,5. Из этого не следует никакой измеримой нагрузки, но вытекает четкий вывод для планирования: любая сбои при оформлении заказа, распределении или повторной загрузке приводят к краткосрочных сертификатов гораздо раньше. Они целесообразны только для систем, вся цепочка поставок которых находится под контролем и обновление которых не зависит от ручных вмешательств. Для обновлений, координируемых ARI, в Let’s Encrypt действуют особые правила относительно лимитов запросов при соблюдении задокументированных условий.

Матрица задач и безопасная делегация DNS

Выбор задачи определяется доступной инфраструктурой, а не общим рейтингом. HTTP-01 требует общедоступного ответа через порт 80, DNS-01 — контролируемую запись TXT, а TLS-ALPN-01 — контроль над завершением соединения TLS на порту 443. Имена с подстановочными знаками можно проверить исключительно с помощью DNS-01.

Поэтому для веб-сайта с одним веб-сервером зачастую достаточно HTTP-01. Однако если записи DNS типа A или AAAA указывают на несколько систем, каждый фактически достигнутый конечный узел должен предоставлять ожидаемый ресурс. В противном случае результат будет зависеть от того, к какому конечному узлу обратится система проверки. Балансировщик нагрузки или централизованно синхронизированное хранилище запросов устраняет эту проблему только в том случае, если оно охватывает все пути.

Для DNS-01 в качестве Минимальные права доступа Следует стремиться к тому, чтобы клиент ACME мог изменять только необходимые записи-челленджи. Какое ограничение действительно возможно, зависит от API и модели прав доступа провайдера DNS; не каждый сервис предоставляет права на отдельное имя TXT. Если остается только широкий доступ, проверку следует перенести на отдельную систему или делегировать в отдельную зону «Challenge». Учетные данные должны храниться отдельно от сертификатов и ключей учетной записи ACME в защищённом хранилище.

В случае обширных зон отдельная зона «Challenge» может ещё больше ограничить права. Делегирование _acme-challenge С помощью записей CNAME или NS данные проверки переносятся в отдельную зону управления. В этом случае клиент получает права на внесение изменений только в этой зоне. Перед запуском в производственную среду необходимо проверить содержимое записей TXT и разрешение DNS: правильного ответа API недостаточно, если резолверы ещё не видят делегацию или запись.

Надежная автоматизация обновления и распределения

Надежный Управление сертификатами не заканчивается получением сертификата. В распределенной среде центральный ACME-рабочий узел инициирует проверку и обеспечивает защищённое хранение сертификата и закрытого ключа. Только после этого эти элементы распределяются по конечным точкам TLS, где проходят проверку и активируются с контролем. Ключ сертификата, используемый в CSR, должен отличаться от ключа учетной записи ACME, используемого для аутентификации; порядок последующего раздельного хранения, предоставления прав доступа и ротации обоих ключей должен быть зафиксирован в концепции эксплуатации.

В приведенной ниже таблице описана рекомендуемая схема работы цепочки поставок. Стандарт RFC 8555 требует, чтобы открытый ключ CSR не совпадал ни с одним из известных ключей учетной записи и, в частности, не совпадал с ключом учетной записи, используемым для аутентификации задания на завершение. Конкретное организационное разделение хранения, прав доступа и ротации основано на этом требовании протокола. Deploy Hook Certbot предназначен для действий после успешной выдачи сертификата. Защита передачи данных, проверка адреса назначения и внешняя проверка TLS должны соответствовать конкретной инфраструктуре.

При внесении изменений в интеграции с Panel или DNS производственную цепочку не следует рассматривать как отдельную систему. В частности, при управлении через Обновления Plesk для хостинг-провайдеров Доступные функции зависят от Panelstand, расширений и подключенных сервисов. Конкретные возможности ACME-клиента, например, в отношении дополнительных расширений протокола, также зависят от версии и должны проверяться в используемой комбинации.

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

certbot renew --deploy-hook /usr/local/sbin/reload-tls-services

Статус завершения программы certbot renew не является подтверждением наличия нового сертификата: даже если обновлять нечего, команда может завершиться со статусом 0. Поэтому система мониторинга должна самостоятельно определить, какой сертификат фактически предоставляет публичный конечный узел, когда истекает его срок действия и удалась ли перезагрузка.

CAA, профили и сертификаты для IP-адресов

Запись CAA — это Выставочные перила: В ней определяется, какие центры сертификации имеют право выдавать сертификаты для того или иного домена. Кроме того, в политике может быть указан допустимый метод проверки, а также через параметр accounturi указать предусмотренную учетную запись ACME. Текущий ключ учетной записи обеспечивает аутентификацию доступа к этой учетной записи, однако его можно изменить с помощью процедуры смены ключа ACME. Таким образом, привязка к учетной записи не заменяет ни защиту текущего ключа учетной записи, ни комплексную систему управления доступом.

Следующая строка записи разрешает использование Let’s Encrypt для домена только при проверке DNS-01. Она подходит только в том случае, если DNS-01 настроена автоматически, а зона проверки надежно управляется. Те, кто впоследствии захочет использовать HTTP-01 для отдельного веб-сайта или TLS-ALPN-01 для обратного прокси-сервера, сознательно блокируют выдачу сертификата с указанным ограничением.

example.org. CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

Отдельная строка не обязательно описывает полную Политика CAA в этой зоне. Несколько записей одного и того же типа действуют суммарно: если одна из них разрешает выдачу сертификата, это разрешение остается в силе, несмотря на более строгие условия в других записях. Кроме того, для сертификатов с подстановочными знаками необходимо проверить, issuewild- имеются записи. В отсутствие таких записей действует issue в том числе для подстановочных знаков; имеющиеся issuewild-Записи, напротив, отдельно регулируют выдачу символов-заменителей. Поэтому определяющим всегда является полный действующий набор записей для проверяемого имени.

Сертификаты для публичных IP-адресов — это отдельный случай, отличающийся от сертификатов для доменов. Let’s Encrypt поддерживает IP-идентификаторы в профиле shortlived; в качестве методов проверки подходят HTTP-01 и TLS-ALPN-01. DNS-01 не может проверять IP-адреса. Поэтому короткий срок действия — примерно 160 часов — требует непрерывного автоматизированного обновления, распространения и контроля доставки.

Таким образом, профиль «shortlived» подходит, например, для интерфейсов, доступных напрямую по IP, только в том случае, если каждый шаг выполняется без ручного вмешательства. Это не упрощённый вариант для систем, обслуживаемых лишь изредка. Кроме того, используемый ACME-клиент и целевая среда должны поддерживать выбранный профиль, а также выбранный челлендж; наличие данной функции в ACME-сервисе не гарантирует её поддержку каждой версией клиента.

Мониторинг и поиск неисправностей сначала в тестовой среде

Диагностика неполадок в ACME начинается с проверки фактически используемого метода валидации, а не с повторного запроса на сертификат. Для внесения изменений в настройки клиента, маршрутизации, брандмауэра или DNS подходит отдельная тестовая точка доступа Let’s Encrypt. Тестовая среда имеет собственные, значительно более высокие лимиты, но не является безграничной; выданные там тестовые сертификаты не являются общедоступными и не вызывают доверия. Хотя новые функции протокола могут быть доступны на конечной точке ACME, поддержка установленного клиента всё же должна проверяться отдельно.

В случае ошибки HTTP-01 сначала необходимо проверить, доступен ли соответствующий домен из внешней сети через порт 80 и находится ли запрашиваемый файл по адресу /.well-known/acme-challenge/ на целевую систему. Наличие нескольких записей A или AAAA усложняет тест: каждая фактически доступная конечная точка должна предоставить соответствующий файл-запрос. Типичными причинами являются несоответствующая маршрутизация виртуальных хостов, прокси-сервер, расположенный выше по цепочке, правило брандмауэра или несинхронизированные контейнеры.

TLS-ALPN-01, напротив, требует контроля над завершением соединения TLS на порту 443. В случае ошибки следует проверить, какой балансировщик нагрузки или прокси принимает соединение, предоставляет ли он сертификат, необходимый для проверки, и не переопределяет ли стандартный TLS-сервис этот процесс. Успешно созданный локальный файл сертификата не является доказательством того, что публично доступная конечная точка использует именно его.

В случае DNS-01 имя и содержимое записи TXT указаны в разделе _acme-challenge проверять отдельно. Запись должна быть опубликована в делегированной или авторитетной зоне; кроме того, при использовании отдельной зоны проверки должна быть правильной цепочка делегирования. Повторные неудачные попытки, связанные с опечатками, ещё не отобразившимися изменениями или некорректным делегированием, следует сначала проанализировать в тестовой среде.

Эффективное Мониторинг не только отслеживает дату истечения срока действия в хранилище ACME-Worker. Он независимо проверяет предоставленное имя хоста, оставшийся срок действия сертификата, указанного в нём, а также успешность перезагрузки после обновления. Сигнал тревоги должен подаваться также в случае, если обновление завершилось неудачно или конечный узел, несмотря на успешную выдачу, по-прежнему предоставляет старый сертификат. Что касается запланированных изменений на хостинг-серверах, в данной статье дополняется Безопасное планирование обновлений cPanel и WHM необходимое планирование производственных операций.

Лимиты ставок и продление действующих контрактов

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

Информация о продлении подписки на ACME, кратко ARI, заменяет фиксированные локальные пороговые значения на окно обновления, рекомендованное сервером ACME для существующего сертификата. Клиент с поддержкой ARI запрашивает информацию об обновлении и выбирает случайный момент времени в пределах этого окна. Планировщик может регулярно запускать клиент, но сам не анализирует данные ARI. Клиент должен определить рекомендованный интервал и Retry-After учитывать, а также в случае ошибок соблюдать надлежащие интервалы отката и повторения. Поэтому более частые запуски планировщика не должны приводить к бесконечным повторениям неудачных заданий.

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

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

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

Выбор подходящей модели работы с учетом рисков

Для отдельного веб-сайта, доступного из открытого Интернета, HTTP-01, как правило, является самой простой моделью работы. Веб-сервер должен надежно обслуживать порт 80 и предоставлять файл-запрос по ожидаемому пути. Эта модель не совместима с подстановочными знаками и становится неустойчивой, если на один и тот же домен отвечают несколько независимых целей. Поэтому она целесообразна, прежде всего, в тех случаях, когда веб-маршрутизация, хранение сертификатов и предоставление TLS объединены в одном четко контролируемом месте.

DNS-01 — подходящая модель для использования подстановочных знаков, динамических субдоменов и распределенных конечных точек TLS. Необходимым условием является не просто доступ к DNS, а возможность безопасного автоматизированного изменения требуемой записи TXT. Использование токена с максимально узкой областью действия или делегированной зоны проверки (challenge-zone) позволяет снизить последствия взлома системы. Достижимая степень детализации зависит от DNS-API. Делегирования должны быть задокументированы как производственные зависимости, подлежать мониторингу и иметь механизм восстановления.

TLS-ALPN-01 подходит для операторов, которые целенаправленно управляют терминацией TLS на порту 443, например, на обратном прокси-сервере или балансировщике нагрузки. Данный метод не является универсальной заменой HTTP-01 и не поддерживает подстановочные знаки. Его практическая применимость дополнительно зависит от конкретной реализации на стороне клиента и прокси-сервера. Поэтому перед использованием необходимо проверить, может ли программное обеспечение генерировать запрос на проверку подлинности, передавать его и после завершения корректно удалять.

Das Профиль shortlived подходит только для систем с полной сквозной автоматизацией. Let’s Encrypt указывает для этого срок действия около 160 часов, а также DNS- и IP-идентификаторы; по сравнению со стандартным профилем со сроком действия 90 дней это теоретически значительно увеличивает необходимую частоту обновления. Поэтому каждый этап — от заказа до распределения, перезагрузки и внешней проверки — должен работать надежно. Выбор профиля также предполагает, что используемый ACME-клиент действительно поддерживает выбор профиля.

Независимо от модели, требуется профессиональное Управление сертификатами полный перечень активов, надёжное управление ключами и доступ к DNS с минимальными правами. Ключ учётной записи служит для аутентификации клиента в учётной записи ACME; частный ключ, используемый в CSR, относится к идентификатору TLS. RFC 8555 запрещает использование открытого ключа учетной записи в сертификате: в частности, ключ в CSR не должен совпадать с ключом учетной записи, который аутентифицирует запрос на финализацию. Раздельное хранение, предоставление прав доступа и ротация этих классов ключей, а также отзывные права доступа и проверенный механизм возврата к предыдущему сертификату являются частью концепции управления правами и действий в чрезвычайных ситуациях.

Успешное выполнение ACME не должно быть единственным критерием успешности. Контроль доставки должен осуществляться вне рабочего процесса, чтобы определить, какой сертификат представляет подлинная конечная точка TLS. Для этапов развертывания и перезагрузки подходят действия, которые запускаются только после успешного обновления; в Certbot для этого предусмотрен deploy hook. Его скрипт должен быть идемпотентным, регистрировать ошибки и перезагружать только те службы, которые действительно используют обновлённые данные.