LDAPを有効にするためにWindows2012 R2 / 2016サーバーにサブジェクト代替名（SAN）サーバー証明書をインストールすることを使用できますか？
r/sysadminからの投稿 に答えるが、自己答えするのに十分なカルマがありません：
LDAPを有効にするためにWindows2012 R2/2016サーバーにサブジェクト代替名（SAN）サーバー証明書をインストールすることを使用できますか？
または、すべてのDCに独自のSSL証明書が必要ですか？
ざっと読んだだけで、各DCには独自の証明書が必要であり、単一のDC証明書の[代替名]フィールドにすべてのSAN名を詰め込んでからインストールすることはできないと思います。すべてのDC。
以前は、DCは、特別にフォーマットされた共通の（すべてのDCにまたがる）自己署名証明書を使用して、データセンター内のAPCのLDAPSが認証できるようにしました。 Cisco UCSは、「トラストポイント」を作成するための自己署名証明書を受け入れません。 UCSで同じ機能を有効にするために、使用する証明書はチェーンする必要があるであると判断されました。テストの結果、ホスト証明書がチェーンされているルート証明書が有効なCAであるか、自己署名CAであるかは問題ではないことがわかりました。そのため、新しい自己署名CAを作成してから、DC LDAP証明書に署名することにしました。これは、サブジェクト代替名（SAN）の特別な要件を除いて、かなり標準的です。 LDAPSは、ドメイン名でアクセスされる複数のドメインコントローラー間で機能します。
Windowsツールを介して必要な証明書を生成するために最善の努力が払われましたが、それが可能であるとしても、文書化が不十分であるため、Linuxマシンで生成し、後でドメインにコピーするのが迅速であると判断しました。以下の方法では、「openssl x509」の「ミニCA」機能を使用して、完全なCA構造を設定せずに証明書を生成できます（ https://www.openssl.org/docs/apps /x509.html#SIGNING-OPTIONS ）。
標準的な手順に従って、CA証明書とCA証明書自体の秘密鍵を生成します。
openssl genrsa -des3 -out ldapCA.key 4096 openssl req -x509 -new -nodes -key ldapCA.key -days 3650 -out ldapCA.pem
SANのサポートに必要な v3_req セクションを含むホストLDAP証明書の証明書構成ファイルを作成します。
[req] distinguished_name = req_distinguished_name req_extensions = v3_req Prompt = no [req_distinguished_name] C = US ST = NC L = XXX O = YYY OU = ZZZ CN = [v3_req] basicConstraints = CA：FALSE keyUsage = nonRepudiation、digitalSignature、keyEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [ alt_names] DNS.1 = DNS.2 = DNS.3 = DNS.4 = DNS.5 =
上記のリクエスト構成を使用して正しい証明書の生成に繰り返し失敗した後、opensslのx509オプションがCSRから拡張機能を not コピーすることがわかりました（ http://openssl.6102.n7.nabble.com/Unable-to-create-Version-3-certificates-with-subjectAltName-using-my-own-CA-td46753.html#a46755 ）
OpenSSLには、CSRから証明書を作成する2つの方法があります。 'ca'＃元の最も完全な方法 'x509 -req'＃ 'データベース'などを使用しない単純化された方法。 構成ファイルの設定、特にcopy_extensionsを完全に使用するのは「ca」のみです。 'x509 -req'は、 拡張機能に構成ファイルを使用できますが、それ以外は使用できません。 CSRから拡張機能をコピーする場合は、「ca」を使用します。 「x509-req」を使用して、SANを含む拡張子を「x509-req」の時間に構成ファイルに入れることができます（「req- new'time）、 これはcrldpのようなCA関連の拡張機能には適していますが、通常はSANは証明書ごとに異なります。
これを修正するには、拡張子のみを含む2番目のファイルを作成する必要があります。<
basicConstraints = CA：FALSE keyUsage = nonRepudiation、digitalSignature、keyEncipherment extendedKeyUsage = serverAuth subjectAltName = DNS：、DNS：、DNS：、DNS：、DNS：
CSRファイルと拡張ファイルの両方に同じデータが必要であるかどうかは不明でしたが、両方で機能します。この時点で、CA、CAキー、証明書要求ファイル、および拡張ファイルを使用してホスト証明書を生成し、結果の証明書を検証できます。
openssl x509 -days 1460 -req -CA ldapCA.pem -CAkey ldapCA.key -CAcreateserial -in ldapSAN.csr -out ldapSAN.pem -extfile ext.txt openssl x509 -text -noout -in ldapSAN.pem
検証の出力は、それがv3証明書であり、CAによって署名されていることを示し、各DCのFQDNで満たされたSANセクションを示している必要があります。
証明書： データ： バージョン：3（0x2） シリアル番号：（） 署名アルゴリズム：sha1WithRSAEncryption 発行者：C =、ST =、L =、O =、OU =、CN =/emailAddress = 有効性 前ではない：2015年3月5日16:36:10 GMT 後ではない：3月4日16 ：36：10 2019 GMT 件名：C =、ST =、L =、O =、OU =、CN = 件名公開鍵情報： [...] X509v3拡張機能： X509v3基本制約： CA：FALSE X509v3キーの使用法： デジタル署名、非否認、キー暗号化 X509v3拡張キーの使用法： TLSWebサーバー認証 X509v3サブジェクト代替名： DNS：、DNS：、DNS：、DNS：、DNS： 署名アルゴリズム：sha1WithRSAEncryption [...]
証明書をインポートしてDCで使用するには、秘密鍵を使用してホスト証明書をpkcs12（pfx）形式でエクスポートする必要があります。
openssl pkcs12 -export -out ldapSAN.pfx -inkey ldapSAN.key -in ldapSAN.pem -certfile ldapCA.pem
最後に、CA証明書のパブリックバージョン（この場合はldapCA.pem）を信頼されたルート証明機関マシンアカウントのストアにインストールします。各ドメインコントローラー。これは、リモート管理ツールを使用して、各サーバーでローカルに、またはGPOを介して実行できます。次に、ホスト証明書と秘密鍵を各サーバーにインストールします。この must は、秘密鍵情報を使用したpfxインポートがリモートで実行できないため、ローカルで実行する必要があります。
CERTUTIL -f -p <パスワード> -importpfx ldapSAN.pfx
この時点で、DCは証明書を自動的に取得する場合があります（ http://support.Microsoft.com/kb/321051 ）：
最後に、Windows Server 2008以降のバージョンのドメインコントローラーがストア内で複数の証明書を検出した場合、 有効期限が最も遠い証明書を自動的に選択します。次に、現在の証明書が 有効期限に近づいている場合は、交換用の証明書をストアにドロップすると、AD DSは自動的に を切り替えて使用します。
私たちの場合、以前の証明書には新しい証明書の後に有効期限があったため、各ドメインコントローラーが新しい証明書を使用する前に古い証明書を削除する必要がありました。 LDAPサービスで使用されている証明書は、次の方法で確認できます（NAGIOSでもこれを確認できます）。
openssl s_client -connect <DCのFQDN>：636 -showcerts
出力には、上記で行った証明書の検証と同様の情報が含まれます。
この時点で、公開証明書を必要とするすべてのクライアントに公開証明書を提供できます。 CAのみを必要とするもの、ホスト証明書のみを必要とするもの、チェーン全体を含む単一のファイルを必要とするものがあります。
UCSとAPCの両方が、新しい証明書に接続するようにSRによって再構成されました。
w00t