[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: CA and Intermediate Certificates


Put your intermediate cert and CA cert in the TLSCACertificateFile specified by your slapd.conf (or olsTLSCA... if using slapd.d).

And the server will include the chain correctly automagically. :)

Test via:
    openssl s_client -connect [host]:636 -showcerts </dev/null

>From that, you should see the chain.

FWIW: I looked at the later mentioned FMs and Admin Guide and none seem include the word 'chain' (except for chaining - a different topic), which is how I would look to see how to configure or verify the server will include the chain. The issue of chains is either not addressed or talked about in a way that isn't obvious or simply hard to find. Frankly, had I your concerns and current config, I would have been just as confused. My first hints on how to correctly configure this from your starting point where by searching Google for openldap cert "chain" which helped me find this post: http://www.openldap.org/lists/openldap-software/200704/msg00229.html

Here's how I have it configured:

# grep TLS.*File slapd.conf
TLSCACertificateFile    /etc/openldap/cacerts/cacert.pem
TLSCertificateFile      /etc/openldap/cacerts/servercrt.pem
TLSCertificateKeyFile   /etc/openldap/cacerts/serverkey.pem

I do NOT have the internal CA we use to sign our certs configured on our host OS; which will explain the error:num=19 you'll see below.
OpenLDAP /is/ configured to trust the cert, openssl doesn't because the systems aren't.

Here's what the command returns for me (scrubbed):

# openssl s_client -connect localhost:636 -showcerts </dev/null
depth=2 C = US, O = [internal CA]
verify error:num=19:self signed certificate in certificate chain
verify return:0
Certificate chain
 0 s:/C=[host cert]
   i:/C=[signing/intermediate cert]
 1 s:/C=[signing/intermediate cert]
   i:/C=[root CA cert]
 2 s:/C=[root CA cert]
   i:/C=[root CA cert]
Server certificate
subject=/C=[host cert]
issuer=/C=[signing/intermediate cert]
No client certificate CA names sent
SSL handshake has read 3941 bytes and written 438 bytes
New, TLSv1/SSLv3, Cipher is CAMELLIA256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1
    Cipher    : [snipped because paranoid corp security staff]
    Session-ID: 7A03E9F206C372CB11F13E5E3C0E03E0FBC1EA3624B38DC6057656CBE4EE1DCF
    Master-Key: [snipped because paranoid corp security staff]
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1408032684
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)

I hope this helps,
- chris

-----Original Message-----
From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Andrew Devenish-Meares
Sent: Wednesday, August 13, 2014 10:25 PM
To: openldap-technical@openldap.org
Subject: CA and Intermediate Certificates

Hi All,

We are currently assessing changing our TLS Certificate setup.

We have been using a self-signed CA to issue certificates for our OpenLDAP setup, which has required us to supply the CA to anyone outside our organisation that wishes to use our OpenLDAP over TLS or SSL.

We're currently starting to migrate our certificates to AusCERT, as we get a good deal as a University.  As AusCERT is an intermediate CA, so we need to use a chain to get this to work.

The server side works, as per the documentation, by adding the intermediate CA with the root CA in the olcTLSCertificateCAFile.

This means that we need to install the intermediate certificate on clients that connect to our LDAP using SSL or TLS.  Admittedly this isn't vastly different to what we need to do now in supplying our own CA.

Looking at our Linux clients in particular, we need to add an appropriate TLS_CACERT directive to our openldap/ldap.conf.  Is the intention, then, to point the client at the appropriate CA files? Is there a reason that OpenLDAP doesn't use the regular system CA store? Is there any reason for us not to point to the CA store that's already maintained?


Andrew Devenish-Meares
Solutions Analyst
Information Technology
University of New England
Armidale   NSW   2351

e:  adevenis@une.edu.au
p:  02 6773 4098
w: http://une.edu.au/itd

This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.