AD CS で SAN (サブジェクトの別名) を追加するリスク

# はじめに
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/

:::note info
私も ３年前に、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 認証については、以下でも 解説記事を書いていますので、参考にしていただければと思います。

https://qiita.com/carol0226/items/f3bd546d74da609222dd

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

https://qiita.com/carol0226/items/ba5c9eb1ff0f27e8be3b

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

https://qiita.com/shadowhat/items/f71b2564dfed0319fbac

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

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

:::note alert
私は、以下のような海外のサイトで見かけて このリスクを知りました。
（例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 」で紹介した記事に記載されている方法と一致しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/c708a607-21ba-3252-ab5f-ce9dd81fc1a1.png)

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

以下は、海外のサイトの説明からの抜粋です（機械翻訳）
>通常のユーザーが継続的に存在するのは良いことですが、攻撃者にとって重要な目標は、ネットワーク内でより高い特権を取得することです。いくつかの証明書テンプレートの設定とシナリオにより、これが可能になります。<br>
特権のないユーザーが登録エージェントになれるテンプレートに登録できる場合、特権昇格が可能になる可能性があります。登録エージェントは基本的に、別のエンティティの「代理」として証明書を要求するために使用され、これにより特権のないエージェントが高い特権のユーザーの証明書を登録できるようになります。<br>
別のユーザーとして登録するもう 1 つの方法は、SAN を使用する方法です。これについては、後ほど悪用シナリオのフローで説明します。<br>
証明機関 (CA) Web 登録役割サービスなど、いくつかの登録インターフェイスがあります。Web 登録サービスは、HTTP および NTLM 認証を使用します。つまり、悪用者が自分自身に NTLM 認証を強制できる場合、認証を Web 登録に中継できます ( NTLM リレー)。リレーにより、証明書を登録し、それを強制 NTLM ハッシュ ユーザーとして認証に使用できるようになります。<br>
その他の悪用の可能性としては、CES\CEPなどの他の登録サービスをNTLM にダウングレードし、認証にNTLM リレーを使用することが考えられます。AD CS オブジェクトまたはセキュリティ設定を変更して、EKU、登録権限などを有効にします。<br>
次に、権限昇格のために AD CS を悪用するシナリオに従います。

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

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

:::note info
証明書登録ウィザード を利用するのも良い回避策となりそうです。
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 サーバー上で 意図したコマンドを実行することで証明書の発行が行えます。

:::note warn
「証明書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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/f95946d6-db50-b5d4-9e96-e818a17a123c.png)

以下の 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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/f6cac5c3-4ef1-e07c-ee44-dd6cc2e1c4a1.png)

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

https://qiita.com/carol0226/items/cb38ed3188c520bd9d64

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

1. AD CS サーバーに管理者アカウントでサインインします。
1. スタートボタンを右クリックして「Windows PowerShell（管理者」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/a11e7e98-c0a8-5199-cc2b-72f9bb5b4371.png)
　<br>
1. 開かれた PowerShell ウィンドウ上で、以下のコマンドを実行します。 
certutil -setreg policy\editflags +EDITF_ATTRIBUTESUBJECTALTNAME2
　<br>
1. 続いて、以下のコマンドで AD CS のサービスの停止＆起動を行います。
net stop certsvc
net start certsvc
　<br>
1. 最終的に、以下のような実行結果となれば OK です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/3505bf50-9fc9-4f99-c25b-01ab17007d19.png)

# 証明書要求～証明書の発行
①、②、③ すべての場合で、この手順が必要です。
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