Кратко

  • draft-ietf-acme-profiles-02 позволяет серверу объявлять локальные профили и фиксировать выбранное имя в Order; это пока Internet-Draft, а не RFC и не всемирный справочник.
  • Имя подтверждает принятие выбора политики. Допуск аккаунта, контроль идентификатора, поля DER, установка и доверие клиента остаются отдельными квитанциями.
  • Надёжная схема сохраняет Directory и описание на момент заказа, затем проверяет выпущенный сертификат и то, что реально отдаёт конечный узел.

Система продления показывает успех, а в Order записан tlsserver. При этом один балансировщик отдаёт старый сертификат, новый содержит неожиданный EKU, а часть клиентов отвергает цепочку. Профиль не обязан отвечать за эти события: они происходят после выбора.

draft-ietf-acme-profiles-02 от 28 августа 2026 года — рабочий документ ACME Working Group. Он закрывает пробел RFC 8555: CA предлагают разные виды сертификатов, но исходный протокол не даёт общего способа объявить и выбрать политику. Авторы называют два сервера и семь клиентов, Let’s Encrypt описывает эксплуатацию. Это признаки работающего кода, не окончательный стандарт и не полный замер внедрения.

Локальный указатель, а не общий каталог

Сервер публикует meta.profiles в Directory. Короткое имя ведёт к понятному человеку описанию. Клиент может послать его в newOrder, а принятый Order возвращает значение.

Смысл принадлежит серверу. Одинаковое classic у двух CA не обязано означать одно и то же. URL не является обязательной машинной схемой всех X.509-полей и может быть data URI. Строка выбирает локальную политику, а не переносит независимый знак качества.

Это разумный минимализм. Клиент выражает намерение без товарной логики в CSR, CA объявляет варианты без отдельного API, Order сохраняет выбор. Но журнал должен хранить URL Directory, хэш, время, TLS-пира, документ и условия аккаунта. Одно имя теряет контекст.

Из CSR уходит выбор политики, но не ключ

RFC 8555 получает идентификаторы при создании Order и CSR при финализации. Бездумное копирование расширений CSR создаёт риски парсинга и ошибочной выдачи.

Profiles переносит решение в Order. Для него поля CSR, кроме SAN и Subject Public Key, не должны управлять выпуском. CA применяет собственный шаблон.

CSR не исчезает: ключ и SAN существенны. CA отвечает за конструкцию, подпись, цепочку, политику и прозрачность. Протокол только чётче разделяет входы.

Выбор клиента отличается от default сервера

Если клиент послал профиль, подписанный запрос доказывает намерение аккаунта. Сервер всё равно проверяет совместимость.

Если поле пропущено, draft рекомендует серверу выбрать профиль. Тогда значение в Order — решение сервера, не активный выбор подписчика.

Нужно хранить источник выбора, версию и конфигурацию клиента, аккаунт, запрос, ответ, версию политики и право изменения. Так раннее добровольное переключение не смешивается с новым default.

Допуск не равен контролю домена

Несовместимый профиль должен дать invalidProfile, например при неверном типе идентификатора или аккаунте вне allowlist.

Это не ACME-авторизация имени. Аккаунт может иметь право на частный профиль и не подтвердить домен. Успех DNS-01 не даёт права на ограниченный профиль.

Разделяйте допуск аккаунта, проверку каждого идентификатора и решение о выпуске. EAB, договор или allowlist относятся к первому; challenge — ко второму; запись CA и сертификат — к третьему.

Необъявленное исключение должно иметь основание

Серверу следует отклонять неанонсированные имена, но допускаются исключения: частная договорённость или замена при массовом отзыве.

Отсутствие в Directory поэтому не доказывает недействительность. Для исключения фиксируют соглашение или инцидент, аккаунты, срок, ограничения, утверждающего, цель и отзыв. Частное не значит злоупотребление; необъяснимое значит неаудируемое.

При выводе профиля идут двое часов

Профиль может исчезнуть, пока старые Orders живы. Если CA больше не выпускает при finalize, требуется invalidProfile; лучше дождаться истечения Orders.

Учитывайте начало и конец объявления, последний Order, максимальное истечение, последний выпуск, незавершённые renewals, замену и исключения. Иначе поздняя ошибка выглядит как сбой сети или CSR.

Смысл может измениться под прежним именем: срок, EKU, повторное использование авторизации, chain. Определение нужно замораживать для Order и проверять сертификат при каждом продлении.

Объект соответствия — DER

Order выражает обещание политики. Сертификат — проверяемый результат.

Сравнивайте SAN, типы, ключ, Key Usage, EKU, Basic Constraints, Policies, critical, срок, issuer, подпись, chain, serial, кодирование, CT и запрещённые поля с версионным предикатом. Связывайте DER с Order, авторизациями и ключом CSR.

Человеческая документация полезна для выбора, но слаба для автоматизации. CA могла бы публиковать машинный манифест — это предложение статьи, не требование draft. Оно делает локальное обещание проверяемым без центрального каталога.

Повторяйте после renewal. Одинаковое имя не гарантирует одинаковый сертификат. Проверка только ACME-ответа пропускает credential.

CT, CAA и путь доверия независимы

CT показывает журналирование, но не выбор профиля, соответствие или установку. CAA ограничивает CA по своим правилам, но не выбирает profile.

CA может предложить одну цепочку, клиент построить другую. Намерение профиля не заставляет доверяющую сторону принять сертификат.

Выпуск не означает развёртывание

Сертификат и ключ должны попасть на правильный endpoint. Балансировщики, регионы, secret stores, sidecars и старые процессы создают частичный rollout.

Привяжите хэши DER и ключа к целям, наблюдайте снаружи, проверяйте SNI, chain, активацию и уход предшественника, тестируйте клиентов.

Цепочка: обнаружить -> сохранить -> выбрать -> допустить -> авторизовать -> связать Order -> финализировать -> проверить -> развернуть -> наблюдать -> продлить. Каждый следующий шаг требует своего факта.

Производство показывает пользу поэтапного перехода

Let’s Encrypt использует profiles для изменения EKU и срока. tlsserver позволил раньше исключить Client Authentication, временный tlsclient оставил окно, а более короткие сертификаты сначала появились как opt-in.

Это реальный пример разделения раннего перехода, default и ограниченной совместимости. Он же показывает, что имя требует даты. Он не доказывает успех каждого подписчика или поддержку каждым клиентом.

Квитанция профиля

Свяжите Directory, описание, источник выбора, аккаунт, полномочия конфигурации, идентификаторы, ключ, допуск, авторизации, Order, CSR, DER, serial, issuer, chain, CT, результат проверки, цели, наблюдение, clients, renewal, исключение и rollback.

Возврат имени — наблюдение. Соответствие DER версии X — тест. Выдача DER endpoint'ом — другое наблюдение. Бизнес-результат находится ещё дальше.

Минимальный протокол и локальные доказательства лучше, чем попытка превратить имя в универсальную власть.