OpenVPN 証明書の更新：タイマーではなく証明書を届ける

二つの更新設計は設計レビューでは同じに見え、一月にはまったく違う振る舞いをする。一つ目はタイマーを回し、証明書を再発行し、ファイルを共有フォルダに放り込む。二つ目は更新を配送の問題として扱う：誰が求め、何が適格性を証明し、素材がどう端末に届き、何がクライアントにそれを使わせるのか。オフラインのノートPC、廃棄済みの資産、そして静かに失敗した配送に耐えるのは二つ目だけだ。

二つの設計が本当に違うところで比べる

タイマー型の設計はサーバ側を最適化する。スケジュールされたタスクが CA を呼び、新しい証明書が現れ、運用者は作業が終わったとみなす。発行後に起きることはすべて他人の問題で、端末が接続できなくなり、有効期限が理由を説明するまで続く。

ワークフロー型の設計はラストマイルを最適化する。発行は連鎖の一環であり、その後の各段階は独立して失敗しうると仮定する。構築には金がかかり、運用はずっと安く済むのは、失敗が期限切れのクライアントとしてではなく、追跡される状態として現れるからだ。

違いを見失わないための有用な方法は、各設計が明示的に名指ししなければならない順序だ。

detect window -> authenticate request -> authorize -> issue
-> deliver and stage -> activate -> verify fresh auth -> retire old material

証明書そのものから更新の窓を検出する

有効期間は、クライアントが実際に提示している証明書から読み、コピーしたファイル名に埋め込まれた日付からは読まない。ファイル名はずれるし、2026 と書かれたファイルが三月に切れる資格情報を抱えていることもある。

遅いケースのために窓に余裕を残す：何週間もオフラインの端末、人を必要とする承認、動く前に一度は失敗する配送経路だ。成功を報告するタイマーは、タイマーが動いたことしか証明しない。

何かを発行する前に要求を認可する

既存の証明書は正当な更新機構の一部になりうるが、そのサブジェクト文字列は認可の判断ではない。答えるべき問いは、このアカウントとこの端末がまだフリート内の身元を持つ資格があるかどうかであり、その答えは証明書ではなく資産台帳に住んでいる。

スケジュールされたタスクがまだ動いている廃棄済みのノートPCに、新しい権利を与えるべきではない。 RFC 7030 ここで読む価値があるのは、認証済みの再登録をサーバ側の認可とポリシーから切り離している点であり、それは借りるべきモデルであって、OpenVPN や EasyRSA がそのプロトコルを提供するという主張ではない。

配送、配置、有効化を別々の段階として扱う

発行は身元、目的、発行関係を保ち、新しい鍵ペアで作った代替品は、対応する鍵が一緒に運ばれなければ役に立たない。ペアは、推測できない URL は制御ではなく秘匿にすぎないという理由から、アクセス制御の設計を背後に持つ経路で届ける。

配置は、ほとんどの自動化が静かに壊れる場所だ。インポートしたプロファイルが一つの場所にあり、管理者が別の場所でファイルを更新し、クライアントは誰かが気づくまで古い証明書を提示し続ける。クライアントが読むパス、そこに書き込めるアカウント、再読み込みを起こすイベントを書き留める。そのうえで、代替品が横に届いたコピーではなく、実際に使われているファイルであることを確かめる。

検証とは、新しい素材での新しい認証と、利用者が必要とするアプリケーションの確認だ。すでに確立したトンネルは前の資格情報を反映したままかもしれないので、開いている接続は更新成功の証拠にならない。

逃した窓の復旧を先に設計する

ノートPC が VPN 経由でしか登録サービスに届かない場合、期限切れは循環を生む：端末はトンネルに入るために証明書を必要とし、トンネルは証明書を取るために必要だ。最初のスケジュールタスクを出す前に、別途認証された登録エンドポイントであれ、管理者支援の再登録であれ、帯域外の取り決めを決める。

何を選ぶにせよ、要求者と現在の権利を検証しなければならない。求めれば誰にでも期限切れの証明書を受け付けるようサーバを設定するのは復旧経路ではなく、設計の残りで守ってきた検査を恒久的に弱めることだ。

最後に、更新と侵害を別々の手順に保つ。漏れた鍵には失効とアクティブなセッションへの対応が必要で、有効期限を延ばすことにはそのどれも含まれない。オフラインの端末、失敗した配送、廃棄済みの資産を受け入れテストに入れれば、スケジュールは有効化できる。