正しい VPN パスワードは欠けた証明書の代わりにならない

資格情報は正しく、プロファイルも問題なくインポートされ、それでも認証が完了する前に接続が失敗します。Windows では、EAP メソッド用の証明書が見つからないというエラー 798 が表示されることがあります。OpenVPN では、クライアント ログにサーバーを決して満足させない TLS ハンドシェイクが記録されます。どちらも同じ欠落した対象、つまりクライアントが提示すべきだったクライアント証明書を説明しています。

パスワードは秘密の知識を証明し、証明書はキーの所持を証明しますが、一方が他方を代替することはできません。

パスワードは問題ではなかった

エラー 798 は証明書の検索失敗です。クライアントは構成された認証方法に一致する証明書を求められ、自身のストアを検索しましたが、使えるものは見つかりませんでした。証明書が存在しない、秘密キーがない状態で存在する、有効期限が切れている、または検索が届かない場所に保存されている、といった意味になります。パスワードを再試行してもこれらの状態は変わりませんから、資格情報が正しくてもエラーが再発します。

行動する前にメッセージを読んでください。資格情報の拒否、証明書の検索失敗、TLS ハンドシェイクの失敗は三つの異なる所見であり、パスワードが関係するのはそのうち一つだけです。

クライアント ストアに必要なもの

関係する対象は二つです。クライアント証明書は、VPN クライアントを実行するユーザーに対して秘密キーとともにインストールされ、発行元のルートが信頼されている必要があります。.cer ファイルには公開証明書しか含まれないため、それだけでは何も認証できません。Windows の証明書マネージャーでは、クライアント ID は現在のユーザーの個人ストアに、ルートは信頼されたルート ストアに属します。

ID をコンピューター ストアに、またはルート ストアだけにインストールしても、ユーザーの個人ストアを対象とした検索は満たされません。ストア、秘密キーのフラグ、有効期間をまとめて確認し、その後クライアントを再起動してストアを読み直させてください。

二つの製品、同じ欠けた資格情報

OpenVPN サーバーは既定でクライアント証明書を要求します。auth-user-pass をクライアントに追加するとユーザー名とパスワードが送信されますが、TLS ハンドシェイクは依然として証明書を要求するため、verify-client-cert require の下ではパスワードだけでは接続を完了できません。サーバーは何も要求しないように設定でき、その場合パスワードが唯一のクライアント資格情報となり、強度は実際に低下します。auth-user-pass-verify の背後にある shell スクリプトで資格情報を検証できますが、スクリプト実行を有効にする必要があり、適切な認証バックエンドより危険な設計になります。

パスワードのみのプロファイルは、プッシュされるオプションにも依存し、それはさらにプル機構が有効であることに依存します。

チェックを無効にして欠けた証明書を直さない

メッセージを消すために検証を緩めたくなります。しかしそれは役目を果たしていた制御を取り除き、主張を証明しない接続を残すだけです。ゲートウェイが最近ルートを変更した場合は、古いパッケージに以前のルートがまだ含まれている可能性があるため、プロファイルを編集するのではなくクライアント パッケージを再ダウンロードしてください。プロファイル エディターに証明書認証のオプションがない場合、インストールされている Windows のバージョンがその方法を公開していないのかもしれないため、XML を手で編集するのではなく、システムを更新してください。

証明書がどのストアにあったか、どのユーザーがクライアントを実行したか、秘密キーが存在したかを記録してください。この三点で、この失敗のほぼすべての事例を説明できます。

パスワードは問題ありませんでした。方法が本当に必要としていた資格情報は別の場所にありました。