同一性を変えずに VPN 証明書を更新する

同一性を変える証明書更新は更新ではなく、保守チケットを着た移行です。クライアントは名前、チェーン、ときに特定の鍵を検証し、その三つは有効期限を変えずに変わり得ます。交換を依頼する前に、クライアントが実際に確認するものを、ホスト名またはピアの同一性、証明書の目的、鍵ポリシー、発行チェーンという形で書き出します。更新が定例か協調的かは、交換がこれらのどれを変えるかで決まります。

三つの条件が更新の形を決める

三つの条件とは、何かがリーフを固定しているか、チェーンが変わるか、ほかに誰が名前を検証するかです。CA の都合ではなく、午前三時に失敗するのはクライアントだからという理由で、クライアント側から答えてください。

手持ちの証明書を検査することから始める。openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName はサブジェクト、発行者、有効期間、そして証明書が実際に有効な名前を出力します。最後の項目が最も重要で最もよく前提にされるのは、クライアントが依存する SAN を省いた更新要求が、技術的には有効でも機能的には誤った証明書を生むからです。古い証明書の SAN 一覧を、記憶から打ち直すのではなく要求にコピーしてください。

条件一：何かがリーフを固定しているか

クライアントが維持された CA を信頼し名前を検証するなら、新しい鍵でのリーフ更新はクライアントには見えません。いずれかのクライアントがリーフ証明書、その指紋、またはその公開鍵を固定しているなら、古いピンでは新しい証明書を検証できないため、交換はハードカットオーバーを伴う協調的な変更です。

何かを注文する前に、自分がどちらのケースか調べてください。誰も記録していないピンも、壊れるときにはピンです。

条件二：ピンとチェーンを比較する

指紋があれば、古い証明書と新しい証明書で openssl x509 -noout -fingerprint -sha256 -in server.crt、公開鍵を比較するには openssl x509 -noout -pubkey を使って、ピンを確認できます。クライアント設定、モバイルプロファイル、またはアプライアンスの信頼ストアのいずれかにその値が含まれていれば、ピンがあります。モバイル VPN プロファイルは、一度配布されて二度と検査されないため、よくある隠れ場所です。

交換が同じ中間証明書から来ていて、クライアントがその中間証明書をすでに持っているか取得できるなら、信頼側では何も変わりません。新しい中間証明書、別の発行者、誤った順序で届けられたチェーンは、更新を信頼の変更に変え、その障害は期限切れの証明書ではなく未知の発行者のように見えます。

サーバーが実際に送るチェーンを openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts で確認し、openssl verify -CAfile ca.pem -untrusted chain.pem server.crt でローカルに検証してください。変更前にそうすれば、後で比較するための基準が得られます。

条件三：ほかに誰が名前を検証するか

VPN コンセントレーター、ロードバランサー、監視プローブ、RADIUS や SAML の統合、モバイルプロファイルは、それぞれが期待される名前や信頼アンカーの独自のコピーを保持できます。更新は、証明書が変わりコピーは変わらないので、それらのコピーが食い違う瞬間です。

変更前にすべての利用者を列挙し、それぞれに更新が必要か決めてください。忘れたものが、あなたを呼び出すものです。

タイミングの罠もあります。有効期限だけでなく有効開始も、後での有効化のために用意された証明書は早すぎる設置では拒否され、そのエラーが準備の問題ではなく時計の問題のように見えるから、検査してください。配布前に新しいファイルで openssl x509 -noout -dates を実行するのは二秒の確認です。サポートされた復旧経路と既知の良好な設定も維持し、失敗した更新を以前の証明書と鍵の復元で巻き戻せるようにしてください。

配布し、新しい認証で検証し、その後で廃止する

確立済みのトンネルは構築時の検証を反映しているため、新しい接続がすべて失敗していても健全に見えます。クライアントが使う実際のサービス名で、新しい認証を使ってテストしてください。

利用者が気にするアプリケーション層の確認を完了し、チェーンの配信をサーバー側ではなくクライアント側から確認してください。移行を静かに保つために名前や証明書の確認を抑え込むと、一時的な互換性の問題が恒久的な問題になります。

廃止済みの資材は、展開が検証されてから初めて引退させ、侵害された鍵はまったく別のケースとして扱い、更新だけでは何も失効しないため、影響を受けた同一性には展開の失効とセッション処理のプロセスが必要です。RFC 5280 は、このすべての土台にある証明書とパス検証の規則を定義しています。定例のリーフ更新を CA の交換から切り離しておくことで、クライアントに理由なく新しい発行者を信頼させないようにします。