I have a publicly signed UCC for LDAP over SSL in a test domain. It contains the Server Authentication OID Extension and works fine on a 2008 R2 DC in the same domain. The CSR was generated on the 2008 R2 Server, but contains a subject name matching the FQDN of the domain and SANs for the 2008 R2 DC's FQDN and the 2003 DC's FQDN.
When I attempt to connect from another system on the domain via ldp.exe to the 2008 R2 DC via port 636 with SSL, it works fine. However, connecting to the 2003 DC returns:
----------- 0x0 = ldap_unbind(ld); ld = ldap_sslinit("testdc01", 636, 1); Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3); Error 81 = ldap_connect(hLdap, NULL); Server error: <empty> Error <0x51>: Fail to connect to afgtestdc01. ld = ldap_sslinit("testdc01", 636, 1); Error 81 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3); Error 81 = ldap_connect(hLdap, NULL); Server error: <empty> Error <0x51>: Fail to connect to testdc01.
I have raised the SChannel logging level to "Log informational and success events", the most verbose level available. However, the only event when attempting to connect is
36867: Creating an SSL server credential.
To avoid a known issue where an incorrect certificate may be selected by SChannel, I ensured the certificate is the only one in the Computer's local personal store. I moved the intermediate and root CAs to their respective computer stores. The certificate shows as valid in MMC.
What am I missing?
Update: Per the CA's recommendation, I've created a duplicate certificate with the Subject Name matching the FQDN of the server, as opposed to matching it in the SAN. This did not yield any better results.
netstat -n -p tcp does not show 636 as listening, though portqry from another 2003 server returns that 636 is listening. I am looking into why this may be.
I have also tried testing with ldp.exe on the 2003 DC itself, and I still cannot connect.