Windows VPN が提示するマシン証明書はどれか

証明書はインストールされ、秘密キーも存在するのに、トンネルは認証で失敗し続ける。複数の証明書を持つマシンは、誰も意図しなかった候補を VPN に渡すことがあり、クライアントにはゲートウェイがどれを受け入れるかを知る方法がない。他の証明書を削除するのは、マシン上のあらゆるサービスに影響する選択ポリシーである。代わりに適格な集合を絞り込み、実際にどの証明書が提示されたのかを確認する。

複数の証明書、提示されるのは一つ

マシン証明書認証を使う Windows のネイティブ VPN プロファイルは、候補を制限する二つのフィルターを公開する。発行者フィルターと拡張キー使用法フィルターである。これらはクライアントが選べる集合を小さくする。不適切な証明書を修復するものではなく、残ったものをサーバーが受け入れる保証もない。この境界は変更記録に書いておく価値がある。次の読者は、フィルターが実際以上に多くを決めたと考えるだろう。

フィルターが扱う障害は狭く具体的である。誤った機関の有効な証明書や、ゲートウェイが受け入れない目的で発行された証明書が、意図したものより先に選ばれ、健全なストアの隣で認証失敗を起こす。二つのフィルターはそれを検討できるほど小さな集合に変える。このページの残りは、それらを順に適用する。

プロファイルを編集する前にストアを調べる

プロファイルが実際に使うストアで、候補とそのプロパティを一覧にする。ここでは秘密キーをエクスポートせず、証明書がマシンの外に出る必要もない：

Get-VpnConnection -Name 'Office' | Select-Object Name, TunnelType, AuthenticationMethod
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, Thumbprint, NotAfter, HasPrivateKey, EnhancedKeyUsageList

判断が依存するプロパティについて出力を読む。使える秘密キー、許容できる有効期間、意図した発行者、拡張に含まれる目的である。証明書は、存在し、正しく登録されていながら、この接続には役立たないことが同時に起こり得る。後で比較するのは指紋の列なので、出力は保存しておく。

編集の前に、プロファイルとそのスコープを確認する。マシン証明書が LocalMachine にある場合、ユーザーの EAP-TLS 証明書、アプリケーション独自の秘密キーストアは三つの異なるコンテキストである。管理されたプロファイルがそこにあるなら、すべてのユーザーのスコープと管理者コンテキストを使う。似た名前で二つ目のプロファイルを作ると、接続が実際にどの構成を使うのかが隠れる。

発行者フィルターはオブジェクトを求める

発行者のパラメーターは証明書オブジェクトを期待する。表示名や、裸の指紋文字列ではない。承認された機関の証明書を、確認済みのパスから、それが属するストアに渡す：

$issuerPath = Read-Host 'Certificate-provider path for the approved issuer CA'
$issuer = Get-Item -LiteralPath $issuerPath
Set-VpnConnection -Name 'Office' -MachineCertificateIssuerFilter $issuer

パラメーターの型が受け入れるという理由だけで、クライアント自身のリーフ証明書、似たサブジェクトを持つ別の機関、できたばかりのルートに置き換えてはならない。 二つの機関は同じサブジェクト文字列を共有し得る、だからこそテキストよりオブジェクトが重要になる。Microsoft の cmdlet リファレンス は両方の入力型を説明しており、失敗した試行の後ではなく、最初の編集の前に読む価値がある。

使用法フィルターは OID 文字列を求める

拡張キー使用法のパラメーターは OID 文字列を取り、クライアント認証の目的は 1.3.6.1.5.5.7.3.2 である。これを適用すると候補はその目的を持つ証明書に限定され、クライアント認証の配備が求めるのはまさにそれだ：

Set-VpnConnection -Name 'Office' -MachineCertificateEKUFilter '1.3.6.1.5.5.7.3.2'

値は配列なので、複数の目的を必要とする配備はそれらをリストとして渡す。フィルターにできないのは、証明書に目的を追加することだ。署名済みの拡張に対して評価される選択式であり、どのフィルターも拡張を書き換えない。だから目的を欠く証明書は登録をやり直す必要がある。

ユーザー証明書の EAP 構成は、マシン証明書のフィルタリングとは別に保つ。両者は異なる場所にあり、一方の変更が他方の障害を説明することはまれだからだ。プロファイルをドメインとデバイス管理のどちらが所有しているかも確認する。ローカルの編集は、誰もマシンに触れないまま次のポリシー更新で置き換わり得る。

クライアントがどの証明書を提示したかを証明する

新しい接続を確立し、意図した ID についてクライアントとサーバーの認証証跡を読む。複数の証明書がフィルターを満たす場合、結果は固定されたリーフではなく小さなプールなので、次の試行では別のメンバーが選ばれ得る。その証跡に現れる指紋を記録し、ストアから記録したものと比較する。

コマンドの成功は認証の成功ではない。記録する価値があるのは、管理されたポリシーの下で意図した証明書が認証し、無関係な証明書はそれを必要とするサービスに利用可能なままであることだ。二つのフィルターを経ても障害が残るなら、次に見るべきはプロファイル全体ではなく残った候補である。