Hi,
Having just updated our SSL certificates on our OpenLDAP server led us to review the contents of our "bundle" file referenced in "olcTLSCACertificateFile".
According to the documentation at: https://www.openldap.org/doc/admin24/tls.html it states "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."
However based on our understanding of how SSL works we should only actually need the intermediate(s) in there as the client should have the root and then compare the intermediate provided by the server and only trust it if it can use this in conjunction with it's copy of the root certificate to complete the chain of trust.
Based on this we configure our web servers to only have the intermediate(s) in their chain (and in fact SSL Labs marks you down if you have the root in there too).
Of course we do realise LDAP is not HTTP!
We're running OpenLDAP 2.4.47 linked against OpenSSL on Scientific Linux 7.5.
Kind regards, Mark
Mark Cairney Mark.Cairney@ed.ac.uk schrieb am 11.04.2019 um 13:35 in
Nachricht aae98896-e973-bae1-8eaa-d4a7fa6d29dd@ed.ac.uk:
Hi,
Having just updated our SSL certificates on our OpenLDAP server led us to review the contents of our "bundle" file referenced in "olcTLSCACertificateFile".
According to the documentation at: https://www.openldap.org/doc/admin24/tls.html it states "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."
However based on our understanding of how SSL works we should only actually need the intermediate(s) in there as the client should have the root and then compare the intermediate provided by the server and only trust it if it can use this in conjunction with it's copy of the root certificate to complete the chain of trust.
With the same argumentation you could also omit the intermediate CAs (you can trust an intermediate CA as well).
Based on this we configure our web servers to only have the intermediate(s) in their chain (and in fact SSL Labs marks you down if you have the root in there too).
Of course we do realise LDAP is not HTTP!
We're running OpenLDAP 2.4.47 linked against OpenSSL on Scientific Linux 7.5.
Kind regards, Mark
-- /****************************
Mark Cairney ITI Enterprise Services Information Services University of Edinburgh
Tel: 0131 650 6565 Email: Mark.Cairney@ed.ac.uk PGP: 0x435A9621
*******************************/
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Am 11.04.19 um 13:35 schrieb Mark Cairney:
Hello Mark,
However based on our understanding of how SSL works we should only actually need the intermediate(s) in there as the client should have the root and then compare the intermediate provided by the server and only trust it if it can use this in conjunction with it's copy of the root certificate to complete the chain of trust.
Based on this we configure our web servers to only have the intermediate(s) in their chain (and in fact SSL Labs marks you down if you have the root in there too).
That's best practice for *any* TLS server.
have a look at https://www.openldap.org/its/index.cgi?findid=8586 With the referenced patch I can setup TLSCertificateFile /path/to/cert+intermediate.pem TLSCertificateKeyFile /path/to/privkey.pem
I have no TLSCACertificateFile at all because I don't use certificates to authenticate ldap clients...
Of course we do realise LDAP is not HTTP!
I think, it *is* very similar...
Andreas
Hi Andreas,
Thanks- the discussion in the ITS is very useful/interesting. I should clarify that we're referring to a commercially-signed certificate for our LDAP server so clients should already have the root CA in their trust store.
We also aren't currently doing client cert verification and tend to use service accounts for client authentication. We may look to support client cert verification in the future using our own internal CA.
Kind regards, Mark
On 13/04/2019 15:48, A. Schulze wrote:
Am 11.04.19 um 13:35 schrieb Mark Cairney:
Hello Mark,
However based on our understanding of how SSL works we should only actually need the intermediate(s) in there as the client should have the root and then compare the intermediate provided by the server and only trust it if it can use this in conjunction with it's copy of the root certificate to complete the chain of trust.
Based on this we configure our web servers to only have the intermediate(s) in their chain (and in fact SSL Labs marks you down if you have the root in there too).
That's best practice for *any* TLS server.
have a look at https://www.openldap.org/its/index.cgi?findid=8586 With the referenced patch I can setup TLSCertificateFile /path/to/cert+intermediate.pem TLSCertificateKeyFile /path/to/privkey.pem
I have no TLSCACertificateFile at all because I don't use certificates to authenticate ldap clients...
Of course we do realise LDAP is not HTTP!
I think, it *is* very similar...
Andreas
openldap-technical@openldap.org
-
A. Schulze -
Mark Cairney -
Ulrich Windl