2011/7/30 Howard Chu hyc@symas.com:
Frank Swasey wrote:
On 7/29/11 3:09 PM, Philip Guenther wrote:
On Fri, 29 Jul 2011, Francis Swasey wrote:
I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file.
Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients?
It's a CA cert; have you tried adding it to the file specified by the TLSCACertificateFile option?
Well, I never looked at it that way. Yes, adding the intermediate certificate to the file pointed to by the TLSCACertificateFile option on the OpenLDAP server appears to have worked.
Amaazing what trouble you could save yourself if you actually read the documentation.
He told he looked at the documentation. Documentation is not a novel, things must be organized to be easily found.
http://www.openldap.org/doc/admin24/tls.html#Server%20Configuration Section 16.2.1.1
I too think a configuration directive is missing here. The logic that says "this is a CA, you must place it in this CA file/path" is wrong. This directive (TLSCACertificateFile/Path) is used to verify the client certificate, and it shouldn't be used to place the certificates needed by the client to verify the server certificate.
Imagine this situation: - Root CA A, sub-CA A1 used to sign server certificates - Root CA B, sub-CA B1 used to sign client certificates - Server, Client, each one has a certificate signed by the correct CA (A1 and B1, respectively) - Client knows A (the trust anchor, maybe have been bundled with the software), B and B1 (it has received the whole certificate chain when it received its personal certificate - Server knows A and A1 (it received the whole certificate chain), and B (manually set by the admin), and maybe B1 (the admin could have set it, or he's waiting for the client to send it, both situations are valid and can be justified)
Actual OpenLDAP configuration would be to place B (and maybe B1) certificate in TLSCACertificateFile/Path element, to be able to verify the Client certificate. The Server must also place A1 in this element, so it can be sent to the Client to help it verify the Server certificate. So, during the TLS negotiation, B, A1, maybe B1, maybe A are sent to the Client for it to verify the Server certificate? (remember, this certificate is signed by A1, and A must already be known by the Client). That's a waste of bandwidth. What if B is a global CA, Bx are national ones (or similar decomposition, so we have a lot of Bx)? And, because A1 is in TLSCertificateFile/Path element, then Server will implicitly trust any certificate signed by the A+A1 chain? That's not what the admin has thought.