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?
Cheers
Andrew Devenish-Meares wrote:
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.
If correctly setup the server will send the intermediate CA cert to the client in the TLS handshake. So the client will be able to validate the server cert and intermediate CA cert against a pre-installed root CA cert.
You can test this with "openssl s_server ..".
Ciao, Michael.
Andrew Devenish-Meares adevenis@une.edu.au writes:
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. [...] 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.
You have to put the chain leading to the well-known root CA into your server certificate file:
-----BEGIN CERTIFICATE----- [your server cert] -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- [the intermediate certificate (issuer of your server cert)] -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- [possible other intermediate certificate (issuer of your intermediate cert)] -----END CERTIFICATE-----
You may include the well-known root CA at the end (as the final issuer), but that is not necessary, as that certificate must be present and trusted on the client systems anyway.
Ferenc Wagner wrote:
Andrew Devenish-Meares adevenis@une.edu.au writes:
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. [...] 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.
You have to put the chain leading to the well-known root CA into your server certificate file:
Wrong. The correct usage of CA certificates is already documented in the slapd.conf(5) manpage, slapd-config(5) manpage, and the Admin Guide. RTFM.
Andrew,
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 CONNECTED(00000003) 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] -----BEGIN CERTIFICATE----- [snipped] -----END CERTIFICATE----- 1 s:/C=[signing/intermediate cert] i:/C=[root CA cert] -----BEGIN CERTIFICATE----- [snipped] -----END CERTIFICATE----- 2 s:/C=[root CA cert] i:/C=[root CA cert] -----BEGIN CERTIFICATE----- [snipped] -----END CERTIFICATE----- --- 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 SSL-Session: Protocol : TLSv1 Cipher : [snipped because paranoid corp security staff] Session-ID: 7A03E9F206C372CB11F13E5E3C0E03E0FBC1EA3624B38DC6057656CBE4EE1DCF Session-ID-ctx: 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) --- DONE
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?
Cheers
-- 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.
--On Thursday, August 14, 2014 10:22 AM -0700 Chris Jacobs Chris.Jacobs@apollo.edu wrote:
# grep TLS.*File slapd.conf TLSCACertificateFile /etc/openldap/cacerts/cacert.pem TLSCertificateFile /etc/openldap/cacerts/servercrt.pem TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem
Or just use TLSCACertificatePath and hash the CA certs, rather than using huge clunky files...
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
It's a matter of preference. Those 'huge clunky files' are easy to parse from the command line. When it's time to renew the cert, I can simply update the parts that were updated (usually just the host cert) rather than having to generate a new hash.
I understand where you're coming from, but I prefer this way. It really is easier to trace/fix/replace.
Or perhaps I'm misunderstanding you.
- chris
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Thursday, August 14, 2014 11:17 AM To: Chris Jacobs; Andrew Devenish-Meares; openldap-technical@openldap.org Subject: RE: CA and Intermediate Certificates
--On Thursday, August 14, 2014 10:22 AM -0700 Chris Jacobs Chris.Jacobs@apollo.edu wrote:
# grep TLS.*File slapd.conf TLSCACertificateFile /etc/openldap/cacerts/cacert.pem TLSCertificateFile /etc/openldap/cacerts/servercrt.pem TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem
Or just use TLSCACertificatePath and hash the CA certs, rather than using huge clunky files...
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
--On Thursday, August 14, 2014 12:52 PM -0700 Chris Jacobs Chris.Jacobs@apollo.edu wrote:
It's a matter of preference. Those 'huge clunky files' are easy to parse from the command line. When it's time to renew the cert, I can simply update the parts that were updated (usually just the host cert) rather than having to generate a new hash.
I understand where you're coming from, but I prefer this way. It really is easier to trace/fix/replace.
Or perhaps I'm misunderstanding you.
You don't hash host certs at all. Just CA certs. Unless the CA redoes its cert chain, you don't have to do anything when updating the host cert.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Chris Jacobs wrote:
Andrew,
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.
http://www.openldap.org/doc/admin24/tls.html 16.2.1.1 is pretty explicit.
Per your link: ---- 16.2.1.1. TLSCACertificateFile <filename>
This directive specifies the PEM-format file containing certificates for the CA's that slapd will trust. The certificate for the CA that signed the server certificate must be included among these certificates. If the signing CA was not a top-level (root) CA, certificates for the entire sequence of CA's from the signing CA to the top-level CA should be present. Multiple certificates are simply appended to the file; the order is not significant. ----
I would add: "The entire available chain is sent to clients during TLS startup."
I don't see that being implied in there. Merely 'put the certs here, and intermediates must be too'.
My two cents as a non-developer, non-OpenLDAP contributor, sysadmin. :-)
- chris
-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, August 14, 2014 11:35 AM To: Chris Jacobs; Andrew Devenish-Meares; openldap-technical@openldap.org Subject: Re: CA and Intermediate Certificates
Chris Jacobs wrote:
Andrew,
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.
http://www.openldap.org/doc/admin24/tls.html 16.2.1.1 is pretty explicit.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
openldap-technical@openldap.org