要約

  • RFC 9811の通常のCMP-over-HTTP交換では、HTTP要求が成功すると200 OKでCMP応答を返す。外側の成功は、内側のPKIStatusが示す受理、条件変更、拒否、待機を代行しない。
  • 証明書自動化の記録は、宛先、HTTP、保護されたPKIMessage、transactionID、ポーリング、確認、鍵ストア、依存システムの検証を結び付けつつ、それぞれの意味を分離しなければならない。

証明書運用を誤らせるのは、赤い失敗とは限らない。過剰な権限を与えられた200 OKであることも多い。

RFC 9811は、2025年7月にIETF標準化過程のRFCとして公開され、Certificate Management ProtocolをHTTPで転送する方式を定めた。DERで符号化したPKIMessageをPOSTの本文に置き、application/pkixcmpを指定する。通常の要求がHTTPレベルで成功した場合、サーバーはCMP応答を本文に入れて200を返す。他の成功2xxをこの用途に使ってはならない。

この厳密さはHTTPの権限を広げない。外側の受領証を一つに定め、内側のプロトコルに判断を残す。

一つの応答に二つの結果

RFC 9810にはCMPの状態としてaccepted、grantedWithMods、rejection、waitingなどがある。したがってHTTP 200は、要求どおりの許可、変更付きの許可、拒否、未完了の処理のいずれも運び得る。HTTP成功率だけでは、次に何をすべきか決められない。

逆に、4xxや5xxだから本文を捨てる実装も重要な証拠を失う。RFC 9811は、2xx、4xx、5xxの応答本文にCMPの応答PKIMessageが含まれる場合を処理できるよう求める。外側のエラーと、認証・関連付け可能な内側の説明は同時に存在できる。

処理は段階的である。HTTP応答を受け、媒体型と大きさを確認し、DERを解析し、CMP保護と送信者を検証し、正しい取引に関連付け、その後で本文の型、状態、失敗情報を読む。前段の成功は、次段を検査する資格であって、全体の完了証明ではない。

応答がないときに残るもの

RFC 9811は、HTTP応答によって受領が確認できなければ、CMPメッセージは宛先へ正常配送されなかったものと仮定するよう定める。これは配送を根拠なく主張しないための安全な規則である。ただし、サーバー内部で何も起きなかったことまでは観測していない。

サーバーが要求を読み、状態を作った後で接続が切れることもある。クライアントから見れば配送未確認だが、認証局には取引が残っているかもしれない。新しい識別子で即時再送すれば重複を生み、再送しなければ更新を完了できない可能性がある。

必要なのは、元のtransactionID、要求本文のハッシュ、対象CA/RA、操作種別、時刻境界を保った照合である。CMPが継続やポーリングを許すなら、それを使う。状態を判定できないなら「不明」として扱い、別取引で覆い隠さない。

ステートレスな運搬、ステートフルな取引

一部のPKI管理操作は複数の要求・応答対から成る。HTTPの各往復が独立していても、CMPのtransactionIDが同じ操作に結び付ける。RFC 9810では、一度値が確立したら後続メッセージにも同じ値を設定し、同一クライアントが同一サーバーに対して同じ識別子の取引を複数同時に進めないよう求める。

クライアント生成時には128ビットの擬似乱数が推奨される。サーバーは認識能力に応じて{client, transactionID}または識別子単独の一意性を求め、正しく関連付けられない衝突にはtransactionIdInUseを返す。

しかし、追跡番号は身分証ではない。transactionIDだけでは、送信者、権限、完全性、証明書プロファイルの許可、業務上の冪等性を証明できない。CMP保護、nonce、要求識別子、ローカル方針が別の権限を担う。監査記録はそれらを連結すべきだが、同一視してはならない。

waitingは別の時計を持つ

waitingは、HTTPが完了しても業務判断が完了しないことを明示する。要求本文がまだ処理されていないため、クライアントはpollReqを送る。CAまたはRAは、完了していれば最終応答を、未完了ならcheckAfterを含むpollRepを返す。次の照会まで少なくとも指定秒数を待つ。

遅延原因には、バックエンド負荷、PKI管理主体間のオフライン転送、RA担当者の承認がある。ネットワーク往復が閉じた後に、人や組織の決定が残る。

自動化は、待機の所有者、次回照会可能時刻、累積時間、失効までの余裕、エスカレーション条件を保存する必要がある。checkAfterより早い連打は承認を速めず、むしろ不足する能力を消費する。待機を拒否とみなせば二重申請を生み、受理とみなせば存在しない証明書で完了扱いになる。

証明書が返っても終わらない場合

RFC 9810は、受け取った証明書をクライアントが受理または拒否するcertConfと、それに応答するpkiconfを定める。CAが要求項目を変更したなら、実際の証明書を検査しなければならない。grantedWithModsは無条件インストールの許可ではない。

