NPSのRADIUS証明書失効を早めに検知するには、証明書の自動更新に任せきりにせず、NPSが実際に提示しているサーバー証明書の有効期限を監視するのが基本です。NPSは PEAP、PEAP-TLS、EAP-TLS、さらに PEAP-MS-CHAP v2 でもサーバー証明書を使います。しかも Microsoft は、再接続時にクライアントとNPSが TLS handle を再利用し、クライアントがサーバー認証をやり直さない場合があると案内しており、利用者の「つながらない」で初めて気づく運用は遅れやすいのが実情です。 (Microsoft Learn)
ここでは、検索で混同されやすい「NPSのRADIUS証明書失効」を、まずはNPSがクライアントへ提示するサーバー証明書の有効期限切れとして扱います。後半で、EAP-TLS の CRL/失効チェックとどう違うのかも整理します。
なぜNPSのRADIUS証明書失効は見逃しやすいのか
802.1X や VPN の認証失敗は、利用者から見ると「Wi-Fiだけ落ちる」「VPNだけ認証に失敗する」としか見えないことが多く、証明書期限切れだとすぐ分からないことが珍しくありません。Microsoft の 802.1X トラブルシューティングでも、証明書まわりの障害は有効期限切れ、チェーン検証失敗、失効チェック失敗が典型例とされており、NPS 側の Security ログ 6272/6273、クライアント側の WLAN-AutoConfig / Wired-AutoConfig、必要に応じて CAPI2 ログを見る流れが推奨されています。 (Microsoft Learn)
さらに、Schannel のイベントでは、クライアントが受け取ったサーバー証明書が期限切れなら 36881、信頼されない CA なら 36882、失効済みなら 36883 が記録されます。つまり「認証失敗」という表面上の症状は同じでも、原因が期限切れなのか、信頼チェーンなのか、失効なのかで見るべき場所が変わります。 (Microsoft Learn)
まず監視対象を間違えない
「LocalMachine\My にあるサーバー証明書を全部見る」だけでは、実務では足りません。監視対象として優先すべきなのは、NPS が実際に認証に使えると判断している証明書です。
| 監視項目 | 監視する理由 | 実務での見方 |
|---|---|---|
| NotAfter（有効期限） | 期限切れの直接原因になる | 30日前、14日前、7日前で段階アラート |
| Subject / SAN のFQDN | クライアント側の名前検証に影響する | NPS名と接続プロファイルの名前が一致しているか |
| Server Authentication EKU | NPSの利用候補に入る条件 | 1.3.6.1.5.5.7.3.1 があるか |
| NPS画面に表示される証明書 | 「実際に使う証明書」を確認できる | 発行先、発行者、有効期限を台帳化 |
| 候補証明書の本数 | 古い証明書が残ると切り分けが難しくなる | 同用途の証明書が複数ないか確認 |
NPS が使うサーバー証明書には、Subject name が空でないこと、Server Authentication EKU を持つこと、必要に応じて SAN に DNS 名を持つこと、クライアントが信頼できる CA に連なることが求められます。Microsoft は、NPS に表示されるのも Server Authentication EKU と Subject name を備えた証明書に限られると明記しています。 (Microsoft Learn)
NPSコンソールで実使用証明書を確認する
最初にやるべきなのは、証明書ストアではなく NPS の EAP 設定画面で、いま何を使っているかを見ることです。確認手順はシンプルです。
- Network Policy Server を開く
- Policies > Network Policies を開く
- 対象ポリシーの Properties を開く
- Constraints > Authentication Methods で Microsoft: Protected EAP (PEAP) などの EAP 設定を開く
- Certificate issued to / Issuer / Expiration date を確認する
この画面で、NPS が認証に使えるサーバー証明書の発行先、発行者、有効期限を確認できます。つまり、ここで見えている証明書を基準にしないと、監視が「ある証明書」ではなく「使われていない証明書」を見てしまう危険があります。 (Microsoft Learn)
早期検知で効く4つの方法
| 方法 | 向く環境 | 強み | 弱み |
|---|---|---|---|
| NPSコンソールでの定期確認 | すべて | 実使用証明書を確認できる | 手作業なので抜けやすい |
| AD CS の自動更新 | ドメイン参加NPS | 更新漏れを減らせる | 監視の代わりにはならない |
| NPS上のローカル通知/タスク | 1〜2台のNPS | サーバー自身で期限接近を検知できる | 通知先の整備が必要 |
| 外部監視・スクリプト | 本番、複数台 | 集中監視と履歴管理がしやすい | 初期実装が必要 |
結論から言うと、実運用で安定するのは 「自動更新 + 外部監視 + 更新後の実機確認」 の組み合わせです。NPS の画面確認だけでは抜けますし、自動更新だけでは「更新されたか」は分かっても「NPSがいま何を提示しているか」までは保証できません。 (Microsoft Learn)
自動更新は必須。ただし監視の代わりではない
AD CS を使っているなら、NPS のサーバー証明書は Certificate Services Client – Auto-Enrollment を有効化し、Renew expired certificates, update pending certificates, and remove revoked certificates と Update certificates that use certificate templates を有効にしておくのが基本です。Microsoft も、NPS 向け証明書の展開・更新・管理を簡素化する方法として auto-enrollment を案内しています。 (Microsoft Learn)
ただし、ここで安心してはいけません。Microsoft は、auto-enrollment は 8時間ごとに実行され、証明書更新は有効期間の80%を過ぎ、かつ renewal period 内に入ってから行われると説明しています。たとえば 1 年有効・6 週間 renewal period の証明書なら、更新が走るのはおおむね 46 週目以降です。つまり、「まだ自動更新されていない」こと自体は必ずしも異常ではない一方で、更新が最後の 20% に寄るぶん、検知を遅らせる設計も危険です。 (Microsoft Learn)
実務では、更新ロジックの都合に合わせて、次のような多段アラートにすると運用しやすくなります。
| タイミング | やること |
|---|---|
| 90日前 | テンプレート権限、GPO適用、監視対象の台帳を確認 |
| 45日前 | 自動更新対象になっているか確認、CA側の発行状況を確認 |
| 30日前 | 外部監視アラートを強制的に通知、担当者へチケット化 |
| 14日前 | 実際にNPS画面で新証明書を確認、接続テストを実施 |
| 7日前 | 手動更新や切替の最終判断、古い証明書の整理 |
NPS自身の通知を使う
外部監視が弱い環境では、Windows の PKIClient 機能を使って サーバー自身に期限接近を検知させるのが有効です。Set-CertificateAutoEnrollmentPolicy では、Machine コンテキストの auto-enrollment ポリシーに対して ExpirationPercentage を設定でき、証明書寿命の何%時点から近期限イベントや通知を出すかを制御できます。さらに New-CertificateNotificationTask を使うと、証明書の置き換え、期限切れ、期限接近をトリガーに PowerShell スクリプトを起動できます。MY ストアは常に監視対象で、追加ストアも指定可能です。 (Microsoft Learn)
小規模環境なら、この仕組みで「NPS上でイベント発生 → スクリプトでメールやWebhook通知」という形にすると、監視製品を増やさずに実装できます。逆に複数台のNPSを持つなら、各サーバーでローカル通知を作るより、外部監視へ寄せたほうが管理しやすいです。
外部監視を主軸にする
本番環境で最も現実的なのは、LocalMachine\My にある Server Authentication EKU 付き証明書のうち、NPSで使う候補を毎日収集し、日数しきい値で警告する方法です。特に、候補が複数あること自体を異常として拾う運用は効果があります。
まずは候補証明書の一覧を毎日出すだけでも、期限切れの見落としはかなり減ります。
$serverAuthOid = '1.3.6.1.5.5.7.3.1'
$now = Get-Date
Get-ChildItem Cert:\LocalMachine\My |
Where-Object {
($_.EnhancedKeyUsageList | ForEach-Object { $_.Value }) -contains $serverAuthOid
} |
Sort-Object NotAfter |
Select-Object Subject, Thumbprint, NotAfter,
@{Name='DaysLeft';Expression={ [math]::Floor(($_.NotAfter - $now).TotalDays) }}NPS の要件上、少なくとも Server Authentication EKU を持つ証明書が候補になります。まずはこの一覧と、NPS の EAP 設定画面に出ている証明書を照合してください。監視対象をサムプリントで固定するか、FQDN + EKU で自動判定するかは環境次第ですが、更新後にサムプリントが変わる点まで考えると、「候補一覧を外部監視」「実使用証明書はNPS画面で確認」の二段構えが扱いやすいです。 (Microsoft Learn)
実際にチェーン、名前、失効検証までまとめて確認したいなら、Test-Certificate が便利です。Microsoft はこのコマンドについて、既定で失効状態を検証し、-DNSName を指定すると SSL ポリシーで DNS 名も確認すると案内しています。 (Microsoft Learn)
$cert = Get-Item "Cert:\LocalMachine\My\<thumbprint>"
Test-Certificate -Cert $cert -Policy SSL -DNSName 'nps01.contoso.local'ログ監視で取りこぼしを減らす
期限切れの「予防」だけでなく、「もう起きた」を素早く拾うにはログ監視が欠かせません。NPS 側では Security ログの 6272 / 6273、クライアント側では WLAN-AutoConfig または Wired-AutoConfig が基本です。さらに、証明書まわりの詳細な切り分けでは CAPI2 Operational ログが有効です。 (Microsoft Learn)
監査ログが無効だと、NPS 側の初動が極端に遅れます。監査設定は次のコマンドで確認・有効化できます。 (Microsoft Learn)
auditpol /get /subcategory:"Network Policy Server"
auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enableクライアント側でサーバー証明書期限切れを疑うときは、Schannel の 36881 をまず見ます。36882 なら信頼チェーン、36883 なら失効です。ここを見分けるだけで、対応が「証明書更新」なのか「ルートCA配布」なのか「CRL対応」なのかが大きく変わります。 (Microsoft Learn)
環境別に向く運用
| 環境 | 向く運用 |
|---|---|
| NPSが1台、AD CSあり | auto-enrollment を有効化し、毎日候補証明書一覧を監視。30日前と14日前にNPS画面で実証明書を確認 |
| NPSが複数台 | すべてのNPSから証明書情報を集中収集し、期限・候補本数・サムプリント差分を監視 |
| AD CSなし、手動更新 | カレンダー通知だけに頼らず、60/30/14/7日の多段アラートと、更新後の接続試験を必須化 |
| Wi-Fi/VPNクライアントが多い | サーバー側監視に加えて、クライアント側のSchannel/WLANログもSOCや監視基盤で集約 |
期限切れとCRL/失効障害の違いを混同しない
ここは実務でかなり重要です。CRL は、証明書が有効期限前に CA によって失効させられたかどうかを確認するための仕組みです。Microsoft は、EAP-TLS や PEAP-TLS などの証明書ベース認証では、既定で NPS が証明書チェーン全体の失効状態を確認し、失効チェックに失敗すると接続を拒否すると説明しています。また、CRL 自体が期限切れ、未到達、未更新でも認証失敗になります。 (Microsoft Learn)
一方で、NPS の CRL 関連レジストリ設定は HKLM\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 配下で、EAP-TLS のクライアント証明書失効チェックを制御するものです。NoRevocationCheck や IgnoreNoRevocationCheck を変えても、NPSサーバー証明書自体の有効期限切れは直りません。ここを混同すると、問題が長引きます。 (Microsoft Learn)
もし本当に CRL キャッシュや配布が原因なら、NPS 側では次のコマンドで CRL キャッシュを更新できます。期限切れ対策ではなく、失効チェック障害の切り分け用として覚えておくと便利です。 (Microsoft Learn)
certutil -urlcache * delete
certutil -setreg chain\ChainCacheResyncFiletime @now更新後に必ずやる確認
証明書を更新した直後に、次の4点を確認してください。
- NPS の EAP 設定画面で、新しい証明書の発行先・発行者・有効期限が表示されているか
- 実際の Wi-Fi または VPN クライアントで、本番と同じプロファイルを使って接続試験したか
- NPS の Security ログで 6272 / 6273、クライアントで WLAN/Wired AutoConfig と Schannel を確認したか
- 古い期限切れ証明書が残っていないか
最後の「古い証明書を残さない」は軽視されがちですが、Microsoft には IAS/RRAS の関連障害として、新しい証明書を入れても期限切れ証明書を残したままだと認証失敗するケースが記録されています。NPSそのものの最新仕様として断定はしませんが、更新後に期限切れ証明書を放置しない運用は十分に合理的です。 (Microsoft Learn)
よくある失敗ポイント
- auto-enrollment を有効にしただけで安心する
更新は有効期間の最後の 20% に寄って実行されるため、監視しきい値を expire 当日付近に置くと実務では遅すぎます。 (Microsoft Learn) - 証明書の有効期限しか見ない
Subject/SAN の名前不一致、信頼チェーン、EKU不足でも失敗します。サーバー証明書には Server Authentication EKU が必要で、クライアント側では接続先名との一致も見られます。 (Microsoft Learn) - Windows 11 の検証厳格化を見落とす
Windows 11 では server certificate validation behavior がより一貫したものになり、trusted root certificate thumbprint や server name の扱いが Windows 10 より厳密です。期限切れではなくプロファイル不整合で落ちることがあります。 (Microsoft Learn) - NPS監査ログが無効なまま
6272/6273 が取れていないと、障害の切り分けがほぼ勘になります。最初に監査状態を確認してください。 (Microsoft Learn) - 利用者報告を一次検知にしてしまう
TLS handle キャッシュの影響で、一部端末だけ遅れて症状が出る可能性があります。障害が一斉に見えないほど、外部監視の価値が上がります。 (Microsoft Learn)
迷ったらこの順で進めれば十分です
最初の一歩は、NPSコンソールで実際に使われる証明書を確認し、その証明書の期限を台帳化することです。次に、AD CS 環境なら auto-enrollment を有効化し、外部監視で候補証明書の期限と本数を毎日チェックします。最後に、30日前・14日前・更新直後の3回は、NPS画面と実接続テストで必ず裏取りします。これだけで、「期限切れ当日に初めて気づく」事故はかなり減らせます。 (Microsoft Learn)
NPSのRADIUS証明書失効を早めに検知する運用は、難しい仕組みを増やすことではありません。自動更新、見える化、実機確認を役割分担することです。監視対象を「証明書ストア全体」ではなく「NPSが実際に使う証明書」に寄せるだけで、運用の精度は大きく上がります。
コメント