はじめに

Active Directory 証明書サービス (AD CS) を運用していて、証明書を発行する場面があると思います。
その際に、以下のようなシチュエーションで SAN（サブジェクトの別名）を追加の情報として付加する必要があります。知る人ぞ知る話なのかなと思います。
AD CS の証明機関を使って SAN を付加する方法は、広く公開され知られている方法なのですが、セキュリティ的に問題があるとの情報もあるため、SAN の付加をする複数の方法に関して、まとめてみました。

SAN シチュエーション 1：Google Chrome 問題の対策

IIS や、Apache、Azure App Service などの Webサイト(HTTPS) で利用する証明書を、AD CS を使って発行する場合には注意が必要です。
AD CS で発行したサーバー証明書を Webサイト側へインポートして、ルート証明書をクライアントPC にインポートすれば、問題なく利用できるハズなのですが、 Chrome だけエラーになってしまう・・・という問題です。
この場合は、SAN情報として、Webサイトの URL を追加することで対処できます。

（事象の説明：Google Chrome で自組織のCAで署名したSSL証明書のサイトにアクセスすると NET::ERR_CERT_COMMON_NAME_INVALID エラーメッセージが表示される）
https://www.ipentec.com/document/windows-chrime-error-net-err-cert-common-name-invalid-using-ssl-certificate-signed-with-local-ca

（対処例1：SAN(Subject Alternative Name)フィールドを含むSSL証明書を作成する）
https://www.ipentec.com/document/windows-server-create-ssl-certification-including-san-dns-name-field

（対処例2：Active Directory 証明書サービスで発行した証明書が Chrome だけエラーになる）
https://mseeeen.msen.jp/certificate-issued-by-active-directory-certificate-services-fails-only-in-chrome/

私も３年前に、App Service でカスタムドメインを使った Webサイトを検証したことがあり、その際に AD CS を使って証明書を作成した時に、Chrome だけ参照できないという問題に遭遇しました。その際に上記で紹介させていただいた例1 や例2 のサイトを見つけて参考にさせていただきました。問題解決にあたって、大変参考にさせていただき感謝しております。

SAN シチュエーション 2：802.1x 用クライアント証明書

有線LANや、無線LAN (WiFi) を認証する方法として、802.1x 認証という仕組みがあります。
この 802.1x 認証には、「IDとパスワード」を使った認証 (EAP-MS-CHAPv2) と、「クライアント証明書」を使った認証 (EAP-TLS) という２種類の選択肢があります。

このうち「クライアント証明書」(EAP-ELS) を使った認証を行う場合には、クライアント証明書に SAN情報として「クライアントPC の FQDN」または「サインインするユーザーの UPN」を追加する必要があります。

（例：クライアント証明書の最小要件）
https://learn.microsoft.com/ja-jp/windows-server/networking/technologies/nps/nps-manage-cert-requirements#minimum-client-certificate-requirements
（抜粋）
ユーザー証明書の場合は、証明書のサブジェクトの別名 (SubjectAltName) 拡張にユーザープリンシパル名 (UPN) が含まれていること。
コンピューター証明書の場合は、サブジェクトの別名 (SubjectAltName) 拡張にクライアントの完全修飾ドメイン名 (FQDN) (DNS 名) が含まれていること。

802.1x 認証については、以下でも解説記事を書いていますので、参考にしていただければと思います。

以下は、802.1x 認証のクライアント証明書の作成手順です。
NPS サーバーと組み合わせて、動作検証まで済んでいますので、参考にしてみてください。

SAN シチュエーション 3：１つの証明書をマルチドメインで利用したい場合

SAN を付加するシチュエーションで、私が知っているものは上記の３点だけですが、他にも SANを付加することで対応するサービスがあるかもしれません。
そのように SAN を必要とするその他のサービスであっても、本記事に記載したセキュリティのリスクは同程度あるものと思います。

セキュリティについての懸念

前章で紹介した記事にも記載されていますが、AD CS 上で "EDITF_ATTRIBUTESUBJECTALTNAME2" の設定を有効にして SAN を付加する方法が紹介されています。
しかしながら、この方法はセキュリティ的に問題があるようです。

私は、以下のような海外のサイトで見かけてこのリスクを知りました。
（例1）
https://www.paloaltonetworks.com/blog/security-operations/detecting-active-directory-certificate-services-abuse-with-cortex-xdr/
（例2）
https://www.gradenegger.eu/?p=1486#more-1486

判断の決め手は、以下の Microsoft 公開情報です。
ココにも、"EDITF_ATTRIBUTESUBJECTALTNAME2" の設定を有効にすることは推奨しない行為であることが書かれています。海外のサイトで書かれていることは、本当のようです。

（URL：環境に合わせて RequestPolicy.inf をカスタマイズする）
https://learn.microsoft.com/ja-jp/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff625722(v=ws.10)#customizing-requestpolicyinf-for-your-environment

上記サイトの解釈ですが、SAN情報を追加する方法は、①～③ の３通りあって、このうち ③ の方法を採用することは、偽装攻撃のリスクがあるので辞めましょう・・・という事のようです。③ の行為とは「シチュエーション 1 」で紹介した記事に記載されている方法と一致しています。

偽装攻撃のリスクとは？

先に紹介した海外のサイトの説明によると、AD CS の脆弱性を発見するツールを使う事でこの脆弱性をみつけることができ、攻撃者はこの脆弱性を突いてドメインの管理者権限を奪取する事が可能である・・・との説明がありました。

以下は、海外のサイトの説明からの抜粋です（機械翻訳）

通常のユーザーが継続的に存在するのは良いことですが、攻撃者にとって重要な目標は、ネットワーク内でより高い特権を取得することです。いくつかの証明書テンプレートの設定とシナリオにより、これが可能になります。

