失効したVPN証明書がまだ接続する？CRLの適用を確認する

証明書を失効させ、新しいリストを生成しても、古いプロファイルはまだトンネルを張ります。失効そのものが壊れているわけではなく、CRLはシリアル番号が有効でなくなったという署名済みの宣言であり、TLSを終端するコンポーネントが正しい発行者向けにそれを読み込み、受け入れを判断する前に初めてアクセスが変わります。こうした事例の多くはそこにあり、だからこそ失効と拒否は別の事実なのです。

後続の確認はそれ以前が正しいことを前提とするため、以下の五つの確認を順に行い、最初に成り立たないところで止めてください。

どのコンポーネントが受け入れを判断するかを確認する

クライアント証明書を検証するプロセスは、リストを適用できる唯一のプロセスなので、それを特定してください。OpenVPNサーバーではcrl-verifyで設定されたデーモン自身です。ocservではocserv.conf内のcrl行です。strongSwanでは入力は読み込まれたCRLとstrictcrlpolicyです。VPNの手前でTLSを終端するプロキシや機器が実際の検証者であることもあり、その場合、その背後のデーモンはクライアント証明書を一切見ません。

WireGuardは別のカテゴリです。証明書も失効リストもなく、ピアは設定内の公開鍵で受け入れられるため、アクセスを終わらせるとはその鍵を削除することです。WireGuardだけの配備でCRLを探しているなら、その仕組みは存在しません。

クライアント側の罠にも注意してください。サーバー証明書が気に入らないために接続を拒むクライアントは、サーバーのチェーンを適用しているのであって、自分の資格情報を失効させているのではありません。ユーザー証明書が失効するのは、その証明書が検証される場所だけであり、それはほぼ常にサーバー側です。

リストがどの発行者のために署名されたかを確認する

CRLは一つの発行CAに限定されます。ルートと中間がある場合、リーフ証明書は中間から出るため重要なリストは中間のCRLであり、ルートのリストはそれらのリーフについて何も語りません。間違ったファイルを指す検証者はそれを陽気に解析し、一致する項目を見つけられず、すべてを受け入れます。

デーモンに触る前に組を確認してください。証明書の発行者はリストのsubjectと一致しなければなりません:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

両方が同じCAから来る場合、証明書に印字されたシリアル番号がリストに現れるべき値です。一致しないなら、間違ったCRLかその間違ったコピーを持っています。

有効性も同じ確認に属します。過去のnextUpdateはリストを古くし、閉じた形で失敗する検証者は失効したものだけでなく全クライアントを拒否します。

シリアル番号がデーモンの読み込んだコピーにあるかを確認する

失効はCAデータベースに項目を書き、再生成は新しいファイルを書きます。どちらも、起動時に古いコピーを読み込んだ稼働中のデーモンには届きません。リストをダンプし、シリアル番号を探してください:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

次に、実装がファイルをどう取り込むかを確認します。OpenVPNはcrl-verifyに与えられたパスを起動時に一度だけ読むため新しいリストには再起動か再起動シグナルが必要で、同じオプションをディレクトリに向けると接続ごとに読み直され、だからこそディレクトリモードが存在します。strongSwanは資格情報を再読み込みする必要があり、たとえばswanctl --load-credsを使います。ディスク上のファイルが正しいことと、検証者がそれを使うことは別の事実です。

リストが欠けている場合や期限切れの場合のポリシーを確認する

これは多くの配備が明示的に決めたことのない判断であり、失効があなたを守るのか全員を締め出すのかを決めます。fail-closedは使える失効情報がなければ拒否するという意味で、fail-openはそれがなくても検証を続けるという意味です。strongSwanは選択をstrictcrlpolicyとして公開します。OpenVPNはcrl-verifyで、読めない、あるいは解析できないファイルでは起動を拒否し、期限切れのリストは黙って受け入れるのではなく期限切れCRLについてのTLS検証エラーとして現れます。

どちらの方向を選んでも選択より自動化が重要であり、nextUpdateの前にCRLを再生成する処理と、配備されたコピーが古くなったときの警告があれば、どちらのポリシーもインシデントになりません。OCSPによるオンライン確認は鮮度をレスポンダーに移しますが、応答を確認するよう設定されていない検証者は何も変えないため、同じ規則が当てはまります。

稼働中のセッションを確認し、次に鍵のコピーを確認する

失効は証明書の検証時に評価され、それは接続時と再ネゴシエーション時に起こります。確立したセッションは再ネゴシエーションするまで動き続け、OpenVPNの既定はreneg-sec 3600で一時間に一回です。その人が今すぐネットワークから外れる必要があるなら、リストの公開と併せてセッションを終了し、再接続が拒否されることを確認してください。

資格情報をそのコピーから切り離してください。一台のノートPCでプロファイルを削除しても同じ秘密鍵の別のコピーが認証するのを止められませんが、すべてのコピーを無用にするのは失効であり、しかも以前の確認が成り立って初めて効果があります。代替端末には独自の証明書を与え、片方を他方に触れずに失効できるようにしてください。

終わったと判断する前に、検証するコンポーネントが特定され、リストの発行者がリーフの発行者と一致し、失効したシリアル番号がデーモンの実際に読み込んだコピーにあり、欠落や期限切れのリストに対するポリシーが意図的で監視され、稼働中のセッションが待つのではなく終了されていることを確認してください。これらすべての背後にある形式はRFC 5280で規定されています。