0

I've been given a certificate by the person who runs our Active Directory server so I can use LDAPS but I can't get it to work. When verifying with openssl:

openssl s_client -connect domain.com:636 -CAfile  ~/filename.pem

I just get Verify return code: 20 (unable to get local issuer certificate) every time.

I'm wondering if the server is misconfigured because I have tried to get the certificate straight from the server like this (from Ubunutu 16.04 client):

openssl s_client -host domain.com -port 636 -prexit -showcerts

And I get the same error message even with that.

Whereas if I type:

openssl s_client -host google.com -port 443 -prexit -showcerts

I get Verify return code: 0 (ok)

I've tried copying certificates into /etc/ssl/certs. I've tried using -CApath and -CAfile to give various certificates to the server.

Really I'm asking if the error code 20 in response to an openssl with -showcerts means that the server really is misconfigured or if I'm just not doing it right, because I'd hate to spend more time on the client when it's the server that's misbehaving.

openssl x509 -noout -text -in filename.pem

returns (with some redactions):

Certificate:

Data:

    Version: 3 (0x2)
    Serial Number:
        xxxxxxxxxxxxxxxx
Signature Algorithm: sha1WithRSAEncryption
    Issuer: CN=My organisation RootCA
    Validity
        Not Before: May 20 13:11:34 2016 GMT
        Not After : May 20 13:21:34 2021 GMT
    Subject: DC=org, DC=example, CN=My organisation Issuing CA

And then a load of stuff that all looks fine. That is the root certificate, is it not? It says RootCA on it, after all.

Oh yes, and if I feed that certificate in, with

openssl s_client -connect domain.com:636 -CAfile file.pem

I do get a different error message:

Verify return code: 2 (unable to get issuer certificate)

So this feels like I have one certificate but not the other.

I did get another one using nmap --ssl-cert but I don't seem to be able to get anything other than error code 20 with that.

  • If you have a Windows machine handy, you can use ldp.exe (download from Microsoft.com) to verify the LDAPS configuration, That said, assuming you're connecting to an AD Domain Controller, the only "configuration" is to have a Computer Certificate. There's literally nothing for us to do beyond that to enable LDAPS – Dan Jul 30 '18 at 13:09
  • Add the output of openssl x509 -noout -text -in filename.pem to your question. – garethTheRed Jul 30 '18 at 14:22
  • If telnet domain.com 636 is working, use the nmap ssl-cert -vv script. to dump the domain controller certificate. That should provide more information than the brain-damaged openssl client. You should also do a nslookup domain.com and test every IP address listed because you may be getting an invalid IP. – Greg Askew Jul 30 '18 at 16:08
  • No, that's not a root cert. It is issued by the root CA, but its subject (owner) is 'issuing CA' which presumably is an intermediate (and certainly is not the root). OpenSSL by default will not treat a non-root as an anchor. Either get the actual root cert, or in OpenSSL 1.0.2 up commandline use -partial_chain to validate using a non-root anchor. – dave_thompson_085 Jul 30 '18 at 16:58
  • Thanks for that. I didn't mention I actually have got the whole thing verified using partial_chain. However, that doesn't help me for the actual application, which is using LDAPS to secure an LDAP connection within Shiny Server docs.rstudio.com/shiny-server/#ldap-and-active-directory. Or does it? – Chris Beeley Jul 30 '18 at 17:03
2

I assume that you've received a file containing single root CA cert to validate the TLS server cert. Make sure it's ASCII-armored base64-encoded (aka PEM).

Normally a certificate authority would not use the root CA's key to directly sign a TLS server public key. For security reasons one uses an intermediate CA, also often called issuing CA, for that.

Now the TLS client has to verify the whole CA cert chain and it needs access to intermediate CA cert and root CA cert.

In case of a well-configured TLS server you only need the root CA cert in a local file because the server sends the intermediate CA cert during TLS connect. But some TLS servers are not well-configured.

You should see what's going on with

openssl s_client -connect ldap.example.com:636 -showcerts

like you already did.

If you do not have the root CA cert then ask the person who gave the intermediate CA cert to you.

Or if you have a Windows workstation in this AD domain it's somewhat likely that you find the root CA cert in the trust store of your Windows installation.

0

That is the root certificate, is it not? It says RootCA on it, after all.

    Issuer: CN=My organisation RootCA
    Validity
        Not Before: May 20 13:11:34 2016 GMT
        Not After : May 20 13:21:34 2021 GMT
    Subject: DC=org, DC=example, CN=My organisation Issuing CA

No, this is not the root certificate, it is just signed by the root certificate. You need a certificate that looks like this:

    Issuer: CN=My organisation RootCA
    Subject: CN=My organisation RootCA

In other words, both Issuer and Subject must be your RootCA.

As it was probably created on the Windows machine, go to the certificate manager and export the root CA (just the certificate, you don't need the key).

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.