AD証明書サービスでLDAPS接続用証明書を発行する

# 本記事について
某製品を扱う際にADドメインサービス（AD DS）への接続にLDAPSを利用する必要があり、
かつAD証明書サービス（AD CS）で発行したサーバ証明書の管理をおこなう必要があったため、
AD CSの構築～証明書発行とLDAPS接続までの流れとポイントをまとめておきます。

# AD CSの構築
## 目指す構成
今回目指す構成は以下とします。
- AD CSはエンタープライズCAではなくスタンドアロンCA（サーバもWORKGROUPで構築）
- AD DS用サーバ証明書の有効期限は100年
- AD DS用サーバ証明書にはSANを設定
- 証明書の要求・発行にはAD CSのWeb登録サービスを利用

## AD CS構築の流れ
構築は以下の流れで進めます。
インストールと構成完了までは特に迷うこともなく画面の指示に従って進められると思います。
※インストール、構成の完了後にサーバの再起動は発生しません。
1. サーバーマネージャーからActive Directory証明書サービスをインストール
2. Active Directory証明書サービスを構成
3. AD CSが発行する証明書の有効期限を変更

## AD CS構築時のポイント
### サーバ証明書の要求・発行のためのWeb登録サービスをインストールする
AD CSのインストール・構成時に"証明機関"に加えて"証明機関Web登録"を選択します。
これによってIISもインストール・構成され、AD CSサーバで証明書の要求・発行を管理するWebサービスが起動します。
![install_01.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/b36e196c-9e68-a514-fb0d-6b91736e7f66.jpeg)<br>
また、私の環境の問題かもしれませんが、AD CSサーバをWindows Server 2025で構築していたところ、
IISの設定でSSLを必須としているものの証明書がバインドされておらず、http、httpsともに接続できない状況でした。
Webサービス（"http(s)://<AD CSサーバ>/certsrv/"）にアクセスできなかった場合は、サーバ証明書をバインドするかhttpでの接続を許可するようにIISの設定を変更しましょう。
なお、別の環境でWindows Server 2016や2019で同様のインストール・構成をおこなった際は既定の状態でアクセスできていましたので、使用した2025のISOの一時的な問題かもしれません。

### ルートCA証明書を100年以上で設定する
今回サーバ証明書の有効期限を発行時から100年としたいため、ルートCA証明書も100年以上で発行します。
ルートCA証明書からの証明書チェーンをもとにサーバ証明書の検証がおこなわれるため、二つの証明書がいずれも失効していないことが証明書を有効な状態に保つために必須です。
※中間CAを挟む場合はもちろんそちらも考慮します。
※今回は検証のため100年としていますがセキュリティリスクを考慮して設定しましょう。
![rootca100.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/284ee4dd-2b09-041b-8199-7a2ed7b4d887.jpeg)

### 発行する証明書の有効期限を設定する
AD CSで発行する証明書はエンタープライズCAでは2年、スタンドアロンCAでは1年がデフォルトです。
今回は100年後としたいため、有効期限の設定を変更します。
この設定は以下のレジストリキーを変更し、"certsvc"サービスを再起動することで反映します。
`HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\<AD CS名>`
こちらの設定方法の詳細は以下のMicrosoftのドキュメントを参照します。
[Microsoft Learn | 証明機関によって発行される証明書の有効期限を変更する](https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/change-certificates-expiration-date)

# AD DS用証明書の発行・LDAPS接続
## 証明書の発行～インストールの流れ
証明書の発行～AD DSでの証明書発行は以下の流れで進めます。
1. infファイルを作成
2. AD DSサーバで証明書要求ファイルを作成
3. AD CSのWeb登録サービスで証明書を要求
4. AD CSの証明機関で証明書を発行
5. AD CSのWeb登録サービスで証明書と証明書チェーン（ルートCA証明書）をダウンロード
6. AD DSサーバにルートCA証明書とサーバ証明書をインストール
7. AD DSサーバを再起動

