Android VPN の Keystore エラー：再登録・ロック解除・再試行のどれを選ぶ？
Android の keystore が示す三つの結果には、それぞれ別の回復手順が必要です。アプリのストレージを消去する前に、ロック解除・再登録・プロバイダーへの再試行を比較してください。
プロフィールは一覧に残ったままで、証明書もインストール済みと表示され、接続ボタンは「Keystore エラー」とだけ書かれたメッセージで失敗します。アプリのストレージを消去したり端末を手放したりする前に、どの鍵操作が失敗したのかを特定してください。三つの結果が同じダイアログを出しますが、それぞれ対応する操作は異なり、そのうち破壊的なのは一つだけです。この比較に十分かける価値があるのは、間違った枝を選ぶと残したかった身元を失うからです。
一つのダイアログの裏にある三つの失敗
一つ目は認証です。鍵は存在し有効ですが、使うにはユーザーが存在を証明する必要があります。端末のロック解除、生体認証、または仕事用プロファイルのチャレンジです。ロックのタイムアウト、登録済みの生体情報、プロファイルの状態が最近変わった場合、鍵自体はまったく正常でも鍵の使用が失敗することがあります。
二つ目は恒久的な無効化です。一部の鍵素材は、ロック方法のリセットや生体登録の変更の際にプラットフォームのポリシーで無効化されます。保護していた結び付きがもう成り立たないからです。鍵は修復できず、再試行は回復計画ではありません。身元はそれを発行した登録手続きによって置き換える必要があります。
三つ目はプロバイダーの障害です。keystore サービスが今この操作を完了できませんでした。時々再試行する価値があるのはこの分類だけで、それ以外にありません。
| Failure | What it means | What recovers it | What does not |
|---|---|---|---|
| User not authenticated | Key needs a presence check | Supported unlock or authorization flow | A VPN account password reset |
| Key permanently invalidated | Binding is gone; key unusable | Replacement enrollment for that identity | Retrying, rebooting, reinstalling the client |
| Transient provider error | Service could not complete now | The provider's documented retry path | Clearing app data |
三つのうち二つは破壊的でなく、一つは端末レベルでは解決策がまったくないことに注意してください。どれも端末を消去して解決するものではありません。それでも人々が最初にその手を取るのは、ダイアログが他に何も示さないからです。
再登録とデータ消去の違い
この二つは外から見ると似ていますが、同じではありません。再登録は発行システムに新しい身元、つまりこの端末に結び付いた新しい証明書や鍵を要求し、古いものを引退させます。データ消去はアプリの保存状態を削除するので、鍵を削除せずに鍵への参照だけを消すこともあれば、鍵を削除して再作成する権限を残さないこともあります。
この区別が重要なのは、エクスポートできない鍵は設計上持ち運べないからです。端末の keystore にあり、利用可能なハードウェアやプロバイダーに支えられており、バックアップが取得して復元が戻すようなものではありません。配備の身元がエクスポートできない鍵なら、回復は再登録だと計画し、その登録を得るための承認済みの経路があることを事前に確認してください。組織によってはそのためにプライベートネットワークへのアクセスを要求し、まさにそれが壊れた VPN の提供していたものでした。
したがって順序はこうです。まずサポートされた認証経路を試し、次に鍵が恒久的に無効かを判断し、そうである場合にだけ身元を置き換えます。ストレージの消去は最後です。何が再作成されるかを知った後に行うのであって、簡単だからといって最初ではありません。
再試行できるものだけを再試行する
古いプラットフォーム版は keystore のエラーを一つの例外にまとめていたため、多くのクライアントが何でも再試行します。API 33 からは例外の型が構造を持ちます。数値のエラー、一時的障害のフラグ、再試行ポリシーです。クライアント開発者にとって再試行ポリシーが意味を持つのは一時性のフラグが真のときだけです。恒久的な無効化には再試行の予定がなく、ループで叩いても電池を消耗してログを埋めるだけです。
クライアントを書くのではなく診断する場合も、実際の帰結は同じです。毎回同じ失敗なら一度きりの不具合は除外できますが、恒久的に無効化された鍵と、しばらく利用できないプロバイダーとを区別できません。プロバイダーの障害は十回目の試行でも一回目とまったく同じに見えます。API 33 の構造化フィールドがなければ、繰り返しは二つ目の信号を探す理由として扱ってください。エラーコードがビルドで見えるならその値、事業者の状態、同じ端末の別の鍵が成功すること、などです。鍵が死んでいる証拠として扱わないでください。
原因の連鎖を読み、ラベルを読まない
アプリケーションは元の例外を包み、画面のやさしい文字列が枝を決める唯一のフィールドを隠すことがよくあります。 原因の連鎖と試行の時刻を保存する：外側の例外はたいてい操作を示し、原因は鍵の状態を示します。
二つのアプリが失敗すれば端末が故障しているという推論には抵抗してください。鍵ごとに異なるプロバイダーやセキュリティレベルに支えられていることがあり、まだ動くアプリが同じ操作をまったく行っていないこともあります。署名、復号、鍵の証明は同じサービスへの別の要求です。 KeyStoreException のリファレンス は新しい API レベルでの構造化フィールドを説明しており、あなたのビルドが実際に何を報告できるかを確認する場所です。
ハードウェアの結論を支えるものは、多くの人が思うより狭いです。同じ操作が、同じプロバイダーで、独立した鍵にわたって、鍵レベルのエラーではなくプロバイダーレベルのエラーで失敗する場合です。それはプラットフォームの診断への問いであり、端末の一括りについてのサポートフォーラムのスレッドへの問いではありません。
判断する間に記録すべきこと
Android のビルド、クライアントのバージョン、選択したプロフィール、失敗した操作、そして最近何か変わったかどうかを記録します。OS の更新、ロック画面の変更、新しい指紋、再登録などです。順序は原因の証拠ではなく文脈として記録してください。鍵の失敗の前のロック変更はもっともらしい相関であって、証明ではありません。
そのうえで、特定した枝に従って行動します。一時的なら身元を保ち、サポートされた再試行経路を使います。認証が必要なら、サポートされたロック解除の流れを完了し、ダイアログを越えるために無効化するのではなく、配備が要求するロックポリシーを維持します。恒久的に無効なら、通常の登録を通じて身元を置き換えて引退させます。
最後に、新しい承認済みの接続で、実際のリソースに対して、サーバー検証を有効にしたまま結果を証明してください。証明書検証を緩めてしか動かないものは、鍵の問題を直していません。それはネットワーク層に移しただけで、後でもっと悪い症状として現れます。
- 三つの枝：認証が必要、恒久的に無効、プロバイダー側で一時的。
- 再試行で得をするのは三つ目だけで、しかも自身の再試行ポリシーに従う場合に限ります。
- 置き換えの登録はアクセスを回復し、データ消去はその選択肢を奪います。
- 新しい接続と通常のサーバー身元検証で確認してください。