LDAPS Microsoft Active Directory Multiple Certificates RFC6125

We have an Microsoft Active Directory Domain with a large pool of domain controllers (DC) that are are setup with LDAP. These are all setup with LDAPS and uses Certificate Services via a template to setup a certificate with the domain name (i.e. test.corp) in the Subject Alternate Name (SAN) for the LDAPS server to serve.

Since these are DC’s, DNS is setup in a pool for each these systems to respond to requests to test.corp in a round robin fashion.

Each of these DC’s have multiple templates and multiple certificates in the Local ComputerPersonal Certificate Store.

Upon testing, using a nodejs module, ldapjs when making a LDAPS request using the domain name, test.corp we notice that a handful of servers fail with the following message:

Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match
certificate’s altnames: Host: test.corp. is not in the cert’s
altnames: othername:, DNS:.test.corp

As we investigated we found that these handful of LDAPS servers are serving the incorrect certificate. We determined this by using the following command

openssl s_client -connect .test.corp:636

If you take the certificate section of the output and put it in a file and use a tool such as the Certificate manager or certutil to read the file, you can see the certificate is not the correct one. (It does not have the domain "test.corp" SAN). We also verified this by comparing the Serial Numbers

As we investigated, since we have DC’s that have multiple certificates in the Local ComputerPersonal Certificate store, we came across the following article:

https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

It suggests putting the certificate from the local computerPersonal certificate store to the Active Directory Domain ServicePersonal store. We followed the steps outlined but we found the same results.

Upon further investigation, it was suggested to use a tool called ldp or adsiedit. We then proceeded to use these tools and spoofed the local machine’s host file we were doing the test from, to point the domain (test.corp) to the ip’s of one of the DC’s that are giving us trouble. After a restart to clear any cache we tested the "ldp" and "adsiedit" tools to connect to test.corp. These systems did not report any errors.

We found this odd, we then ran the openssl command to see what certificate it was serving from this same system and we found it was still serving the incorrect certificate.

Upon further research, it appears that the "ldp" upon selecting the SSL checkbox and "adsiedit" tools were not compliant with RFC6125, specifically B.3

https://www.rfc-editor.org/rfc/rfc6125#appendix-B.3

, which basically states the identity of the certificate must match the identity of the request otherwise the handshake would fail. This identity verification is done by using the certificate common name (CN) or the SAN.

Based on this appears the tools "ldp" and "adsiedit" are not conforming to the RFC6125 standard.

All this to say, we need to first fix the handful of domain controllers that are serving the correct certificate. We are open to suggestions since we have been working on this problem for the past few months. Second, is there a way to get the MS tools in question to work to the RFC6125 standard?

Note: If I have posted this to the incorrect board (i.e. stack overflow), please let me know and I will remove and repost to the correct location.