Android で VPN 証明書をインポートし、鍵を検証する方法

Android で VPN クライアント証明書をインポートするのは数分で終わります。正しい場所に入ったかを確かめるほうが時間がかかり、インストールのダイアログが成功と言った時点で多くの人がまさにその部分を飛ばします。成功メッセージはファイルを解析できたというだけのことです。秘密鍵をどのプロバイダーが保持しているのか、Downloads フォルダーにまだコピーが残っているのかは何も語りません。

ステップ 1: P12 をマシンから出す前に読む

まずファイルそのものから始めます。中のサブジェクト、発行者、有効期限を言えないなら、後で検証できないものをインポートしていることになります。

PKCS#12 バンドルは通常、クライアント証明書、その秘密鍵、発行者のチェーンを運びます。openssl pkcs12 -in client.p12 -info -noout は鍵素材を吐き出さずに MAC と暗号アルゴリズムを表示するので、バンドルがパスワードで保護されているか、どの暗号を使っているかが分かります。続けて keytool -list -v -keystore client.p12 -storetype PKCS12 を実行すると、エイリアス、SHA-256 指紋、スマートフォンと比べる有効期間が得られます。

パスワードはファイルとは別の経路で送るか、コピーを残さない管理された配布フローの中でファイルを渡してください。アーカイブと同じチャットメッセージにパスワードを貼ると、二つの統制が一つになります。

ステップ 2: VPN アプリが実際に読むスロットにインストールする

素の Android 11 から 14 では、設定、セキュリティ、暗号化と認証情報、証明書のインストール、続いて VPN とアプリのユーザー証明書という経路になります。文言と階層はリリースやメーカーのスキンで変わるので、覚えたメニュー位置ではなく認証情報の種類のラベルをたどってください。仕事用プロファイルでは、認証情報がプロファイルの境界を越えないため、仕事側の内側からインストールしてください。

クライアント ID を CA 証明書スロットに入れないでください。そのスロットはユーザーの信頼ストアに供給され、Android 7 以降、アプリはネットワークセキュリティ設定が許可しない限りユーザー追加の CA を無視するため、そこに置いたクライアント証明書は VPN の鍵選択に決して現れません。

VPN クライアントの中にはシステムストアに一切触れず、代わりに P12 を自前のアプリディレクトリにインポートするものがあります。正当な設計ですが、以降の手順がすべて変わります。鍵はアプリのサンドボックスの中に住み、そのアプリが自分のストレージを扱うのと同じ強さしかないため、KeyChain が関与していると決めつける前に、クライアントのドキュメントを確認してください。

ステップ 3: どのプロバイダーが鍵を保持しているかを証明する

インポートが確認するのは解析であって、ハードウェア保護ではありません。Android 12 以降では KeyInfo.getSecurityLevel() が、鍵がトラステッド実行環境にあるのか、StrongBox にあるのか、ソフトウェアにあるのかを報告し、古い isInsideSecureHardware() 呼び出しを置き換えます。VPN クライアントがその値を表示しない場合、ステップ 1 の指紋が代替になります。インポート時に再エンコードされた証明書はバイト単位では一致しませんが、公開鍵とサブジェクトは一致します。

エクスポートできないことは使えないことと同じではありません。デバイスから出せない鍵でも、ユーザーがそのエイリアスの選択を許可したアプリなら使え、だからこそエイリアスの確認は形式ではなく実際の統制なのです。Android Keystore のドキュメントは、その設計判断をするなら一度読む価値があります。

次に、作ったコピーを数えてください。ノート PC の P12、チケットの添付ファイルのもの、先月のバックアップのものは、発行者が失効させるまでどれも有効な ID です。スマートフォン上のインスタンスのハードウェア保護は、それらには何の役にも立ちません。

ステップ 4: 画面ロックの要件が誰のものかを見極める

ここでは三つの秘密、すなわちデバイスのロック解除 PIN、秘密鍵のパスフレーズ、VPN アカウントのパスワードが混同されます。一つを求めるプロンプトは他をリセットする依頼ではなく、間違ったほうをリセットすることが、問題なく動いていたプロファイルから自分を締め出す原因になります。

デバイス管理者や管理対象プロファイルのポリシーがロックを要求する場合、その要件は証明書ではなくポリシーに属します。adb shell dumpsys device_policy は有効な管理者と彼らが強制するパスワード品質を一覧するので、PIN の規則が変わった理由が MDM エージェントかどうかを最短で確認できます。証明書を外してもポリシーは緩みませんし、ポリシーを外すのは設定の調整ではなく管理上の判断です。

使い勝手のトレードオフも想定してください。鍵がユーザー承認を要求する場合、最初のロック解除の前にトンネルは上がらないため、定時同期やリモート起動は設計上失敗します。配備の前に決めてください、後ではなく。

locksettings.db を編集したり、忘れたパターンの古い回避策を再実行したりする近道は避けてください。そうした手順は特定のビルド向けに書かれたもので、フレームワークがもう想定しない状態に認証情報ストアを残すことがあり、そもそもロックを要求したポリシーを変えることは決してありません。

ステップ 5: ID を廃止し、拒否を検証する

廃止には三つの部分があり、ローカルなのは最初の一つだけです。VPN プロファイルを削除し、設定、セキュリティ、暗号化と認証情報、ユーザー認証情報の下でユーザー証明書を削除し、その後で発行者に証明書のシリアル番号を失効させます。ローカル削除だけでは、誰かが P12 を保持していればサーバーがまだ受け入れる認証情報が残ります。

想定せずに結果を検証してください。廃止したプロファイルで接続を試し、サーバーが拒否することを確認します。それでもトンネルが上がるなら、間違ったシリアルを失効させたか、クライアントが別のインストール済み ID に黙って落ちたということです。

失敗したインポートを巻き戻す場合は、ディスクに残した復号済みの鍵ファイルを使い回すのではなく、元の暗号化バンドルから再インポートし、指紋を再確認してください。