証拠は、保護された応答と状態、証明書指紋、要求との差、クライアント確認、プロトコル終了、鍵ストアへの書込み、サービスの読込み、依存側の検証に分かれる。同じ指紋で結び付けられても、全工程の実行を自動証明しない。

発行台帳に証明書があっても、ロードバランサーは旧証明書を提示しているかもしれない。導入ツールが成功しても、重要なクライアントは名前、用途、チェーン、有効期間を拒否するかもしれない。一方、サービスが動作していても、確認記録が失われている可能性がある。実行状態とプロトコル閉鎖には別々の受領証が要る。

プッシュ通知には201と202の意味がある

CA鍵更新、証明書、失効、CRLの通知をプッシュする場合、CMPサーバーはHTTPクライアントとして動き、受信側はCMP応答を返さない。空のHTTP応答だけを返す。

201 Createdは情報が保存済み、または既に存在したことを示す。202 Acceptedは後続処理に受け入れただけである。送信者は待機後に再送し、処理済みの確認を得ることができる。この意味を、200がCMP判断を運ぶ通常の要求応答へ持ち込んではならない。

通知の応答が適切に保護・認証されないなら、その処理状態は信頼できず、PKI全体も確実な受領に依存してはならない。番号の意味は、発信者と保護の証拠に支えられて初めて成立する。

/.well-known/cmpは経路であって権限ではない

相互運用のため、HTTPまたはHTTPS対応CMPサーバーは/.well-known/cmpを支える。後続パスで操作、CA、証明書プロファイルを区別できる。IANA Well-Known URIsレジストリはcmpをIETF管理の恒久的な接尾辞として掲載する。

共通パスは、正しいホスト名を発見しない。RFC 8615もホスト選択を定めず、well-known位置がorigin全体の制御面になる点を警告する。設定元、名前解決、リダイレクト、TLS相手、保護されたCMP送信者、ローカル信頼方針を保存して一致を検査する必要がある。

RFC 9811は3xx対応を許すが、自動追従には慎重さを求める。悪意ある301の永続化は、正しいサーバーへの接続を長期に遮断し得る。HTTPの利便性がPKIの権限点を書き換えてはならない。

一つの真偽値ではなく、引継ぎの台帳

最低限の台帳には、予定CA/RA、設定URIと最終URI、リダイレクト、TLS相手、HTTP方式・状態・媒体型・本文ハッシュ、CMPの送受信者・型・保護検証、transactionID・nonce・要求番号、PKIStatus・失敗情報・checkAfter、証明書指紋・要求との差・確認状態、鍵ストア版、起動結果、ロールバック、重要な依存サービスからの観測を残す。

「不明」を消してはならない。応答なしは配送未確認、200は応答受領、発行は証明書生成、導入はローカル状態変更、接続成功は一つの依存側の受理である。各段階には、その段階を所有する主体の証拠が必要だ。

この区別は障害対応の担当も変える。HTTP 5xxを見てWeb基盤だけの問題と決め付けると、本文に含まれた検証可能なCMPエラーを証明書担当へ渡せない。反対にHTTP 200だけで基盤担当が作業を閉じると、waitingを生んだRA承認待ちが見えなくなる。すべてを支配する中央画面よりも、各状態を決める主体へ証拠を正しく引き渡す仕組みの方が強い。

ベンダー移行にも同じ台帳が要る。旧製品が「成功・失敗」と最終証明書しか輸出できなければ、新製品は、どの200が拒否を運び、どの待機が期限切れで、どの確認が未完了かを再構成できない。元メッセージのハッシュ、取引識別子、状態の時系列、証明書指紋、保護検証結果は、特定製品の画面から独立して保存すべきである。退出可能性は付加的な管理機能ではなく、プロトコル履歴をロックイン資産にしないための技術要件だ。

暗号化された運搬とメッセージの真正性も互いを代行しない。HTTPSは通信路とTLS終端を保護でき、CMP保護はプロトコルメッセージを検証できる。両方に成功しても、ローカル証明書方針が申請を許すとは限らない。方針が許しても、依存側が最終証明書を受理するとは限らない。四つの判定を並べて残せば、一つの制御が失敗したとき、他の制御が実際に何を補ったか説明できる。

Running-Code Primacyの検査対象は、実際のクライアント、CA/RA状態、鍵ストア、依存通信である。Minimum Initial Specification, Localized Future Decision, and Voluntary Adoptionは、共通層を方式、バイト列、識別、関連付け、安全性に限定し、証明書方針と導入判断をローカルに残す。Reality Layersは、複数の真実を一つの緑色へ圧縮しないための規律になる。

RFC 9811が200 OKを弱めたのではない。意味を正確にした。HTTP要求は成功し、CMP応答は届いた。証明書の判断は、まだその中にある。

情報源