更新した VPN 証明書: 一部のクライアントは依然として拒否する

更新のあと、環境の半数は再接続するが、三台の端末は拒否し、それぞれがゲートウェイの識別情報に関する警告を出す。更新そのものは日常作業だ。その三台が保持しているのは古い実体へのピン留めであり、ピン留めは CA の一覧でも、名前の検証でも、トラストストアの項目でもない。どのクライアントに触れる前に、三つの仕組みを比較してほしい。

一つの更新、二つの挙動

再接続するクライアントは信頼判断がまだ通っており、拒否するクライアントには新しい証明書が満たさない要件がある。その差は情報であり、雑音ではない。失敗したクライアントのメッセージを正確に読む。名前の不一致、未知の発行者、変化したフィンガープリントは三つの異なる判定であり、最後の一つだけがピン留めを指す。

失敗したクライアントがどのプロファイルを選んだかも確認する。独自のストアに置かれたインポート済みのコピーは、管理者が別の場所で元のファイルを編集しても変わらない。

更新が置き換えるのは実体であり、日付だけではない

フィンガープリントは符号化された証明書の中身を識別する。更新は新しい証明書を作るので、サブジェクト名と公開鍵が同じままでもフィンガープリントは変わる。CA を信頼し名前を検証するクライアントにとって、それは想定内で無害だ。ちょうど一つの証明書だけを受け入れるよう設定されたクライアントには致命的であり、トラストストアが新しい発行者を受け取っていないクライアントにも致命的だ。

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

二行目は別の問い、つまり鍵ペアが生き残ったかどうかに答える。鍵を使い回す更新はその値を保ち証明書だけを変えるので、まさにそこで管理者は何も変わっていないと決めつけたくなる。配備された証明書を調べるべきで、ビルドホスト上のものではない。リポジトリ内のファイルを比べても生成されたものは分かるが、リスナーが今まさに提示しているものは分からない。

クライアントが何をピン留めしているかを読む

プロファイルにフィンガープリントを保持し、接続のたびに比較するクライアントがある。プラットフォームのトラストストアに保存するものもあれば、CA だけに頼るものもある。修理の方法は場合ごとに違うので、まず仕組みを特定する。

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

一つ目のコマンドは従来のプロファイルのピンを示し、二つ目はエンドポイントが今まさに配信しているフィンガープリントを示す。両者が違えば、推測せずに障害を特定できたことになる。新しい値を、警告を出すすべてのクライアントに貼り付けてはいけない。発行者を理由に拒否するクライアントは拒否し続け、そうではないのにフィンガープリントが問題だったと自分に教え込むことになる。

各バックエンドが配信する証明書を比較する

断続的な結果は通常、複数のエンドポイントを意味し、一つのノードに適用した更新は他を古い実体のまま残す。共有名ではなくアドレスで各バックエンドを比較する。

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

一つのノードが遅れているプールは、二回目の試行で接続し一回目で失敗するクライアントを説明する。利用者が苦情を言う間に監視チェックが通ることも説明する。まず遅れを直す。すべてのノードが新しい証明書を配信する前に信頼設定を切り替えると何も動かない時間帯が生まれ、後に切り替えればクライアントが予測できない形で失敗し続ける。

管理された経路で信頼を変える

どこかで受け入れる前に、すでに信頼された管理チャネルを通じて交換を確認する。もっともらしい有効期限は所有の証明ではない。管理設定は、それを所有する手順を通じて更新し、許容される識別情報の計画的な重なりを入れ、配備が求める名前の検証は維持する。名前の検証を伴わないピン留めは、それが置き換えた CA の信頼より弱い設計だ。

そのうえでクライアントごとに、接続して受け入れた識別情報を確かめ、今信頼している証明書の版を記録する。一度は退けた警告は、次の更新で戻ってくる癖がある。