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