信頼ストアから古い VPN 証明書を削除する方法

VPN クライアントはアンインストールされ、プロファイルは設定から消えたのに、トンネルは古い資格情報のまま上がってきます。あるいは削除して再起動し、翌朝には戻っているのを見つけます。どちらも削除ボタンの故障ではありません。プロファイルは構成であり、証明書は鍵素材に加えて、プロファイルが指し示すだけのストアに記録された信頼の判断です。どちらを手にしているかで、「削除」が意味すべきことが決まります。

プロファイルは証明書ではない

VPN の設定では、三つの別々のオブジェクトが「証明書」と呼ばれます。クライアント ID は秘密鍵を持つリーフ証明書で、ゲートウェイはそれを使ってあなたが誰かを判断します。サーバー自身のリーフとその中間証明書は、接続時にクライアントが確認するものです。トラストアンカーは通常ルート証明書かプライベート CA 証明書で、チェーンをそもそも検証可能にするものです。 RFC 5280 はこれらをトラストアンカー、中間証明書、エンドエンティティと呼び、チェーンは各リンクがその下を署名している間だけ有効です。

ID を削除すれば、一つのデバイスがアクセスを失います。アンカーを削除すれば、 そのストアに対して検証するすべてのアプリケーションが、その下で発行されたあらゆるものを確認する能力を失います。VPN と何の関係もない接続も含まれます。この非対称性がここでのリスクのすべてです。一つのゲートウェイのためにインストールされたルートは、しばしば社内ポータル、メールサーバー、パッケージミラーを署名している同じルートです。二つのうちどちらを手にしているかを覚えておいてください。

所有権が、削除が削除されたままになるかを決めます。自分が所有するノート PC では、証明書を戻せるのはあなただけです。管理されたデバイスでは、構成プロファイルや MDM ペイロードが次のチェックインで再インストールする可能性があり、それが「戻ってくる」理由であり、より強く削除しても効かない理由です。

どのストアがまだ保持しているかを見つける

人は設定アプリから始めますが、そこは証明書が保存されない唯一の場所です。実際の場所は OS の信頼ストア、ブラウザー自身のストア、アプリケーションのプライベートストアです。

シリアル番号かフィンガープリントで照合し、表示名では決して照合しないでください。表示名は証明書を発行した人が設定し、再利用されます。「Example VPN」は三つの異なる鍵を持つ三つの証明書である可能性があり、一つは今も日常的に使われています。

certutil -user -store My
certutil -store Root
openssl x509 -in vpn-client.pem -noout -subject -issuer -serial -fingerprint -sha256

macOS では security ツールが同じ事実を示し、 find-identity どの証明書にまだ秘密鍵が付いているかを表示します:

security find-certificate -a -c "Example VPN" -Z /Library/Keychains/System.keychain
security find-identity -v -p ssl-client

狭いオブジェクトを削除し、共有の発行者を残す

削除する前にエクスポートします。 バックアップがなければ、唯一の復旧は再発行です。プライベート CA では、PKI を運用する人に戻ることを意味します。エクスポートした PFX は、削除が誤った判断だった場合に引き渡すものでもあります。

certutil -user -exportPFX -p backup My <serial> C:\temp\vpn-id.pfx
certutil -user -delstore My <serial>
Remove-Item Cert:\CurrentUser\My<thumbprint>

この -user フラグは、人がうっかり落とすものです。これがないと certutil はマシンストアで動作し、昇格したシェル、別の証明書セット、そしてマシン上の他のすべてのアカウントを含む影響範囲を意味します。

macOS と Linux では形は同じで、特定し、エクスポートし、症状を説明する最も狭いストアから削除します。 /usr/local/share/ca-certificates の下のファイルを削除し、 update-ca-certificates を再実行すれば十分です。 --fresh が助けになるのは、 /etc/ssl/certs 内のシンボリックリンクがすでに不整合な場合だけです。RHEL 系のシステムはアンカーを /etc/pki/ca-trust/source/anchorsに置き、そこでは trust anchor --remove が同じ仕事をします。

sudo security delete-certificate -Z <sha1> /Library/Keychains/System.keychain
sudo rm /usr/local/share/ca-certificates/example-vpn.crt
sudo update-ca-certificates
sudo trust anchor --remove /etc/pki/ca-trust/source/anchors/example-vpn.crt

CA 証明書を削除する前に、他に何がそれへ連鎖しているかを確認します。バンドル内のサブジェクトを一覧にするのは二行の確認で、そのアンカーが別の仕事をしているかどうかに答えます:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
  | openssl pkcs7 -print_certs -noout | grep -i example

ファイルの削除は ID の失効ではない

ローカルの削除はコピーを一つ取り除きます。秘密鍵は、古いチケットに添付された p12、バックアップフォルダー、あるいは同時に設定された二台目のノート PC にまだ残っている可能性があります。これがクライアント ID だった場合、ゲートウェイはサーバー側で ID が拒否されるまで、その鍵のどのコピーも受け入れ続けます。

ある OpenVPN PKI では、証明書を失効させ、 crl-verify が参照する CRL が最新であることを確認することを意味します。 easyrsa revoke 次に easyrsa gen-crl が短い版です。ID プロバイダーに結び付いたゲートウェイでは、そこでユーザーを無効化するかデバイスを削除してください。証明書はゲーム中の資格情報の一つにすぎないからです。アカウントが有効なままローカルコピーを削除するのは、整理整頓に見えてそうではありません。

インシデント作業には別の順序があります。まず証明書、そのシリアル番号、失効記録を保存し、それから削除して失効させます。その記録は何のコストもかからず、動作する資格情報を残しておく必要もありません。

ハンドシェイクと二つ目のアプリで検証する

チェーンは外側から確認します。今編集したストアの一覧からではありません。ストアはあなたの編集を示し、ハンドシェイクは結果を示します。

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com \
  -CAfile /etc/ssl/certs/ca-certificates.crt -verify_return_error < /dev/null
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt vpn-gateway.pem

戻りコード 0 は、残ったアンカーがまだゲートウェイを検証していることを意味します。アンカー削除後のチェーンエラーは想定される結果で、使用中のアンカーに当たったこと、クライアントが決して読まないストアの重複に当たらなかったことを確認します。接続がまだ動くなら、二つ目のコピー、アプリに同梱されたストア、ピン留めされた証明書を探してください。いずれも独自の信頼リストを持ち込むクライアントではよくあります。

次に無関係なものを試します。社内サイト、メールクライアント、パッケージミラーです。変更ウィンドウが閉じる前に、影響範囲を安く測れます。

• 役割を ID、中間証明書、トラストアンカーのいずれかとして特定
• シリアル番号とフィンガープリントを記録し、コピーを承認された場所へエクスポート
• 症状を説明する最も狭い範囲で削除を実施
• 人やデバイスが去ったときにサーバー側の認可を失効
• ハンドシェイクを説明し、無関係なアプリを一つ再テスト
• MDM ペイロードまたは管理プロファイルを更新、さもなければ証明書が戻る

再起動後に証明書が戻っているなら、作業は終わっていません。何かがそれを所有して再インストールしているので、もう一度削除する前にその所有者を見つけてください。三度目の削除も最初の二回と全く同じ振る舞いをします。