要約

  • RFC 9773は、認証局が更新を試みる時間帯を提案し、新しい注文がどの証明書を置き換えるかを示す仕組みを定める。実際の時刻選択、失敗時の待機、ACMEによる発行、配備と切り戻しはクライアント側の責任として残る。
  • suggestedWindow、replacesを受理した注文、valid状態、証明書の取得、CTログ、配備先のファイル、外部から観測したTLSハンドシェイクは、それぞれ別の事実である。前の事実だけで次の状態を完了扱いにしてはならない。

二十四時間の幅が午前二時に集まる

ある証明書群に、丸一日の推奨更新時間帯が届いたとする。認証局は全体の発行需要を見ながら、将来の集中を避けるように仕事を広げた。ところが翌日の監視画面では、午前二時に更新要求がほぼ垂直に立ち上がる。

原因は一つとは限らない。クライアントが選んだ時刻を粗い定期実行の境界へ丸めたかもしれない。正確な時刻まで待てない実装が「次の通常起動より前」を即時実行と解釈した可能性もある。再起動で選択済み時刻や失敗回数を失った個体、時計が進んだ個体、全証明書を一つの配備ジョブへ束ねた管理系も考えられる。

これは特定の事故を示すものではない。ARIの時間帯が、現場でどのように別の意味へ変わり得るかを確認するための運用上の思考実験である。

認証局は、発行基盤全体の混雑や、早期置換を要するインシデントを把握できる。クライアントは自分の起動周期、保守時間、時計、過去の失敗を知る。ACMEサーバーは注文の発行可否を判断する。配備系は証明書と秘密鍵の保管先、設定検査、プロセス再読込、切り戻しを管理する。サービスの終端は、その瞬間に読み込まれている証明書をTLSで提示する。

どの主体も、隣の主体が持つ事実を完全には知れない。RFC 9773が優れているのは、この不完全さを隠さず、認証局の役割を有用だが狭い調整信号として定義した点にある。

ディレクトリが公開するのは助言の入口

ARIを提供するACMEサーバーは、ディレクトリオブジェクトにrenewalInfoのURLを載せる。クライアントは対象証明書を識別するパスを付け、認証を伴わないGETで情報を取得する。

識別子は運用データベースの番号ではない。証明書のAuthority Key Identifierに含まれるkeyIdentifierと、DERで表現されたシリアル番号のバイト列をそれぞれbase64urlで符号化し、末尾のパディングを除き、ピリオドで連結する。異なる実装が同じ証明書から同じ対象を導けることが重要である。

応答にはstartとendを持つsuggestedWindowが必須となる。これは認証局が更新を試みてほしい範囲である。任意のexplanationURLは、負荷分散や大規模な失効対応など、時間帯を変更した理由を運用者へ示すために使える。

ここで三つの誤読を避けなければならない。

第一に、この時間帯はX.509証明書の有効期間ではない。notBeforeとnotAfterを書き換えない。第二に、失効状態を返すCRLやOCSPではない。過去の時間帯を返して早急な更新を促しても、その応答自体が旧証明書を失効させるわけではない。第三に、応答が存在しても、クライアントがそれを取得したこと、採用したこと、注文を作ったことは証明されない。

助言の出所を標準化することと、助言の実行を中央集権化することは別である。

一つの時刻を選ぶのはクライアント

RFC 9773が推奨する方法では、クライアントは時間帯の中から一様な確率で一時点を選ぶ。選んだ時刻が既に過ぎていれば直ちに更新を試みる。正確に起動できるならその時刻まで待つ。選択時刻が次の通常起動より前なら現在の起動で処理する。それ以外は、次に更新情報を確認すべき時刻まで待ち、再評価する。

認証局が証明書ごとに一つの予約時刻を割り当てないことには意味がある。認証局には、個々のクライアントがその時刻に起動できるか、現地の保守規則が許すか、失敗後にどの程度待つべきかまでは分からない。時間帯は、全体を調整しながら局所の実行権を残す形式である。

ただし、乱数を一度使えば分散が保証されるわけではない。選択した時刻を保持せず、起動のたびに引き直せば、実行に都合のよい値へ漂う。多数の複製環境が同じ乱数状態を持つ、分単位の粗い時刻しか扱えない、あるいは上位のジョブ管理が全対象を一括処理する場合も集中が起きる。

