VPN 証明書が今日失効します：実際に何が止まるのか

失効アラートが鳴っても、トンネルはまだ通信を通しており、日付が重要かどうかで意見が割れます。重要ですが、証明書に印字された瞬間とは限りません。失効した証明書は新しい認証を止め、長寿命セッションの内部で一部の実装が行う再検証も止めます。既存のトンネルが真夜中に切れるかどうかは、プロトコル、クライアント、サーバーの再ネゴシエーション設定に依存します。日付の前に更新を計画し、すでに開いていたセッションではなく新しいログインで検証してください。

どの証明書が実際に失効するのかを特定する

配備にはサーバーのリーフ証明書、クライアント資格情報、一つ以上の中間証明書、トラストアンカーが含まれ、これらは同時に失効しません。エラーで示された証明書と、それが提示されたチェーンを読み、プロファイルディレクトリの最初のファイルを読まないでください。きれいに更新されるサーバーのリーフでも、上位の中間証明書が失効していれば失敗します。何かを変更する前に、各ファイルのサブジェクト、発行者、not-after、配備場所を書き留めてください。

トラストアンカーは通常、最も寿命が長い対象であり、原因である可能性が最も低いものです。

稼働中のセッションが日付を超えて生き残る理由

認証は接続の確立時に行われ、一部のプロトコルは後から識別情報を再確認します。OpenVPN はタイマーでデータチャネルを再ネゴシエーションするため、失効した証明書を提示する再ネゴシエーションは、トンネルが何時間も稼働していても失敗します。再検証を一切行わない実装は、確立済みのセッションを失効日より先に運ぶことがあり、だからこそ「まだ動いている」は証拠になりません。どちらの挙動も見込んで計画できるものではありません。

日付は新しいログインの期限、セッションの寿命は借り物の時間と考えてください。

証明書を責める前に時計を確認する

有効性はローカルの時計に対して評価されるため、時刻が誤った端末は完全に最新の証明書に対しても有効性エラーを報告します。クライアント、サーバー、経路上のあらゆる機器を確認してください。

起動時にリセットされる時計は、停電の後にだけ現れる障害を説明します。

発行した機関を通じて更新する

身元、想定された用途、互換性のある鍵設定を維持してください。更新が新しい発行者やピン留めされた証明書を持ち込む場合、クライアントにはサーバーのファイル差し替えではなく、調整された信頼の更新が必要です。発行と配布の間は秘密鍵を保護してください。更新された証明書は侵害された古い鍵を取り消さないからです。パスワードのリセットは、チケットが何と言おうと更新ではありません。

新しいチェーンは、中間証明書のないリーフがすでにキャッシュしたマシンでしか機能しない半分の更新になるため、完全に公開してください。

新しいログインで証明し、切り戻しを用意する

配備後、代表的なクライアントから新しい許可された接続を確立し、実際のアプリケーションを試してください。チェーンがクライアントの期待どおりに配信され、失効情報に到達できることを確認します。失効した素材への信頼に依存しない切り戻しを用意し、検証を弱めずに以前の状態へ戻れるようにしてください。古いファイルは置き換えが検証されてから削除します。

既存のセッションは以前の状態を反映している可能性があるため、どちらの方向にも何も証明しません。

当日に私が使う順序

失効する対象とそのチェーンを確認し、次に時計を確認します：

• どの証明書が失効し、どのチェーンに属するか。
• すべての中間証明書が配備され公開されているか。
• クライアントとサーバーの時計が妥当な範囲で一致しているか。
• 代表的なクライアントから新しいログインが成功するか。
• 失効情報に到達できるか。
• 検証を弱めない切り戻しが存在するか。

その後で更新し、チェーン全体を配備し、新しいログインでテストし、最後に片付けてください。有効期間とその評価ルールは RFC 5280 で定義されており、実際に失効する対象を監視していれば、日付は驚きではありません。