Кратко

  • RFC 9773 позволяет центру сертификации рекомендовать период для попытки продления, а новому заказу — назвать предыдущий сертификат. Случайный выбор момента, устойчивый откат частоты, резервный график, выпуск ACME и развёртывание остаются локальными решениями клиента.
  • suggestedWindow, принятый replaces, заказ в состоянии valid, скачивание, запись CT, установленный файл и сертификат, увиденный в новом TLS-рукопожатии, доказывают разные факты. Ни один из них не должен изображать завершение следующего этапа.

Один зелёный статус и шесть часов

Панель показывает «продлён». Слово кажется точным, потому что прячет не меньше шести независимых часов.

Центр сертификации выбирает период, когда он предпочитает принять работу. Клиент выбирает момент внутри периода. Retry-After задаёт следующую проверку информации. Состояние ошибок ограничивает повторную попытку. Система развёртывания выбирает момент доставки и перезагрузки процессов. Наконец, работающая точка завершения показывает в новом соединении, какой сертификат она действительно использует.

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

Представим парк сертификатов, получивший окно длиной 24 часа. Центр разумно использовал глобальную картину: отвёл работу от будущего пика и оставил клиентам пространство для распределения. Но при следующем общем пробуждении планировщиков график поднимается стеной.

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

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

Каталог публикует источник рекомендации

ACME-сервер с поддержкой ARI добавляет URL renewalInfo в объект каталога. Для сертификата клиент строит воспроизводимый идентификатор: кодирует в base64url keyIdentifier из Authority Key Identifier, ставит точку и кодирует в base64url DER-байты серийного номера, удаляя конечное заполнение. Затем выполняет неаутентифицированный GET.

Так независимые реализации называют один сертификат одинаково. Но ответ не становится командой на развёртывание.

Объект RenewalInfo обязан содержать suggestedWindow.start и suggestedWindow.end. Они ограничивают период, в котором центр рекомендует попытку продления. Необязательный explanationURL может объяснить динамическое распределение нагрузки или подготовку к массовому отзыву.

Нужно сохранить три смысловые границы.

Окно не является сроком действия X.509 и не меняет notBefore или notAfter. Это не ответ CRL или OCSP о статусе отзыва. И наличие ресурса не доказывает, что клиент прочитал его, принял данные или начал заказ.

Центр может поместить всё окно в прошлое, рекомендуя немедленное действие. Клиент с отстающими часами ещё увидит его в будущем. Клиент без ARI не увидит вовсе. Глобальное знание улучшает сигнал, но не создаёт локального принятия.

Клиент выбирает момент и хранит выбор

RFC 9773 рекомендует равномерно выбрать случайный момент внутри окна. Если он уже прошёл, клиент пытается продлить сразу. Если клиент умеет запланировать точное пробуждение, он ждёт. Если выбор находится до следующего обычного запуска, действует сейчас. Иначе ждёт следующей проверки RenewalInfo и оценивает ситуацию снова.

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

Но случайный выбор сам по себе не гарантирует гладкого распределения. Момент должен переживать перезапуск. Иначе клиент может выбирать заново при каждом пробуждении, пока не получит удобное значение. Клонированные экземпляры не должны иметь одинаковое псевдослучайное состояние. Грубое часовое разрешение способно сжать широкое окно в несколько точек. Верхнеуровневая задача парка не должна заменять решения по сертификатам одним запуском.

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

Окно с end, равным или меньшим start, недействительно. Клиент рассматривает его как непригодный ответ и следует повторной проверке или локальному резервному графику. Ожидаемый источник не даёт противоречивым данным права на исполнение.

Retry-After управляет повторным наблюдением

В ARI Retry-After выражает желательный интервал до следующего чтения RenewalInfo — запрошенные минимум и максимум одновременно, с разумными местными границами и приоритетом отката ошибок.

Она не назначает время заказа сертификата.

Получив Retry-After: 21600, клиент узнаёт шестичасовой ритм обновления информации. Выбранный внутри окна момент продления остаётся другой величиной. Смешение двух часов не позволяет отличить намеренное ожидание от устаревшего совета.

Тайм-ауты соединения и запроса, а также ответы 5xx — временные ошибки; клиент применяет экспоненциальный откат с ограниченным числом попыток. После их исчерпания или при долговременной ошибке — отсутствующем или неверном Retry-After, неправильном объекте, сбое DNS, отказе соединения или ошибке не-5xx — он возвращается через шесть часов либо через местный эквивалент.

Let’s Encrypt рекомендует на практике проверять ARI для каждого сертификата не реже двух раз в день и сохранять резервное правило по оставшемуся сроку. Это рекомендация конкретного центра, а не универсальное число RFC 9773. Учёт должен показывать, что пришло из стандарта, что — из политики центра, а что — от оператора.

replaces задаёт происхождение выпуска

ARI добавляет к заказу необязательное поле replaces. Оно использует тот же идентификатор и объявляет, какой предыдущий сертификат должен сменить новый заказ.

