動作していた OpenVPN 2 プロファイルを新しい Windows クライアントにコピーすると、以前のクライアントが自分で見つけていた証明書はもう提示されません。それを可能にしていた行は Community 2 クライアントに属する Windows 専用のセレクターであり、新しいアプリケーションは別の資格情報経路を持つ別のプログラムです。プロファイルはその一行以外は変わっていないので、違いに気づきにくいのです。

その報告では、Community クライアント、コアライブラリ、そして誰かがインストールしたフロントエンドという三つの層が混同されています。この指示を理解していたのはそのうちの一つだけでした。

このオプションが存在する場所での意味

Windows 上の Community OpenVPN 2 クライアントでは、cryptoapicert はクライアントがファイルではなく Windows 証明書ストアで見つけるべき証明書を指定します。これは Windows 専用の便利機能で、そのクライアントがストアを列挙し、得られたキーを自身の TLS スタックに渡す方法を知っているため機能します。したがってこのディレクティブはそのクライアントの設定言語の一部であり、OpenVPN プロトコルの性質ではありません。伝送形式にはそれを運ぶものは何もありません。

同じ行を別のアプリケーションにコピーすれば、新しいプログラムが解析し、無視し、あるいは拒否するかもしれない単語をコピーしたことになります。ディレクティブはプロトコルの機能ではなく、これは OpenVPN を話すすべてのクライアントの機能ですらありません。

代わりにコアライブラリが公開するもの

OpenVPN 3 Core は他のアプリケーションが組み込むライブラリで、外部資格情報をストア検索ではなく API で扱います。組み込む側のアプリケーションが証明書チェーンを渡し、後でライブラリに外部キーでの署名を求めると、ライブラリはそれを実行するためにアプリケーションへコールバックします。これはより一般的な設計で、どのプロバイダーが存在するかはフロントエンドが決めることを意味します。ライブラリ自身のオプション処理では、cryptoapicert は実装されていないディレクティブの中に現れ、これはその責務分担と整合しています。

こうしたコールバックの存在は、特定のパッケージ済みアプリケーションが現在のユーザーの個人ストアを列挙したり、特定のキープロバイダーをサポートしたり、スマートカードのプロンプトを完了できることを意味しません。それらはフロントエンドの性質であり、それぞれをフロントエンドが文書化する必要があります。

代わりに Windows フロントエンドが行うこと

OpenVPN Connect は別の道を取ります:オペレーターが PKCS#12 ファイルをインポートし、証明書とその秘密キーを含むそのファイルを、その目的で作成された OpenVPN Certificate Store に入れ、次に外部証明書をプロファイルに割り当てます。これは意図的なインポート手順であり、個人ストアにあるものを自動的に発見するものではありません。別の目的でインストールした証明書がクライアントの一覧にそのまま現れると誰かが想定したとき、この区別が重要になります。

インポートはキーポリシーにも影響します。キーを P12 ファイルにエクスポートすることは、エクスポート不可のキーがまさに防ごうとしていることだからであり、これは設定ではなくポリシーの問題で、誰かがインポートを試みる前に答えが必要です。

キーのポリシーに合う道を選ぶ

資格情報がエクスポート可能で、ポリシーが文書化されたインポートを許可しているなら、組織の保護された登録手順を使い、一時的な P12 とそのパスワードをログやスクリプトに残さないでください。キーがスマートカードや保護されたプロバイダーを決して離れてはならないなら、その要件を明示的にサポートするクライアントとプロバイダーの組み合わせを選ぶか、インストールしたバージョンについてベンダーの確認を得てください。どちらの分岐も他方の回避策ではありません。

ディレクティブをプロファイルに戻しても、アプリケーションが持っていない統合を補うことはできません。新しいクライアントのバージョンが必ず追加するわけでもないのは、その能力がフロントエンド自身の設計に属するからです。

ローカルキーが機能した後も、サーバーは証明書の身元、チェーン、認可を確認します。使えるローカルキーと受け入れられた VPN の身元は別の結果であり、それらを分けておくことが、フロントエンドの制限が弱められた証明書ポリシーに変わるのを防ぎます。

関連記事