定期実行型のクライアントには、失敗状態の永続化も必要になる。確認頻度だけを上げ、注文ごとの失敗回数や直近の失敗時刻を保存しなければ、本来のバックオフを毎回忘れてしまう。頻繁に目を覚ます能力が、頻繁に同じ失敗を繰り返す権利へ変わってはならない。

endがstart以前の時間帯は無効である。クライアントは利用可能な応答を得られなかったものとして、適切な再確認またはローカルの予備日程へ移る。期待した認証局から返ったというだけで、矛盾した時間帯を実行してはならない。

Retry-Afterと更新時刻を混ぜない

ARIにおけるRetry-Afterは、一般的なHTTPの印象とは少し異なる。これはRenewalInfoを次に取得するまでの望ましい間隔であり、要求される最短と最長の双方を表す。証明書注文そのものを何秒後に開始せよ、という指定ではない。

例えばRetry-After: 21600を受け入れたクライアントが証明するのは、六時間後を目安に情報を更新するということだけである。時間帯の中で選んだ更新時刻は別に保存されるべきだ。

一時的な接続失敗、タイムアウト、5xx応答には、回数上限を持つ指数バックオフが優先する。Retry-Afterが欠ける、値が不正、RenewalInfoオブジェクトが無効、DNS解決に失敗、接続拒否、非5xxのエラーといった長期的な失敗では、六時間後またはローカル既定値で再確認する。

運用データには少なくとも、情報を再取得する時刻、更新を試す時刻、ACME注文を再試行できる時刻の三つが必要になる。すべてを一つの「次回実行」に入れると、遅延が認証局の提案、クライアントの選択、情報取得の障害、発行処理の失敗のどれから生じたのか説明できない。

Let’s Encryptは運用ガイドで、各証明書について少なくとも一日二回ARIを確認し、残存有効期間に基づく予備条件も維持するよう勧めている。これは具体的な認証局による実務上の助言であり、すべてのARI実装に固定された値ではない。標準、認証局方針、ローカル方針は記録上も分ける必要がある。

replacesが示すのは発行上の前後関係

ARIはACMEの注文に任意のreplacesフィールドを加える。RenewalInfoと同じ証明書識別子を使い、新しい注文がどの旧証明書を置き換える意図を持つかを示す。

この関係により、認証局は更新として扱える注文を判別し、推奨時間帯内の注文へ自らの方針に沿った優先度やレート制限上の扱いを与えられる。問題のある証明書に後継が現れたかを追跡する用途もある。既に別の無効でない注文が旧証明書を置換済みとした場合、サーバーはHTTP 409とalreadyReplacedを返す。

それでも、replacesは配備確認ではない。受理されても、新証明書が取得されたか、秘密鍵と一致したか、ロードバランサーへ届いたか、プロセスが再読込したか、旧証明書の提示が止まったかは分からない。

認証局の「置換済み」は、ACME注文の系譜として読まなければならない。認証局が観測できない加入者設備の状態まで証明したことにすると、便利な発行情報が誤った運用権限へ拡大される。

validの先に長い距離がある

証明書の発行はRFC 8555のACME手順に従う。クライアントは新しい注文を作り、必要な識別子の認可を満たし、CSRをfinalize URLへ送る。サーバーが発行を進め、注文がvalidになればcertificate URLから証明書を取得できる。

readyは発行条件を満たし最終化を待つ状態、processingは発行中、validは証明書が発行され取得先が用意された状態である。取得成功は証明書のバイト列を受け取ったことを示す。

いずれも、サービスへの反映を意味しない。

取得後には、保存権限、秘密鍵との照合、チェーンの組み立て、配備先への伝送、設定検査、プロセス再読込、既存接続の扱い、各地域への展開、失敗時の復元がある。管理画面上の発行が完了しても、古いワーカープロセスが動き続けることはある。新しいファイルがあっても、プロセスが開き直さなければ提示証明書は変わらない。

したがって、運用状態は次のように段階化すべきである。

  1. RenewalInfoを取得し、内容を検証した。
  2. 更新時刻を選び、再起動後も残る形で保存した。
  3. 旧証明書を示す注文を作成した。
  4. 認可と最終化を終えた。
  5. 新証明書を取得し、指紋と秘密鍵一致を確認した。
  6. 指定した配備先へ送った。
  7. 設定検査と再読込に成功した。
  8. ローカルの新規TLS接続が新しい指紋を提示した。
  9. 必要な外部経路と地域で同じ事実を観測した。
  10. 有界な復旧期間の後に旧材料を廃止した。