特権のないユーザーが登録エージェントになれるテンプレートに登録できる場合、特権昇格が可能になる可能性があります。登録エージェントは基本的に、別のエンティティの「代理」として証明書を要求するために使用され、これにより特権のないエージェントが高い特権のユーザーの証明書を登録できるようになります。

別のユーザーとして登録するもう 1 つの方法は、SAN を使用する方法です。これについては、後ほど悪用シナリオのフローで説明します。

証明機関 (CA) Web 登録役割サービスなど、いくつかの登録インターフェイスがあります。Web 登録サービスは、HTTP および NTLM 認証を使用します。つまり、悪用者が自分自身に NTLM 認証を強制できる場合、認証を Web 登録に中継できます ( NTLM リレー)。リレーにより、証明書を登録し、それを強制 NTLM ハッシュユーザーとして認証に使用できるようになります。

その他の悪用の可能性としては、CES\CEPなどの他の登録サービスをNTLM にダウングレードし、認証にNTLM リレーを使用することが考えられます。AD CS オブジェクトまたはセキュリティ設定を変更して、EKU、登録権限などを有効にします。

次に、権限昇格のために AD CS を悪用するシナリオに従います。

偽装攻撃の回避策

前章の（URL：環境に合わせて RequestPolicy.inf をカスタマイズする）の図で紹介した ③ の方法（"EDITF_ATTRIBUTESUBJECTALTNAME2" を有効）は使わないようにします。
つまり、① または ② の方法を使うようにします。

② の方法は、旧OS 用になるので、採用すべきは ① の方法になると思います。
私の方では ① の方法で証明書を作って、Chrome や 802.1x の証明書を作成し動作検証することができています。今後は、① の方法を使っていきましょう。

証明書登録ウィザードを利用するのも良い回避策となりそうです。
802.1x 認証の場合ですが、手動で SAN情報の付加をしなくてもクライアント証明書を展開することができそうです。
（URL：証明書登録ウィザードの使用）
https://learn.microsoft.com/ja-jp/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff625722(v=ws.10)#using-the-certificate-enrollment-wizard

偽装攻撃の軽減策

以下は、③ "EDITF_ATTRIBUTESUBJECTALTNAME2" を有効をする判断をした場合のリスク軽減策を考えてみました。リスクをキチンと理解した上で回避策を講じて利用する分には良いのではないかと思います。

AD CS の利用は、検証用途のみに留める
検証時だけ AD CS を使うけど、本番運用は公的証明機関や専用アプライアンスを使うという感じで、うまく使い分けすれば良いと思います。
※専用アプライアンスというのは、以下の NetAttest EPS のような製品のことです。
https://www.soliton.co.jp/products/category/product/network/netattest_eps/
「証明書 Web 登録」をインターネットには公開しない
まあ、これはいわずもがなですね。利便性のために公開してしまっている場合は、このリスクを認識して、非公開にすることを推奨します。
「証明書 Web 登録」を利用するが、アクセスを Windows Firewall で制限する
管理用PC からしかアクセスできないようにすれば、リスクは制限下に置かれるので、安全です。
「証明書 Web 登録」は無効化する。
この機能は使わなくします。そうすることで、不特定多数の人からの申請はなくなり、管理者が AD CS サーバー上で意図したコマンドを実行することで証明書の発行が行えます。

「証明書Web登録」を使わないようにするだけで、リスクを軽減はできていると思うのですが、100% リスクをカバーし切れているかは、私も断言できません。
私としては、検証用途だけに留めておくのが良いかな・・・と思います。

SAN情報追加のための .inf 作成手順について

以下のサイトを参照ください（図のあとに解説を記載しています）
（URL：To create a RequestPolicy.inf file）
https://learn.microsoft.com/ja-jp/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff625722(v=ws.10)#to-create-a-requestpolicyinf-file

以下の URL の手順で説明されていますが、上記の抜粋した図のうち、① ② ③ のすべての方法が記載されているので不要な部分を削除するように指示されているようです。
わかりずらすぎる・・・
（URL：環境に合わせて RequestPolicy.inf をカスタマイズするには）
https://learn.microsoft.com/ja-jp/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff625722(v=ws.10)#to-customize-requestpolicyinf-for-your-environment

AD CS のインストール

以下の記事で、AD CS のインストールを Step by Step で紹介しています。
なお、この手順では、「証明書 Web 登録」を有効化しています。

"EDITF_ATTRIBUTESUBJECTALTNAME2" の有効化手順

リスクを理解した上で ③ "EDITF_ATTRIBUTESUBJECTALTNAME2" を有効する場合は、この手順を実施してください。当然 ①、② の方法を選択した場合は、この章の手順は不要です。

AD CS サーバーに管理者アカウントでサインインします。
スタートボタンを右クリックして「Windows PowerShell（管理者」をクリックします。

　
開かれた PowerShell ウィンドウ上で、以下のコマンドを実行します。
certutil -setreg policy\editflags +EDITF_ATTRIBUTESUBJECTALTNAME2
　
続いて、以下のコマンドで AD CS のサービスの停止＆起動を行います。
net stop certsvc
net start certsvc
　
最終的に、以下のような実行結果となれば OK です。

証明書要求～証明書の発行

①、②、③ すべての場合で、この手順が必要です。
AD CS サーバーを構築して、クライアントPC 上で、.inf ファイルを作成できたら、以下の手順を参考にして、証明書要求～発行までの手順を実施してください。
（URL：Certreq.exe を使用した証明書の要求の作成）
https://learn.microsoft.com/ja-jp/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff625722(v=ws.10)#creating-a-certificate-request-by-using-certreqexe