## 証明書の発行～インストールのポイント
### SAN属性を追記したinfファイルの設定
LDAPS接続用のサーバ証明書の構築については以下のMicrosoftのドキュメントにテンプレートや手順の説明があります。
[Microsoft Learn | サードパーティの認証局を使用してSSL経由のLDAPを有効にする](https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority)
ただ、今回はSAN属性を追記します。
SAN属性の追記についてはこちらもMicrosoftのドキュメントに記載があり、3通りの方法があります。
しかし、セキュリティの問題から現在推奨されているのは1の手法でinfファイルのExtensionsセクションにSANに設定したいFQDNをdnsに記載します。
[Microsoft Learn | Customizing RequestPolicy.inf for your environment](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)
    1. Add a SAN extension in text format to the Extensions section of RequestPolicy.inf.
    2. Add a SAN extension in base64-encoded ASN.1 format to the Extensions section of RequestPolicy.inf.
    3. Add a SAN attribute to the RequestAttributes section of RequestPolicy.inf.

**サンプルのinfファイル**
Subjectと_continue_の2行でAD DSのFQDNを置換してください。
```
;----------------- request.inf -----------------

[Version]

Signature="$Windows NT$

[NewRequest]

Subject = "CN=<AD DSのFQDN>"
KeySpec = 1
KeyLength = 2048
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=<AD DSのFQDN>&"

;-----------------------------------------------
```

### 証明書要求ファイルの作成は必ず証明書インストール対象サーバでおこなう
証明書要求ファイルを作ること自体はどの環境でおこなうこともできますが、要求ファイル作成時に秘密鍵が作成され実行したサーバ内に保存されるため必ず対象サーバで実行しましょう。
`certreq -new request.inf request.req`

### 証明書インストール後にAD DSの再起動をおこなう
ドキュメントにも明記されていますが、証明書インストール後ドメインサービスに反映するためにAD DSサーバの再起動が必要になります。
運用環境で実行する場合は留意しましょう。

## LDAPS接続
最後にldp.exeを使ってLDAPS接続をテストする手順を記載しておきます。
通常AD DSを構築した際の既定の設定では非SSL接続のみがサポートされており、TCP/389でLDAP接続を受け付けています。
上記手順に従って証明書をインストールすることでSSLで暗号化されたTCP/636でのLDAPS接続が可能になります。

ldp.exeはWindowsのリモート管理ツール（Active Directory Domain Servicesおよびライトディレクトリサービスツール）に含まれていますので、クライアントOS、サーバOS問わず利用可能です。

今回は以下のOU内のユーザーアカウントを使ってOUの情報をLDAPS接続経由で検索してみます。
`ドメイン：shtest.local`
`OU名：azlocalAA`
`ユーザーアカウント：lcmadminAA`

1. ldp.exeを起動し、[接続]からAD DSのFQDNとポート636を指定し、SSLにチェックを入れて接続します。
![ldp_con.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/b80508cc-80cb-83e1-7a27-8b11646df4f6.jpeg)

2. [バインド]から"資格情報によるバインド"を選択し、ユーザー、パスワード、ドメイン情報を入力します。
![ldp_bind.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/9ec74448-b26a-fa09-47fc-812ceee29997.jpeg)

3. [検索]から上記OUの情報を入れて検索します。成功するとOU内のオブジェクト（今回の例ではユーザーアカウントのみ）が見えてきます。
![ldp_search.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/58e07650-e260-3d2a-e2b5-91a3ac953ee6.jpeg)
![ldp_search_result.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/55256900-10b0-065f-bd3e-ff2892c322b1.jpeg)

# まとめ
Microsoftのドキュメントの情報は少し古くなっていたり、若干わかりづらかったりもしますが、必要な情報は一通り説明されています。
また、各ポイントを解説してくださっているサイトも多々ありますが、今回の用途で通しでのメモが欲しくまとめてみました。同じケースでの構築の参考になれば幸いです。