Windows Server で Always On VPN を構築し、手動のテスト接続で「IKE failed to find a valid machine certificate」が出る場合、原因の多くは“トンネル種別（ユーザー/デバイス）”と“証明書の置き場所（ユーザー/コンピューター）”の不整合です。NPS/RADIUS の前提から証明書の具体的な確認手順まで、現場で詰まりやすいポイントをまとめます。
エラーの正体：「machine certificate」と言われる理由
「IKE failed to find a valid machine certificate」は、IKEv2（IPsec）のネゴシエーション中に“マシン（コンピューター）証明書として使える条件を満たした証明書が見つからない”ときに出やすいメッセージです。Always On VPN では IKEv2 を使う構成が多く、認証に証明書（EAP-TLS）を使うと、クライアント側・VPN サーバー側のどちらでも同じ系統のエラーが出ます。
ポイントは「証明書がインストールされているか」だけではなく、次のような細部が合っているかです。
- トンネルがユーザートンネルなのかデバイストンネルなのか（＝ユーザー証明書なのかコンピューター証明書なのか）
- 証明書が正しい証明書ストアに入っているか（Current User / Local Computer）
- 証明書に秘密鍵があり、IKE/NPS が参照できるか
- サーバー名（接続先の FQDN）と証明書の名前が一致しているか
Microsoft のトラブルシューティングでも、イベントログ上は IKEEXT のエラー 13806として整理され、必要な証明書（マシン証明書／ルート証明書）不足や格納場所の不備が原因になりやすいとされています。参考：Troubleshoot Always On VPN – Windows Server | Microsoft Learn
まず整理：ユーザートンネルとデバイストンネルの違い
Always On VPN は同じ「VPN」でも、ユーザートンネルとデバイストンネルで前提が大きく変わります。テスト接続で迷子になりやすいのは、実際にはデバイストンネル相当の設定になっているのに、クライアントにはユーザー証明書しか入れていない（あるいはその逆）ケースです。
| 項目 | ユーザートンネル | デバイストンネル |
|---|---|---|
| 接続タイミング | ユーザーがログオン後に接続 | ログオン前に接続（端末として接続） |
| 主な認証 | ユーザー証明書（EAP-TLS）など | コンピューター証明書（EAP-TLS）が前提 |
| 証明書の格納場所 | Current User（ユーザー）ストア | Local Computer（コンピューター）ストア |
| OS 要件 | 比較的広い Windows エディションで構成可能 | ドメイン参加済み Windows 10 Enterprise/Education（1709 以降）など、要件が厳しい |
| つまずきポイント | 手動作成の VPN が「全ユーザー接続」になっていて、実はマシン証明書を要求している | Windows 10 Pro でデバイストンネル相当の検証をしてしまう／コンピューター証明書が未配布 |
デバイストンネルの要件や構成手順は Microsoft Learn にまとまっています。参考：Windows クライアントで VPN デバイス トンネルを構成する | Microsoft Learn／Configure the VPN device tunnel in Windows client | Microsoft Learn
切り分けの第一歩：エラーが「クライアント側」か「サーバー側」かを確定する
同じメッセージでも、どちらの端末が “証明書を見つけられない” と言っているかで打つ手が変わります。最短ルートは、クライアントと VPN サーバーの両方でイベントログを見て、13806 が出ている場所を確認することです。
| 確認先 | 見るログ | 見つかりやすい手がかり |
|---|---|---|
| クライアント | Microsoft-Windows-IKEEXT/Operational Microsoft-Windows-RasClient/Operational | 13806（証明書が見つからない）／接続失敗の詳細（どの認証方式で失敗したか） |
| VPN サーバー（RRAS） | Microsoft-Windows-IKEEXT/Operational RemoteAccess（運用ログ） | サーバー証明書の選択に失敗していないか／IKEv2 のネゴ失敗 |
| NPS サーバー | Network Policy and Access Services | RADIUS 要求が届いているか／EAP 設定・ポリシーの一致／未知のクライアント扱い |
もし NPS 側にログが一切出ないなら、IKE フェーズで止まっている可能性が高く、まずは証明書（特にサーバー証明書とトンネル種別）を疑うのが効率的です。逆に NPS で「未知の RADIUS クライアント」などが出ているなら、RADIUS クライアント登録の前提が崩れています。
原因になりやすいポイントA：RRAS を NPS の「RADIUS クライアント」として登録する
NPS で認証させる構成では、RADIUS 要求を送ってくる装置（＝VPN サーバー/RRAS）を NPS の「RADIUS クライアント」に登録しておく必要があります。ここでよくある勘違いは、クライアント PC を登録するのではなく、ネットワークアクセスサーバー（NAS）としての RRAS を登録するという点です。
手順の要点は次のとおりです。
- NPS（nps.msc）を開く
- 「RADIUS クライアントとサーバー」→「RADIUS クライアント」→「新規」
- Friendly name（識別しやすい名前）
- Address：VPN サーバーの IP または FQDN
- Shared secret：RRAS 側の RADIUS 設定と一致させる
公式手順：Configure RADIUS Clients | Microsoft Learn
VPN サーバーと NPS サーバーが同一台の場合でも、RRAS を RADIUS 認証プロバイダーとして NPS に投げる設定にしているなら、RADIUS クライアント登録が必要になるケースがあります。特に、RRAS→NPS の送信元 IP が「127.0.0.1」ではなく NIC の IP になる環境もあるため、NPS 側ログで送信元を確認し、必要ならループバック（127.0.0.1）とサーバー自身の IP の両方で登録しておくと切り分けが楽になります。
| 症状 | NPS のログ例 | 疑うポイント |
|---|---|---|
| 接続は開始するが、すぐ失敗。NPS のイベントに拒否が出ない | そもそもイベントが出ない | IKE の段階で失敗（証明書・UDP 500/4500） |
| NPS に「不明なクライアント」系のイベントが出る | RADIUS クライアントが不明として破棄 | RADIUS クライアント登録（IP/FQDN/Shared secret） |
原因になりやすいポイントB：証明書とトンネル種別の整合（本命）
このエラーの本命は、「今その接続が要求している証明書」と「実際に入っている証明書」が噛み合っていないことです。まずは必要な証明書を役割ごとに整理し、次にストアと内容を機械的にチェックします。
必要な証明書の全体像
Always On VPN（IKEv2 + EAP-TLS）で最低限そろえるべき証明書を、役割ごとにまとめます。環境によっては統合できますが、切り分けの最初は役割を分けて考えるのが安全です。
| 役割 | どこに入れる | 必要な主な条件 | 不足時の典型症状 |
|---|---|---|---|
| クライアント（ユーザー証明書） | Current User > Personal（My） | 秘密鍵あり／EKU: Client Authentication（+用途により Smart Card Logon）／有効期限内 | ユーザートンネルで認証失敗、EAP エラー |
| クライアント（コンピューター証明書） | Local Computer > Personal（My） | 秘密鍵あり／EKU: Client Authentication／端末名で発行されている | デバイストンネルや全ユーザー VPN で 13806 が出る |
| VPN サーバー（IKEv2 用サーバー証明書） | Local Computer > Personal（My） | 秘密鍵あり／EKU: Server Authentication／接続先名（FQDN）が SAN/Subject に一致 | クライアントまたはサーバーで 13806、ネゴ失敗 |
| NPS サーバー（EAP サーバー証明書） | Local Computer > Personal（My） | 秘密鍵あり／EKU: Server Authentication／NPS が選択できる | EAP ハンドシェイクで失敗、証明書警告 |
| ルート CA / 中間 CA | Current User/Local Computer > Trusted Root / Intermediate | 信頼済みチェーンを構成できる | 「信頼できない証明書」系エラー、チェーン不一致 |
チェックポイント：手動テスト接続が「ユーザートンネル相当」か「デバイストンネル相当」か
Always On VPN の本番では Intune や PowerShell で VPN プロファイルを配布することが多い一方、検証段階でコントロールパネルから手動で VPN を作るケースもあります。このとき、次の設定がズレると「machine certificate」系のエラーになりがちです。
- 全ユーザーが使用できる接続として作成している（管理者権限で作る VPN 接続）
- 認証方式が証明書（EAP-TLS）になっている
この組み合わせだと、Windows は接続をマシンコンテキストとして扱いやすく、ユーザー証明書が入っていても、Local Computer の証明書を探しに行くため 13806 につながります。ユーザートンネルを試したいなら、まずは自分のユーザーだけの VPN 接続として作り、ログオン後に接続するのが安全です。
チェックポイント：証明書が「正しいストア」に入っているか（ここで半分片付く）
「証明書は入れたはずなのに見つからない」という相談で最も多いのは、証明書自体ではなく格納場所の違いです。Windows には大きく分けて次の 2 つの証明書ストアがあり、Always On VPN のトンネル種別で参照先が変わります。
| ストア | 管理ツール | 主な用途 | Always On VPN での関係 |
|---|---|---|---|
| Current User | certmgr.msc | ユーザーが使う証明書 | ユーザートンネルのクライアント証明書 |
| Local Computer | certlm.msc（または MMC の Certificates スナップイン） | OS/サービスが使う証明書 | デバイストンネルのクライアント証明書、VPN/NPS サーバー証明書 |
確認は GUI でもできますが、現場では「見落としを減らす」ために PowerShell で一覧を出してしまうのが早いです。
# クライアント（コンピューター）証明書の確認
Get-ChildItem -Path Cert:\LocalMachine\My |
Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey, EnhancedKeyUsageList
# クライアント（ユーザー）証明書の確認
Get-ChildItem -Path Cert:\CurrentUser\My |
Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey, EnhancedKeyUsageList
一覧に出てこない場合は、単純にストアが違うか、インポートに失敗しています。HasPrivateKey が Falseの場合は「証明書はあるが秘密鍵がない」状態なので、IKE/EAP の認証では使えません（PFX で正しくインポートしたか、秘密鍵のエクスポート可否、アクセス権を確認します）。
チェックポイント：サーバー証明書の「名前」と「用途」を満たしているか
VPN サーバー（RRAS）側の IKEv2 は、サーバー証明書を「それっぽいものから自動選択」する挙動になることがあります。証明書が複数入っている環境だと、EKU が違う／名前が合わない／秘密鍵がない証明書を掴んで失敗し、結果として 13806 になることがあります。
最低限、次を満たすサーバー証明書を用意してください。
- Local Computer > Personal にある
- 秘密鍵がある（証明書アイコンに鍵マーク／HasPrivateKey=True）
- EKU にServer Authenticationが含まれる
- クライアントが指定するVPN サーバー名（FQDN）が、証明書の Subject または SAN に含まれる
- 有効期限内で、チェーンが正しく構築できる（ルート/中間 CA が信頼済み）
特に最後の「サーバー名」は盲点になりやすいです。例えばクライアントが VPN 接続先に IP アドレスを入れているのに、証明書は FQDN で発行していると、証明書の名前チェックで引っかかります。Always On VPN では基本的に FQDN を接続先に使い、証明書もその FQDN で発行するのが安定します。
チェックポイント：NPS の EAP-TLS 設定が「ユーザー/コンピューター」の想定と合っているか
NPS 側では、ネットワークポリシーの「認証方法」で Microsoft: Smart Card or other certificate（EAP-TLS）を使う構成が一般的です。ここで重要なのは、
- ユーザートンネルを通したいなら、ユーザー証明書でマッピングできる発行ルールにする
- デバイストンネルを通したいなら、コンピューター証明書でマッピングできる発行ルールにする
- 両方あるなら、NPS のネットワークポリシーを分けて順序を調整する
という運用です。実務的には、AD グループ（例：VPN 接続を許可するユーザーグループ／ドメインコンピューターグループ）で条件分岐させると事故が減ります。
また、NPS 自身が EAP サーバーとして提示する証明書も必要です。テンプレートとしては「RAS and IAS Server」などを使う構成が多く、証明書の EKU が Server Authentication を含むことを確認します。NPS で証明書を選択できない場合は、ストアの場所や EKU が合っていない可能性があります。
追加チェック：通信（UDP 500/4500）と名前解決、CRL 到達性
証明書が揃っていても、周辺条件で同じような失敗に見えることがあります。Microsoft のトラブルシューティング観点でも、次の項目はセットで確認するのが推奨されています。参考：Troubleshoot Always On VPN – Windows Server | Microsoft Learn
- UDP 500 / 4500 がクライアント→VPN サーバー間で遮断されていないか（NAT 環境では 4500 が重要）
- クライアントが指定する VPN サーバー名が、証明書の SAN/Subject と一致しているか
- 証明書失効確認（CRL/OCSP）が必要な設計の場合、クライアントが外部から CRL 配布点へ到達できるか
現場メモ：「社内 CA で発行した証明書を使っているが、VPN クライアントは社外から接続する」構成だと、CRL 配布点が社内 URL のままで到達できず、証明書関連の失敗に見えることがあります。エラー文は環境により変わりますが、切り分けとして CRL への疎通確認（名前解決と HTTP 到達性）も早めにやると遠回りを防げます。
手順で直す：チェックリスト形式のトラブルシュート
ここまでの内容を、作業手順として落とし込みます。最初は「できているつもり」を疑って、機械的に潰すのが一番早いです。
| 手順 | 確認内容 | OK の目安 | NG だった場合の対処 |
|---|---|---|---|
| トンネル種別の確定 | ユーザートンネルかデバイストンネルか | 「ログオン前に必要」ならデバイス、「ログオン後」ならユーザー | まずはユーザートンネルで検証し、要件（OS/証明書）を満たしてからデバイスへ |
| 接続プロファイルの性質 | 手動 VPN が「全ユーザー接続」か | ユーザートンネル検証ではユーザー接続 | 全ユーザー接続ならコンピューター証明書を配布するか、作り直す |
| クライアント証明書 | 必要な証明書が正しいストアにあるか | ユーザーは CurrentUser、デバイスは LocalMachine | 正しいストアへ再インポート／自動登録（GPO/MDM）を整備 |
| サーバー証明書 | RRAS が使えるサーバー証明書があるか | LocalMachine\My、秘密鍵あり、Server Authentication、名前一致 | 証明書を再発行（SAN に FQDN）／不要な証明書を整理 |
| NPS 設定 | RADIUS クライアント登録とポリシー | RRAS が RADIUS クライアントとして登録済み、EAP-TLS 設定済み | RADIUS クライアント追加、Shared secret 合致、ポリシー順序調整 |
| ネットワーク | UDP 500/4500、名前解決 | VPN サーバーの FQDN が引けて疎通できる | FW/ルータ設定、DNS、NAT-T の経路を再確認 |
よくある落とし穴と対処パターン
ユーザー証明書はあるのに 13806：実は「コンピューター証明書」を要求している
もっとも多いパターンです。次に当てはまるなら、この可能性が高いです。
- VPN 接続を「全ユーザーが使用できる」設定で作った
- Always On VPN のデバイストンネルを検証しているつもりで、OS が Pro だった
- クライアントにユーザー証明書しか入れていない
対処：ユーザートンネル検証ならユーザー接続として作り直し、デバイストンネル検証なら LocalMachine ストアにコンピューター証明書を配布します（ドメイン環境ならコンピューター証明書の自動登録が定番です）。
サーバー証明書は入れたのに 13806：秘密鍵がない／名前が合っていない
PFX をインポートしたつもりでも、秘密鍵が付いていなかったり、別ストアに入っていたりします。また、接続先名が IP アドレスになっているなど、名前不一致でも証明書系の失敗として表面化します。
対処：VPN サーバー（RRAS）の LocalMachine\My に「鍵付き」のサーバー証明書があるか確認し、クライアント側は FQDN で接続するよう統一します。証明書は SAN に FQDN を入れて再発行するのが確実です。
NPS を同居させているのに認証が進まない：RADIUS クライアント登録漏れ
同居構成でも、RRAS が「RADIUS 認証プロバイダー」として NPS に投げる設定の場合、NPS では RRAS を RADIUS クライアントとして認識させる必要があります。
対処：NPS のイベントログで送信元 IP を確認し、その IP（場合によっては 127.0.0.1 も）を RADIUS クライアントとして登録し、RRAS 側の Shared secret と合わせます。
運用のヒント：VPN と NPS を同一台にする場合の注意点
小規模検証では「VPN サーバーと NPS サーバーを同一台」にしがちですが、切り分けの観点では役割分離が有利です。とはいえ同居させるなら、少なくとも次の点は意識しておくと後から楽になります。
- 証明書は用途ごとにテンプレート（発行ルール）を分ける（VPN サーバー用／NPS 用／ユーザー用／コンピューター用）
- NPS のポリシーは「ユーザー」と「コンピューター」を別ポリシーにし、順序も管理する
- ログの保管先を決め、接続失敗時にクライアント・VPN・NPS をワンセットで見る癖をつける
まとめ
「IKE failed to find a valid machine certificate」で詰まったときは、まずRADIUS（NPS）側の前提として RRAS を RADIUS クライアント登録できているかを押さえ、次に本命のトンネル種別（ユーザー/デバイス）と証明書ストア（ユーザー/コンピューター）の整合を確認します。証明書は“存在”だけでなく、秘密鍵・EKU・名前一致・チェーン信頼まで含めて揃えるのがポイントです。
コメント