トークンがあるのに OpenVPN が秘密鍵ファイルを求める理由

トークンを挿しても、ベンダー自身のツールには見えているのに、VPN クライアントは秘密鍵ファイルを要求します。このプロンプトはトークンが未対応だという証拠ではありません。多くの場合、プロファイルがクライアントにトークンを使うよう指示していないため、既定で期待する証明書と鍵の入力に戻っているだけです。

そのフォールバックが止まるには、二つの別個の値が正しくなければなりません。トークンを公開するプロバイダーと、その中の証明書の識別子です。これらは別のオプションで指定され、混同しやすい項目です。

プロファイルが指示しているからクライアントはファイルを要求する

既定のプロファイルは証明書ファイルと秘密鍵ファイル、または単一の PKCS#12 バンドルを想定します。これらの入力がないとクライアントは読み込むものがなく、ファイルが存在しない場合とほぼ同じ挙動になるため、症状は仕組みの欠落ではなく壊れたパスとして読まれます。PKCS#11 の経路はこれらの入力を補うのではなく置き換えるので、鍵ファイルを指定したままのプロファイルはファイルを使い続けます。ファイル入力を意図的に外し、トークンに両方を供給させてください。

プロバイダーのオプションが指すのはミドルウェアのライブラリであり、デバイスでも証明書でもありません。パッケージ版のクライアントがそのライブラリを読み込めるかはビルド方法に依存し、一部のビルドだけが有効にする任意の p11-kit 対応も含まれます。一般的なチュートリアルでは、お使いのパッケージの構成までは分かりません。

シリアル化された識別子は別の値

証明書の識別子は検出処理が生成する長いシリアル化文字列であり、ライブラリのパスでも、トークンの PIN でも、VPN アカウント名でもありません。引用が必要な文字を含むことが多く、引用しない値は明確なエラーなしに切り詰められたり誤読されたりします。クライアント自身の 識別子の検出 オプションでトークンが公開する項目を一覧し、目的のエントリを正確にコピーしてください。一覧の先頭のオブジェクトを選ぶと、デバイスが誤った証明書を提示する結果になります。

検出の出力は、そのプロバイダーを通じてトークンが見えるかという前提の問いにも答えます。何も一覧に出なければ、問題は VPN クライアントより上流にあり、ミドルウェア側に属します。

接続するプロセスがトークンに到達できなければならない

デスクトップセッションで動くトークン操作は、システムサービスについては何も証明しません。サービスは別のユーザーで、別のマウント名前空間で、ベンダーのライブラリを含まないモジュールパスで、あるいはデバイスノードを開く権限なしで動作しているかもしれません。実際に接続を保持しているプロセスを特定し、その文脈から検証してください。

PIN の扱いは独自の判断が必要です。参照実装は PIN キャッシュと保護された認証パスを提供しており、どちらも運用者がワークフローを発明するのではなく選択できるように存在します。無人運用の要件を共有プロファイル内の平文 PIN に変えないでください。トークンの保護を利便性と引き換えにすることになります。トークンが鍵のエクスポートを禁じている場合、署名はデバイス上で行われ、PIN が唯一のローカル秘密になります。それにふさわしい注意で扱ってください。

トークンが置き換えないもの

トークンは配備されたポリシーの下でクライアントを認証しますが、サーバーに対するクライアントの検証を置き換えるものではありません。選択に成功した証明書は、予期しないゲートウェイ証明書を受け入れる許可ではありません。二つの検証は逆方向を守っています。

登録はいまも発行者側で行う必要があり、ゲートウェイはいまも識別子を承認する必要があります。

受け入れのためには段階を分けてください。プロバイダーが読み込まれ、目的の証明書が見つかり、秘密鍵がローカル認可のもとで使われ、VPN が認証し、リソース操作が成功する、という順です。パスワードを巡らせて暗号スタックを再インストールするのではなく、最初に失敗した段階で止めてください。

バージョン、モジュールの所有権、選択した公開識別子、サニタイズしたエラーを記録し、PIN と資格情報バンドルはその記録に含めないでください。