0

I've got a configuration issue with my test domain controller (Server 2019) where I can't connect via 636 using LDP. (using the full domain name)

On 2008 and 2012 I didn't have to do any additional configuration; it just worked.

However, in 2019 is may appear that I need to manually configure an SSL cert for this to work. I found this article on MS: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-over-ssl-3rd-certification-authority and it appears that I need to get a public certificate for each domain that I will be connecting to (which will be a lot). If this is true, those certs would expire and I'm not sure what the effect will be (will it still work or fail?). If it will fail, how do I watch the certs and fix ahead of time?

But this doesn't make sense to me since 2008 and 2012 both work "out of the box" with 636.

When I check the 2019 server with: certutil -v -urlfetch -verify serverssl.cer > output.txt

I get:

DecodeFile returned The system cannot find the file specified 0x80070002 (Win32: 2 ERROR_FILE_NOT_FOUND) LoadCert(Cert) returned The system cannot find the file specified 0x80070002 (Win32: 2 ERROR_FILE_NOT_FOUND) CertUtil -verify command FAILED: 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND) CertUtil: The system cannot find the file specified.

So that's telling me the cert does not exist.

Each of the domains I will be connecting to, the computer connecting to them will not be in the same domain. In that above article it was referring to having a cert that can be trusted by both devices.

From the testdomain I can run LDP and connect back into the 2008 or 2012 domain with zero issues on 636 using the builtin configured certificate... But this is a new version and it appears to be different.

Has anyone run into this on 2019 and can share a little more information of what I'm encountering?

4
  • Do you use an internal-only name for your AD domain (such as domain.local) or a public one? – Massimo Nov 17 '20 at 20:39
  • For my test environment they are all .local domains – Zonus Nov 17 '20 at 20:41
  • 1
    Then you can't get public certificates for them. You'll have to set up an internal Certification Authority. – Massimo Nov 17 '20 at 20:46
  • Ah good point! That lead me to check on the freshly installed domain if I had the certificate authority set up and I didn't. Once I installed and configured the cert authority it started working. Thank you for your help! – Zonus Nov 17 '20 at 20:52
0

It turned out my issue was that in the test domain I didn't install the cert authority service. Once installed and configured, it started working as expected.

1
  • 2
    Please note that certificates signed by an internal CA will only be automatically accepted by domain members; if you need something that's not a domain member (such a network device or a non-domain computer) to trust them, you'll have to explicitly trust the CA's root certificate. – Massimo Nov 17 '20 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.