Такое происхождение полезно. Центр распознаёт продление, применяет приоритет или лимиты по своей политике и отслеживает преемника сертификата, затронутого инцидентом. Сервер проверяет связь счёта и идентификаторов. Если другой не недействительный заказ уже отметил предшественника заменённым, сервер отвечает HTTP 409 с alreadyReplaced.

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

Даже слово «заменён» в системе центра нужно читать в значении ACME: признана последовательность заказов. Распространить его на инфраструктуру подписчика, которую центр не видит, значит превратить полезную запись в ложную гарантию.

valid не загружает сертификат в сервис

Выпуск по-прежнему регулирует RFC 8555. Клиент создаёт заказ, при необходимости выполняет авторизации идентификаторов, отправляет CSR на finalize URL, ждёт выпуска и скачивает сертификат по URL в заказе.

ready означает, что требования выполнены и ожидается финализация. processing говорит о выпуске. valid означает, что центр выпустил сертификат и предоставил URL. Успешное скачивание доказывает получение байтов.

Ни один этап не активирует их в сервисе.

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

Объяснимому состоянию нужны отдельные переходы:

  1. RenewalInfo получен и проверен;
  2. момент выбран и сохранён;
  3. заказ создан с происхождением предшественника;
  4. авторизация и финализация завершены;
  5. сертификат скачан, отпечаток рассчитан, ключ проверен;
  6. артефакт доставлен названным целям;
  7. конфигурация проверена, процесс перезагружен;
  8. новое локальное соединение показывает ожидаемый отпечаток;
  9. внешнее наблюдение охватывает нужные пути;
  10. старый материал удалён после ограниченного периода восстановления.

Булево «продлён» не упрощает цепочку. Оно стирает место сбоя.

CT освещает выпуск, но не активную границу

RFC 9162 описывает публичные журналы выпущенных или наблюдавшихся серверных TLS-сертификатов. Certificate Transparency помогает проверять действия центров, находить неожиданный выпуск и контролировать добавочный характер журналов.

Запись CT — сильное доказательство выпуска или подачи в журнал. Это не доказательство развёртывания.

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

Правильный вывод: сертификат или предсертификат вошёл в механизм прозрачности по его правилам. Чтобы сказать, что публичный сервис его показывает, нужно наблюдать сервис.

Новое TLS-рукопожатие ближе к рабочему факту

При аутентификации сертификатом в TLS 1.3 сервер отправляет цепочку в Certificate, доказывает владение ключом через CertificateVerify и завершает аутентифицированную стенограмму сообщением Finished.

Поэтому новое соединение без прежнего состояния показывает отпечаток, который конкретная точка предъявляет в данный момент. Его надо сравнить со скачанным результатом и повторить проверку по семействам адресов, регионам, именам SNI, уровням завершения и важным маршрутам.

Доказательство остаётся ограниченным. Актуальный IPv4-путь не доказывает IPv6. Один anycast-узел не доказывает все. Внутренняя проверка может завершаться до публичного слоя. Возобновлённая сессия может не дать нужного полного обмена.

«Во время T точка E показала отпечаток F по пути P в новом рукопожатии» — проверяемое утверждение. «Развёрнуто глобально» требует плана наблюдения, действительно покрывающего глобальный охват.

Причинный журнал для каждого сертификата

Отдельно, но связанно следует хранить:

  • идентификатор ARI, ACME-каталог и последнюю успешную проверку;
  • начало и конец окна, объяснение, отпечаток ответа и Retry-After;
  • выбранный момент, способ, смещение часов, разрешение и сохранение;
  • резервный порог, ошибки, последнюю ошибку и следующую разрешённую попытку;
  • предшественника, счёт, URL заказа и результат replaces;
  • время авторизации, финализации, выпуска и скачивания;
  • отпечаток, цепочку, соответствие ключа и место хранения;
  • цели, проверки, перезагрузки и состояние возврата;
  • новые рукопожатия по регионам, семействам адресов и уровням завершения;
  • вывод предшественника и доказательство, разрешившее вывод.

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

Центр сообщает рекомендацию и выпуск. Клиент сообщает выбор и заказ. Развёртывание сообщает хранение и перезагрузку. Точка показывает сертификат. Наблюдатель сообщает маршрут. Ни одному слою не нужно заимствовать уверенность следующего.

Работающая система завершает замену

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

Общий слой ARI узок: объявить ресурс, идентифицировать сертификат, выразить окно, сообщить ритм проверки и назвать предшественника. Он не централизует график подписчика и не объявляет сервис изменившимся.

Локальное решение остаётся во времени, откате и резервном плане. Добровольное принятие видно в том, реализует ли клиент ARI и как его встраивает. Приоритет работающей системы проявляется в конце: новый сертификат становится фактом сервиса, когда активные точки его предъявляют.

Центр управляет окном, не всеми часами. Клиент управляет попыткой, не выпуском. Развёртывание управляет установкой, не всеми путями. Проверка управляет своим наблюдением, не всем парком.

Такое разделение не ослабляет автоматизацию. Оно делает её измеримой, останавливаемой и обратимой.

Источники