失効したクライアントが今も接続する：リストは届かなかった

失効が稼働中のトンネルに入り込んでセッションを削除することはありません。リストは証明書検証への入力であり、TLSセッションを開始する制御チャネルの交換中に参照されます。この一つの事実が二つの驚きを説明します：失効したクライアントが再接続するのはリストが検証側に届かなかったからであり、既存のセッションが生き残るのは、誰も何も再検証しなかったからです。

リストは入力であり、動作ではない

セッションを確立するとき、サーバーはクライアント証明書を自身の信頼アンカーに対して検証し、失効の指示はその判断にリスト検索を加えます。検証はサーバー側で行われるため、クライアントは自分の証明書が失効したことを知れず、同じ証明書を出し続けます。したがって、まだ接続できるプロファイルが示すのは、どこかの検証者がチェーンを受け入れたということであり、失効が失敗したということではありません。

リスト自体が発行日と次回更新日を持つ署名済みのオブジェクトです。無関係なリスト、別の機関が署名したリスト、次回更新日を過ぎたリストは現在のリストの代わりにはならず、古いリストを拒否するか黙って受け入れるかは配備によって異なります。

新規接続と稼働中のセッション

失効はセッションの確立時や再ネゴシエーション時に評価され、パケットごとにデータチャネルに対して評価されるわけではありません。すでに接続済みのクライアントは通信鍵を保持しているため、証明書がリストに現れた後もパケットを通し続けます。既定の再ネゴシエーション間隔は時間単位で測られるので、更新されたリストが新規の相手には効き始めても、稼働中のトンネルはそのまま残ります。

即時適用にはリストだけではなく、意図的な操作が必要です。サービスを再起動すれば全クライアントが再接続を強いられ、管理インターフェースで一つのセッションを終了すれば他は影響を受けません。インシデントごとにどちらか一方を選び、使った方を記録してください。二つの選択肢は影響範囲が異なり、そこが本当の判断です。

検証者が実際に読むファイルを届ける

リストは機関の記録から生成し、証明書を検証するすべてのマシンに配布する必要があります。CAホストで生成したままサーバーに導入しないことが最も多い失敗で、壊れた失効機能にしか見えません。

ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pem

ファイルが実際に読まれるかは二つの点で決まります。相対パスは設定ディレクトリを基準に解決されるため、運用者のホームに残したコピーは見つからないことがあります。またデーモンは通常、起動後に権限を落とすので、実行アカウントには各親ディレクトリの検索権限とファイルの読み取り権限が必要です。rootではなく実行アカウントで両方を確認してください、さもなければテストは誤ったことを証明します。

systemdのホストでは、読み取り専用ビューや保護されたシステムディレクトリによって、強化されたユニットがパスを隠すこともあります。サービス内部からはファイル欠如と区別できないため、権限の誤りを探す前にユニットの制限を確認してください。ファイルのモードを疑う前にユニットファイルを読んでください。

クライアントではなくサーバーで確認する

サーバーのログは何が起きたか、つまりリストを開いた、読み込んだ、あるいは失効したシリアルでの検証に失敗したことを示します。クライアントは一般的なハンドシェイク失敗しか報告しないため、失効の判断を探すのにクライアントのログは不適切です。

失効したプロファイルから新しく試して確認し、そこで止めてください。そのプロファイルから接続できたことは、ファイルのパスと実行アカウントを調べる合図であり、リストが間違っていたと決めつける根拠ではありません。その成功した試行を受け入れテストとして残し、見ていない再接続は数えないでください。

何も失効させないもの

ノートパソコンからプロファイルを消すこと、クライアントから証明書ファイルを外すこと、利用者に接続をやめるよう伝えることは、サーバー側では何も変えません。機関が失効を記録し、検証者が結果のリストを読むまで、証明書は有効なままです。

だからこそ連鎖を書き留める価値があります：失効を記録し、リストを生成して署名し、その正確なファイルを配布し、サービスアカウントが読めることを確認します。どの環も短く、一つでも欠ければ失効したクライアントが平然と接続します。四行のチェックリストは、一行もない前提に勝ります。