Windows で EAP-TLS を使った PIV ログインが失敗する場合、署名経路を確認する

PIV カードの証明書をすべての Windows ダイアログに表示しても、VPN ログインは失敗することがある。見えることと使えることは別の性質だからだ。証明書は公開オブジェクトであり、ログインにはカードが独自のアクセス規則のもとで実行する秘密鍵操作が必要になる。この二つの事実の間には、プロファイルの選択、証明書の選択、ローカル署名、サーバー側の検証という、四つの異なる失敗の仕方をする四つの段階があり、順にたどれば一般的なハンドシェイクエラーは次の部分を持つ担当者への具体的な問いに変わる。

プロファイルと EAP 方式から始める

接続のプロパティを開き、プロファイルが実際にどの EAP 方式を使っているかを読み、次にその方式がどの証明書を選ぶ設定になっているかを読む。多くの配備では証明書ベースの外側方式と内側方式の両方があり、接続レベルで設定された証明書が EAP-TLS の内部で提示される証明書と自動的に同じになるわけではない。プロファイルが発行者やサブジェクトフィルターで証明書を選ぶ場合、そのフィルターは Windows が該当ストアで見えるものから選び、カードがたまたま持っているものから選ぶのではない。何にも一致しないフィルターは、プロファイルの構成に応じてプロンプトか無言の失敗に戻るため、変更の前に選択された拇印を記録しておく価値がある。

接続がサインイン中のユーザーとして動くのか、コンピューターとして動くのかも確認する。この一点が、どの証明書ストアが対象範囲に入るか、どのセキュリティコンテキストが署名を実行するかを決める。

どの証明書が選択されたかを確認する

Windows が選んだ拇印を、クライアント認証用途、信頼されたルートで終わるチェーン、認証サーバーのポリシーがマッピングする ID、そして試行の実際の時点を覆う有効期間という要件と照らし合わせる。これらは別々の確認であり、最後のものは、とくに継続的に発行される証明書と昨日の選択をまだ指しているキャッシュ済みプロファイルにおいて、人が予想する以上に多くの驚きを捕まえる。

ユーザーとコンピューターのコンテキストは確認のもう半分である。ユーザーの個人ストアにある証明書は コンピューターとして動くサービスからは見えないし、コンピューターの証明書も、プロファイルがそう指定しない限りユーザーモードの EAP 交換では提示されない。証明書を誤ったストアに再インポートすると、見える証明書と見えないログイン資格情報が生まれる。読むべきはプロファイル内のストアパスであり、たまたま開いたダイアログのほうではない。

PIN を推測せずに鍵操作を試す

選択が固まったら、問いはカードが署名を実行するかどうかである。Windows が秘密鍵に到達するには対応するカードプロバイダーかミニドライバーが必要で、デバイスは独自の PIN と存在の規則を操作に適用する。署名のたびにタッチを要求するカードは、セッション単位で検証をキャッシュするカードとは挙動が異なり、どちらも正規の構成であり、プロンプトが現れる時点を変える。この違いが、挿し直した直後は成功し再開後は失敗するログインを、証明書が誤っていないまま説明する。

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

最初のコマンドはカードを一覧し、リーダーとプロバイダーの状態を報告するものであり、それは Microsoft の スマートカードのデバッグに関するガイダンスに文書化されている。二つ目のコマンドは、ユーザーコンテキストが実際に何を見られるかを列挙する。どちらも認証の成功を証明しないが、どこで止まったかを絞り込む。

PIN を推測してはいけない。カードは再試行の上限を課しており、楽観的な試行を数回重ねると、権限の問題が管理者による復旧を要するブロック済み資格情報に変わる。ローカル署名が失敗したら、変種を試すのではなくプロバイダーの状態とカードの状態を記録する。同じプロファイル、同じ証明書、既知の正常なリーダーパスで一度だけ再試行して二つの記録を比べるべきで、複数の変数を同時に変えると結果ではなく物語ができる。

ハンドシェイクの両側を読む

署名が完了しても、まだ受け入れではない。認証サーバーはチェーンを受け入れ、失効を確認し、現在の規則で ID をマッピングし、要求を承認しなければならず、クライアント側はプロファイルが求める通りにサーバーの証明書を検証しなければならない。サーバーが生成した TLS 警告はクライアントのログではローカルで生成されたものと同じに見えるため、警告の文面よりどちら側が発したかのほうが重要になる。

Windows のイベントとサーバー側のイベントを時刻を揃えて集め、どちら側が最初の失敗を生んだかを特定する。RFC 5216 は EAP-TLS における所持の証明の手順を記述しており、一般的なハンドシェイク警告はローカルな鍵の原因を単独で名指ししない。二つのログを順序に変えるのは、時刻の比較である。

報告では境界をまっすぐ保つ

報告を四つの段階として書き、それぞれに、どのプロファイルとコンテキストが動いたか、Windows がどの証明書を選んだか、カードが署名したか、サーバーが何を決めたかという一つの判定を添える。この構造は次の手順を明らかにし、誰も特定していない段階を通すために検証を無効化するというよくある修理を防ぐ。

一時的な比較としてのソフトウェア証明書は正当な管理者テストだが、資格情報と保証のモデルを変えるため、静かな本番回避策ではなく承認された変更に属する。同じ規律は PIN の試行と、失敗する段階が判明する前の資格情報の再発行にも当てはまる。同じように失敗する交換用カードは、問題がそもそもカードになかったという高価な証拠である。