AD CS（Active Directory 証明書サービス）の監査を有効にしたのに、証明書要求の SAN（Subject Alternative Name）がイベントログに一切出てこない――オンプレ PKI を運用していると、かなりの確率でぶつかるポイントです。本記事では「何が足りないのか」「どのフラグをどう設定すれば SAN がログに出るのか」、さらにセキュリティ影響や再起動の要否まで、実運用目線で詳しく整理します。
なぜ AD CS の監査を有効にしても SAN が見えないのか
まず、よくある状況を整理します。
- Windows Server 上でエンタープライズ CA（AD CS）を構築済み
- 「詳細な監査ポリシー」で 証明書サービスの監査 を有効化
- CA 管理コンソール（certsrv.msc）の「監査」タブで
「証明書要求の発行および管理」などにチェック済み certutil -setreg policy\EditFlags +EDITF_AUDITCERTTEMPLATELOADも設定済み- Security ログに Event ID 4886 / 4887 は出るが、SAN 情報が見当たらない
ここで重要なのは、以下の点です。
- EDITF_AUDITCERTTEMPLATELOAD は「テンプレート読み込みの監査用」のフラグであり、
証明書要求の内容（サブジェクトや SAN）を追加で出力するフラグではありません。 - 多くの申請パターンでは、SAN が「証明書の拡張」ではなく リクエスト属性として CA に渡されます。
- 既定では CA はこの「SAN 属性」を無視するため、証明書にもログにも SAN が反映されません。
つまり、監査設定や AUDITCERTTEMPLATELOAD は正しくても、CA が SAN 属性をそもそも処理していないかぎり、イベントログに出てこない、というのが根本原因です。
SAN がログに現れるまでの全体像
「何をすれば SAN が見えるのか」をイメージしやすいように、流れを分解してみます。
- クライアントが SAN を含んだ証明書要求（PKCS#10 など）を作成
- 要求が CA（AD CS）に届く
- CA のポリシーモジュールが、リクエスト本体／属性を解釈
- CA が要求を承認（または拒否）し、その結果を Security イベント 4886 / 4887 として出力
- 承認された場合、SAN が埋め込まれた証明書が発行される
このうち、SAN がログに現れるための必須条件は次の 3 つです。
| 要素 | 条件 | 満たされないとどうなるか |
|---|---|---|
| クライアント要求 | SAN が「属性」または「拡張」として正しく含まれている | そもそも SAN が無いため、証明書・ログともに SAN なし |
| CA のポリシー | EDITF_ATTRIBUTESUBJECTALTNAME2 が有効で、属性 SAN を処理できる | 属性として送った SAN は無視され、証明書にもログにも載らない |
| 監査設定 | 証明書サービス監査（4886 / 4887 など）が有効 | そもそも 4886 / 4887 が記録されず、SAN 以前の問題になる |
この記事で焦点となるのは、真ん中の CA のポリシー部分です。ここを正しく設定すると、SAN が証明書に入り、かつ Security ログにも情報が出るようになります。
CA 側の設定：EDITF_ATTRIBUTESUBJECTALTNAME2 を有効化する
属性 SAN を CA に受け付けさせるには、CA のポリシーモジュールの EditFlags にある EDITF_ATTRIBUTESUBJECTALTNAME2 をオンにする必要があります。
現在の設定値を確認する
certutil -getreg policy\EditFlags
このコマンドで出力される EditFlags の値に、0x00040000 が含まれていれば EDITF_ATTRIBUTESUBJECTALTNAME2 が有効です。
EDITF_ATTRIBUTESUBJECTALTNAME2 を有効にするコマンド
rem 管理者権限のコマンドプロンプト／PowerShell で実行
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
rem 設定反映のため CA サービスのみ再起動
net stop certsvc
net start certsvc
- OS の再起動は不要です。CA サービス（Active Directory 証明書サービス）の再起動だけで反映されます。
- この操作で、既存のテンプレート定義（サブジェクト名の作り方や有効期間など）が書き換えられることはありません。
EDITF_AUDITCERTTEMPLATELOAD との役割の違い
混同されがちな 2 つのフラグを整理しておきます。
| フラグ名 | 主な役割 | SAN ログへの影響 |
|---|---|---|
EDITF_AUDITCERTTEMPLATELOAD | CA がテンプレートを読み込んだ際の情報を監査ログに残す（テンプレート変更の追跡など） | SAN の有無・内容には直接関係しない |
EDITF_ATTRIBUTESUBJECTALTNAME2 | リクエスト属性として送られてきた SAN を、サブジェクト代替名として処理・証明書に反映する | 属性 SAN を証明書・イベント 4886 / 4887 の情報に載るようにする鍵となる |
今回 SAN をログに出したい場合、EDITF_AUDITCERTTEMPLATELOAD だけでは不充分で、EDITF_ATTRIBUTESUBJECTALTNAME2 を追加で有効化する必要がある、というのがポイントです。
クライアント側：SAN を含んだ証明書要求を送る
CA 側で属性 SAN を受け付ける設定にしても、クライアントが SAN を含んだ要求を送ってこなければ意味がありません。ここでは代表的な 2 パターンを紹介します。
パターン 1：SAN を「属性」として送る（EDITF_ATTRIBUTESUBJECTALTNAME2 が必要）
certreq で INF ファイルを使う場合、SAN を [RequestAttributes] セクションに書くと、「属性 SAN」として CA に渡されます。これは EDITF_ATTRIBUTESUBJECTALTNAME2 を有効にしない限り無視されます。
; request.inf (属性 SAN 版)
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=example.contoso.com"
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
RequestType = PKCS10
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
[RequestAttributes]
SAN = "dns=example.contoso.com&dns=www.contoso.com"
certreq -new request.inf request.req
certreq -submit request.req issued.cer
このパターンでは、
- CA の
policy\EditFlagsにEDITF_ATTRIBUTESUBJECTALTNAME2が有効であること - テンプレート側が SAN を拒否するような特別な制限を持っていないこと
が前提となります。
パターン 2：SAN を「拡張」として埋め込む（フラグ不要）
別の書き方として、SAN を「証明書拡張（2.5.29.17）」としてリクエストに埋め込む方法があります。この場合は CA 側の EDITF_ATTRIBUTESUBJECTALTNAME2 に依存しません。
; request.inf (拡張 SAN 版)
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=example.contoso.com"
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
RequestType = PKCS10
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=example.contoso.com&dns=www.contoso.com"
どちらのパターンを採用するかは「利用しているツールや申請フロー」に依存します。代表例をざっくり整理すると次のようになります。
| 申請方法 | SAN の渡し方 | EDITF_ATTRIBUTESUBJECTALTNAME2 の必要性 |
|---|---|---|
certreq -new + [RequestAttributes] | 属性 SAN | 必要 |
certreq で [Extensions] に 2.5.29.17 を記述 | 拡張 SAN | 不要 |
| 一部の GUI ツール（MMC の証明書スナップインなど）で SAN を追加プロパティとして指定 | 実装によって属性 SAN になるケースあり | 状況による（SAN が属性なら必要） |
| 自動登録（オートエンロール）＋ AD 上の DNS 名や UPN を SAN に利用 | テンプレートとディレクトリ情報から拡張 SAN を構築 | 通常は不要 |
「どのツールで申請しているか」「そのツールが SAN を属性で送るのか、拡張で送るのか」を一度テスト環境で確認しておくと、安全な運用設計がしやすくなります。
テンプレート側の前提条件も確認する
CA のフラグだけでなく、証明書テンプレートの設定も SAN の扱いに大きく影響します。
サブジェクト名の設定方法
テンプレートの「サブジェクト名」タブ（または同等の設定）では、一般的に次の 2 パターンがあります。
| 設定 | 特徴 | SAN の入り方 |
|---|---|---|
| ディレクトリ情報から構築 | CN, DNS, UPN などを AD 属性から自動で取得 | メールアドレスや UPN など、テンプレートで許可したもののみ自動で SAN に入る |
| サブジェクト名を申請時に指定 | 要求側が CN や SAN を自由に指定できる | リクエストに含まれる SAN（属性／拡張）がそのまま採用される可能性が高い |
特に Web サーバー証明書などで 任意の DNS 名を SAN に入れたい場合、後者の「サブジェクト名を申請時に指定」を使う構成になっていることが多いでしょう。この組み合わせは柔軟な反面、後述する ESC6 などのセキュリティリスクにも直結するため、権限設計が非常に重要です。
Security ログで SAN を確認する具体的な手順
ここまでの前提が整ったら、実際に SAN がイベントログに出ているかを確認します。
必要な監査ポリシーと CA 側設定
以下が有効になっていることを確認します。
- 詳細監査ポリシーの「オブジェクト アクセス > 証明書サービス」が Success / Failure で有効
- CA コンソール（certsrv.msc）> CA のプロパティ > 「監査」タブで
「証明書要求の発行および管理」「証明書サービスの構成変更」など、必要な項目にチェックが入っている
確認するイベント ID
AD CS の証明書要求関連で特に重要なのは、次の 2 つです。
| イベント ID | 概要 | ポイントとなるフィールド |
|---|---|---|
| 4886 | Certificate Services received a certificate request. （CA が証明書要求を受信） | Requester, Request ID, Attributes（属性 SAN がここに出る） |
| 4887 | Certificate Services approved a certificate request and issued a certificate. （CA が要求を承認し証明書を発行） | Subject, Attributes, Certificate Extensions（SAN が拡張として出るケースあり） |
イベントビューアーで「セキュリティ」ログを開き、「現在のログをフィルター」で 4886,4887 を指定すると、対象の証明書要求をすばやく絞り込めます。
実際の確認フロー
- CA 上で EDITF_ATTRIBUTESUBJECTALTNAME2 を有効化し、CA サービスを再起動
- SAN を含んだリクエストを送信（テスト用に INF + certreq で十分）
- 証明書が発行されたら、CA の Security ログで該当の 4886 / 4887 を確認
- イベントの [詳細] タブ（XML 表示）で、
AttributesやCertificate Extensionsの中にdns=example.contoso.com等の SAN 記述が含まれているかをチェック - 発行済み証明書ファイルを
certutil -dump issued.cerで確認し、
「X509v3 Subject Alternative Name」に同じ値が入っていることを検証
この一連の確認が通れば、「リクエスト → CA → 証明書 → 監査ログ」まで SAN が途切れずに流れていることが確認できます。
セキュリティ影響：EDITF_ATTRIBUTESUBJECTALTNAME2 と ESC6 の関係
ここまで読むと「とりあえず EDITF_ATTRIBUTESUBJECTALTNAME2 を全部の CA に入れればよいのでは？」と思いがちですが、実はこのフラグは 誤った組み合わせで使うと危険な構成になり得ます。
ESC6（SAN を悪用した権限昇格）の概要
近年の AD CS 攻撃リサーチでは、CA 設定とテンプレートの組み合わせに起因するさまざまな「ESC（Enterprise Security Control）」が整理されています。その中で EDITF_ATTRIBUTESUBJECTALTNAME2 が関係するものが ESC6 です。
要点だけ抜き出すと、次の条件が揃ったときに危険度が高まります。
- CA の
policy\EditFlagsに EDITF_ATTRIBUTESUBJECTALTNAME2 が有効 - 「サブジェクト名を申請時に指定」するテンプレートに、
Client Authentication / Smart Card Logon など「ユーザー認証」に使える EKU が含まれている - そのテンプレートに対して、一般ユーザー（Domain Users 等）に Enroll 権限 が広く付与されている
この状況だと、攻撃者（通常権限ユーザー）でも「SAN に別ユーザーの UPN（[email protected] など）を埋めこんだ証明書」を取得できる可能性があり、その証明書を用いて 別人になりすましてドメインにログオン できてしまいます。
最近の Windows Update により一部の攻撃パスは制限されたものの、
「CA フラグの有効化＋テンプレート権限の緩さ」という根本問題が解消されたわけではない点に注意が必要です。
EDITF_ATTRIBUTESUBJECTALTNAME2 を安全に使うための対策
とはいえ、SAN ログの可視化や一部の業務要件のために、このフラグを有効化したいケースもあるでしょう。その場合は、次のような対策をセットで検討することを強くおすすめします。
- 認証用途テンプレートでは「サブジェクト名を申請時に指定」を避ける
→ クライアント認証・スマートカードログオン系テンプレートは、原則「ディレクトリ情報から構築」にし、SAN に任意の UPN を入れられないようにする。 - 「申請時に指定」テンプレートの Enroll 権限を最小化
→ Web サーバー証明書テンプレートなどは、サーバー管理者グループや特定のサービスアカウントに限定する。 - 発行に管理者承認を要求
→ 高リスクなテンプレートには「証明書管理者の承認が必要」要件を設定し、SAN の妥当性を人間の目でチェックする。 - 監査ログを活用して異常な SAN を検出
→ SIEM 等で 4886 / 4887 を集約し、AdministratorやDomain Adminsを含む SAN などを検知ルールにする。
AD CS はドメイン全体の信頼の根幹となるコンポーネントです。ログ可視化のためだけに安易にフラグをオンにするのではなく、「テンプレート設計」「権限」「監査」の 3 点セットでリスクをコントロールすることが重要です。
運用上の追加ポイント：ログ保全とモニタリング
SAN をログに出せるようになったら、次は「そのログをいかに活かすか」です。いくつか運用面の tips を挙げます。
Security ログの容量と保存期間を見直す
AD CS の監査を有効にすると、4886 / 4887 をはじめとした多数のイベントが Security ログに記録されます。ログ容量が小さいままだと、重要なイベントがすぐに上書きされてしまいます。
- ドメイン コントローラー ポリシーなどで Security ログ最大サイズ を増やす
- 古いログを自動アーカイブするか、SIEM などに 転送・保管 する
- CA サーバー専用のログ収集ルールを用意し、AD CS 関連イベントを明示的にタグ付け
監視クエリ・アラートの例
各製品ごとにクエリ言語は異なりますが、発想としては次のようなものが役に立ちます。
- 短時間に大量の SAN 付き証明書が発行されていないか
- 通常と異なる端末／アカウントから SAN 付き証明書が申請されていないか
- SAN に別アカウントの UPN や高権限アカウント名が含まれていないか
AD CS を狙う攻撃は、いまや「レッドチーム向けの特殊なテクニック」ではなく、一般的な侵害パターンの一つとして扱われています。監査ログ上での振る舞いを把握し、検出・対応フローをあらかじめ設計しておくと安心です。
よくある質問とハマりどころ
Q1. EDITF_ATTRIBUTESUBJECTALTNAME2 を有効化すると、既存テンプレートが勝手に書き換わる？
書き換わりません。このフラグはあくまで CA のポリシーモジュール（policy.dll）の挙動を変えるものであり、テンプレートオブジェクトそのもの（サブジェクト名の作り方、有効期間、EKU など）は変更されません。
ただし、「申請時にサブジェクト名を指定」＋「Client Auth 系 EKU」＋「Enroll 権限ゆるゆる」といったテンプレートが既に存在する場合、そのテンプレートが急に危険になる可能性はあるため、事前の棚卸しと権限見直しは必須です。
Q2. サーバー再起動は必須？
不要です。フラグの変更はレジストリ（HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CA 名>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags）に書き込まれ、CA サービスの再起動で読み込まれます。
Q3. SAN を完全に禁止したい場合はどうする？
極端な話、
certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2でフラグをオフにし、属性 SAN を一切受け付けない- テンプレートから「Subject Alternative Name」関連の設定を削除し、SAN 自体を使わない設計にする
という方針も技術的には可能です。
ただし現代の TLS 運用では SAN はほぼ必須であり、完全禁止は現実的ではありません。より現実的なのは、
- サーバー証明書では SAN を許容しつつ、クライアント証明書では厳格に制限する
- SAN を自由に指定できるテンプレートの数を最小限にする
といった「用途別の設計」を行うことです。
Q4. 証明書の SAN には入っているのに、イベント 4886 / 4887 に出てこないことはある？
あります。OS バージョンやパッチレベルによって、イベントログにどこまで拡張情報を表示するかが微妙に異なるケースがあります。また、SIEM 側で取り込みスキーマの都合で SAN が捨てられている（または別フィールドにマッピングされている）こともあります。
その場合は、
- まず CA ローカルのイベントビューアーで XML ビューを確認し、本当にイベントに載っていないかを確認
- 載っているのに SIEM で見えない場合は、ログ転送・パーサーの設定を見直す
という手順で切り分けるとスムーズです。
Q5. SAN をログに出すなら、EDITF_ATTRIBUTESUBJECTALTNAME2 は必須？
「属性として送られてくる SAN」をログに出したいなら必須です。一方、最初から拡張 SAN として埋め込んでくるクライアントだけを相手にするのであれば、このフラグなしでも証明書・ログ両方に SAN が見えるケースがあります。
しかし現実には、ツールやスクリプトの歴史的経緯もあり、「属性 SAN を使う申請」が残っている環境も多いです。その場合、少なくともテスト環境で挙動を確認したうえで、フラグの有効化とテンプレート設計の見直しをセットで検討することをおすすめします。
すぐに試せる検証手順（まとめ）
ここまでの内容を踏まえ、テスト環境で「SAN がログに出ること」を最短で確かめるための手順を整理します。
- CA サーバーで以下を実行
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 net stop certsvc net start certsvc - SAN を含む INF ファイルを作成（属性版または拡張版のいずれか）
certreq -new→certreq -submitで証明書を発行- CA の Security ログで 4886 / 4887 をフィルターし、
対象イベントのAttributes/Certificate Extensionsを確認 - 発行済み証明書を
certutil -dumpで開き、SAN 拡張に同じ値が入っていることを確認
この 5 ステップが問題なく通れば、「監査は有効だが SAN が出ない」という典型的な悩みはほぼ解消できます。
まとめ：SAN をログに出すには「監査」だけでは足りない
最後に、この記事の要点を整理します。
- 監査ポリシーや EDITF_AUDITCERTTEMPLATELOAD を有効にしただけでは、SAN はログに出ない。
- 多くのツールは SAN を「リクエスト属性」として CA に渡すため、
CA 側で EDITF_ATTRIBUTESUBJECTALTNAME2 を有効にしないと、証明書にもログにも反映されない。 - クライアント要求に実際に SAN が含まれていること、およびテンプレート設定が SAN を許容していることを確認する。
- SAN をログに出せるようになると、AD CS 攻撃の検知や不正な証明書発行の追跡に大きく役立つ一方、
設定次第では ESC6 などの権限昇格リスクが高まるため、テンプレート設計と権限管理が重要。 - CA サービス再起動のみで反映され、OS 再起動は不要。まずはテスト環境で動作とログ出力を確認するのが安全。
「AD CS の監査は有効なのに SAN が見えない」という状況は、単なる設定漏れに見えて、実は PKI 全体の設計・セキュリティを見直す良いきっかけでもあります。本記事を参考に、SAN のログ出力だけでなく、AD CS 周りの権限・テンプレート・監査を総合的に見直してみてください。
コメント