「更新済み」という一つの真偽値は、この連鎖の途中にある失敗を説明できない。

CTは発行を照らすが、終端を巡回しない

Certificate Transparencyは重要な監査面である。RFC 9162は、発行または観測された公開TLS証明書を追記型ログへ記録し、認証局の行為や予期しない発行を監視できるようにする。

CTへの記録は強い証拠だが、配備の証拠ではない。加入者が取得する前に証明書やプレ証明書が提出されることも、第三者がチェーンを提出することもある。ログは各サービス終端へ接続せず、どのロードバランサーが対応する秘密鍵を持つかも判定しない。

CTから言えるのは、その証明書またはプレ証明書がログの規則に従って提出・記録されたことまでである。実サービスがそれを提示している、という結論には別の観測が必要になる。

新しいTLS接続が示すもの

TLS 1.3で証明書認証を行うサーバーは、Certificateメッセージで証明書チェーンを送り、CertificateVerifyで対応する秘密鍵の所持を示し、Finishedでハンドシェイクを確定する。

そのため、対象終端への新しい接続で提示されたリーフ証明書の指紋を確認すれば、その時点のその経路については配備に近い証拠を得られる。ACMEで取得した指紋、発行者、識別子、有効期間と比較し、IPv4とIPv6、地域、SNI、TLS終端層ごとに観測する。

ただし一回の成功を全体へ拡張してはならない。一つのAnycast拠点だけが更新された可能性がある。IPv4は新しくIPv6は古いかもしれない。セッション再開では証明書交換を十分に観測できない。内部監視が公開トラフィックとは異なる終端へ接続している場合もある。

「時刻T、経路P、終端Eの新規ハンドシェイクで指紋Fを確認した」は範囲の明確な事実である。「全世界で配備済み」は、対象範囲を支える観測計画がなければ成立しない。

証拠を因果順に並べる

一枚の証明書について、次の事実を関連付けながら別々に残す。

  • 証明書識別子、ACMEディレクトリ、最終RenewalInfo取得時刻
  • start、end、説明URL、応答指紋、Retry-After
  • 選択時刻、選択方法、時計のずれ、スケジューラの粒度、永続化結果
  • 予備更新条件、失敗回数、直近失敗、次回試行可能時刻
  • 旧証明書識別子、ACMEアカウント、注文URL、replacesの結果
  • 認可、最終化、valid到達、取得の各時刻
  • 新証明書指紋、チェーン、秘密鍵一致、保管先
  • 配備対象、設定検査、再読込、切り戻し状態
  • 経路、地域、アドレスファミリー別の新規ハンドシェイク
  • 旧材料を廃止した時刻と、その判断を支える収束証拠

秘密鍵、完全なアカウント資格情報、無制限の内部構成を分析面へ出す必要はない。指紋、管理された対象識別子、責任者付きの操作記録によって、秘密の保管範囲を広げずに因果関係を示せる。

認証局は助言と発行を、クライアントは選択と注文を、配備系はファイルと再読込を、終端は実際の証明書を、観測者は特定経路の握手を報告する。前の主体が次の主体の権限を借りなければ、障害位置は明確になる。

実装と運用が最後の文を完成させる

インターネットの調整文書は、公開された瞬間に運用現実を作るものではない。共通部分を狭く定義し、参加者が実装し、局所的に検証し、実際に採用して初めて効果が生まれる。

ARIの共通部分は、情報資源の広告、証明書識別、推奨時間帯、再確認間隔、前後関係という最小限に保たれている。加入者の配備時刻を直接支配せず、サービス変更を宣言しない。

将来の局所判断は、クライアントの時刻選択、バックオフ、予備条件に現れる。自発的な採用は、クライアントがARIを実装し、自らの更新系へどう組み込むかに現れる。稼働する実装の優位は最後に現れる。新証明書がサービスの事実になるのは、稼働中の終端がそれを提示したときである。

認証局は時間帯を管理できるが、各クライアントの時計を所有しない。クライアントは試行時刻を選べるが、発行を決定しない。配備系はファイルを置けるが、全経路の収束を単独では証明しない。観測者は一つの経路を証明できるが、それを全体へ自動的に拡張できない。

責任を細分化するのではない。責任を、実際に知り得る事実の範囲へ戻すのである。

出典