同じコモンネーム、2つの証明書：許可リストか失効か

同じコモンネームでノートPCの証明書を再発行すると、置き換えたように感じられ、誰もが古い証明書は無効になったと思い込みます。そうではありません。前者は同じ認証局が署名した有効な証明書のままであり、名前でクライアントを許可する統制はそれを許可し続けます。ID確認と資格情報確認を分けるのはシリアル番号であり、修正はそこに属します。

サーバーが使う名前付けポリシーから始めます

二つの統制が混同されています。クライアントが名乗る身元で許可することと、特定の証明書をサービスから外すことです。前者は名前の確認、後者は失効の確認です。答える問いが異なり、片方だけを備えた配備もあります。

サーバー設定を読み、どのIDソースが使われているかを記録します。 username-as-common-name は、認証済みユーザー名をクライアント固有の検索における実効名にします。これがない場合、証明書のサブジェクトのコモンネームが使われます。答えが何であれ、許可リストに触れる前に書き留めます。

二つの経路は同じ証明書に対して異なる許可名の集合を生みます。ここで推測すると、間違ったファイルを編集して統制が機能しないと結論づけることになります。

実際にクライアントを許可しているものを確認します

一致するファイルを持つ client-config-dir はクライアントごとのオプションを提供しますが、それ自体は許可規則ではありません。名前による許可には ccd-exclusive が必要で、一致するファイルがないクライアントを拒否します。稼働中の配備で有効にすると、名前に対応するファイルがない全員が切断されるので、何かを切り替える前にファイルを数えます。

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

数が確認です。ディレクトリの一覧と、接続を期待するIDを比較します。

次に、各ファイル名が実効IDと完全に一致することを確認します。大文字小文字と空白も含みます。 office-laptop のファイルは、サブジェクトが Office-Laptop と表示される証明書には何の効果もありません。末尾の空白も通常の一覧から隠れるため、存在するように見えるファイルが読まれないままになります。

ゲートウェイが読み込むCRLを確認します

CRLは失効した証明書を発行者とシリアル番号で特定します。これは名前の確認に欠けている粒度です。 二つの証明書は同じコモンネームを共有し、シリアル番号で異なることがあります。両者を分けるのはシリアル番号レベルのリストだけです。

ファイルを信頼する前に、設定されたパス、発行日、次回更新のフィールドを確認します。

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

CRLのシリアル番号と、保持する予定の証明書のシリアル番号を比較します。この比較が試験のすべてであり、一度目で見て行うことは、誰も読んでいないスクリプトを信頼するより価値があります。更新したCRLは、ゲートウェイがすでに読むパスで配布します。誤ったディレクトリにあるCRLは何も強制せず、クライアントログにも記録されません。

置き換えてから、両方の結果を証明します

同じコモンネームで代替証明書を発行し、両方のシリアル番号を記録し、その後にだけ古い証明書を失効させます。この順序なら、変更を準備する間も動作するIDを利用可能に保てます。

まず代替証明書を試験します。認証に成功し、その名前に許された範囲に到達するはずです。次に古い証明書を試験し、拒否されることを確認します。置き換えの成功は失効について何も語らないからです。両方がまだ接続できるなら、失効入力が読まれていないか、古いシリアル番号が一度も記載されていません。どちらも接続できないなら、資格情報ではなく許可規則を壊しています。

すでに確立されたセッションは別問題です。失効は新しい認証に適用され、ゲートウェイが稼働中の接続も切断するよう設定されていない限り、既存の接続は残ります。誰かに約束する前に、即時削除が必要かを決めます。

名前の確認に決してできないこと

許可リストは、このIDが接続してよいかを答えます。そのIDがどの証明書を使ったかは言えず、資格情報が有効で失効していない限り、古い資格情報を許可し続けます。この隙間はインシデント時に表面化します。代替証明書が数か月前に発行され、前者がまだ機能している場合です。

証明書レベルの統制が必要な場合は、証明書を名指しする仕組みを使います。CRLのエントリか、運用者が管理するフィンガープリントを確認する検証フックです。どちらも保守のコストがかかり、どちらも検査する対象について正直です。OpenVPN 2.6のマニュアル は crl-verify とクライアント固有の許可を別々のオプションとして文書化しています。

どの統制がどの仕事をするかを書き留め、次に否定ケースを試験します。接続を拒否するのを見たことがない失効は、機能することを願っている設定にすぎません。