証明書はWindowsの証明書ビューアーに見えているのに、クライアントはそれを使えません。証明書が見えるということは、ストアに公開オブジェクトがあることしか証明しません。接続プロセスが対応する秘密鍵を見つけられることや、それを使う権限があることは証明しません。

三つのオブジェクトが揃わなければなりません。選択された証明書、その背後の秘密鍵、クライアントが動作するアカウントは別々のものであり、それぞれが単独で失敗し得ます。

三つのオブジェクト、三つの答え

Windows上のコミュニティ版OpenVPNは、拇印を受け取るCryptoAPIストア選択子cryptoapicertを文書化しています。値は実際に使いたい証明書を指さなければならず、似た名前の別物ではいけません。OpenVPNベースの他のアプリケーションはまったく別の取り込みモデルを持ち得るので、この選択子はそれを文書化しているビルドに対する証拠にすぎません。下流をデバッグする前に、自分のクライアントがこの仕組みを実装しているか確認してください。

ビルドがこの選択子に対応していない場合、解決策は別のプロファイル形式であり、別の証明書ではありません。

選択子は正しい身元に解決するか

公開証明書は秘密鍵なしでも取り込めます。証明書ビューアーはどちらの場合も表示するため、この障害は、明らかにある証明書をクライアントが無視しているように見えます。エントリの有無だけでなく、鍵の関連付けを確認してください。

更新された証明書は二つ目の罠を追加します。両方のエントリがストアに残ったまま、プロファイルがまだ古い拇印を指していると、クライアントは廃止したい身元を選び続けます。

権限を見る前に、選択子がどの身元に解決するかを確認してください。誤った拇印は、鍵が欠けているときと同じように失敗します。

このアカウントはその鍵を使えるか

鍵へのアクセスはアカウントごとです。サービス、スケジュールされたタスク、対話的なデスクトップセッションでは、ストアの見え方も秘密鍵を使う権限も異なる場合があります。自分のセッションで証明書が見えることは、サービスアカウントについて何も語りません。

ハードウェアに裏付けられた鍵は、そのプロバイダーと確認手順を必要とする場合があります。プロンプトを表示できないサービスは、鍵を平文ファイルに書き出しても救われません。

何かを変える前にローカルのエラーを読んでください。選択の失敗、署名の失敗、サーバーからの拒否は三つの異なる結末です。ローカルなのは最初の二つだけです。三つ目は鍵が機能し、サーバーが証明書を拒否したことを意味します。

ローカルでの利用はサーバーの受理ではない

ローカルでの成功は認可ではありません。クライアントが鍵で署名した後も、サーバーは発行者、有効期間、ロール、そして自らのアクセス方針を評価します。同じCAの別の証明書が同じVPN権限を自動的に持つわけではありません。

サーバーが必要とするのは信頼の連鎖であり、クライアントの秘密鍵のコピーではありません。鍵をサーバーへ送ることは、検証の問題の修復には決してなりません。

障害を順番に切り分ける

エラーの正確な文言を残してください。鍵の権限不足をCAの変更に変えてはいけませんし、サーバーからの拒否をストアの修復に変えてもいけません。それぞれに独自の証拠があります。

障害が現れる順(選択子、鍵、アカウント、サーバー方針)に作業してください。コミュニティのクライアントリファレンスは、実行しているバージョンのWindowsストア選択子を文書化しています。

関連記事