I have searched the faq-o-matic, google, the admin guide, and I cannot find any documentation that will allow me to set up my OpenLDAP 2.4.25 server using an SSL certificate that was issued from a CA that uses intermediate certificates (by, which I mean to indicate any commercial SSL cert company currently selling certs). Apache has the SSLCertificateChainFile directive to handle this. OpenLDAP seems to be lacking this functionality. 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?

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.

2011/7/30 Howard Chu<hyc(a)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

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.

On 2011-07-30 14:14, Howard Chu wrote: > Erwann ABALEA wrote: >> 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. > > The TLS library doesn't do anything so stupid, it only sends the > certificates that are part of the chain from the subject's cert up to > the root CA. I think the real question here is if the CA chain that the server sends and the CA chain that the server uses to verify client certificates can be different. In Apache, this is done with the SSLCertificateChainFile and SSLCACertificateFile directives. This makes it possible to have the server send a certificate chain that differs from the CAs it uses to verify clients. This is useful if you want to have a server certificate signed by one CA, but only accept client certificates signed by another CA. This sounds like an OpenLDAP feature request to me.

If there were indeed anything to be gained by such a feature, it would also need to be implemented on clients. Look around - do any web browsers allow you to isolate CAs like this?

It's utter nonsense.

On 2011-08-01 13:07, Howard Chu wrote: > David Hawes wrote: >> On 2011-07-30 14:14, Howard Chu wrote: >>> Erwann ABALEA wrote: >>>> 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. >>> >>> The TLS library doesn't do anything so stupid, it only sends the >>> certificates that are part of the chain from the subject's cert up to >>> the root CA. >> >> I think the real question here is if the CA chain that the server sends >> and the CA chain that the server uses to verify client certificates can >> be different. >> >> In Apache, this is done with the SSLCertificateChainFile and >> SSLCACertificateFile directives. This makes it possible to have the >> server send a certificate chain that differs from the CAs it uses to >> verify clients. This is useful if you want to have a server certificate >> signed by one CA, but only accept client certificates signed by >> another CA. >> >> This sounds like an OpenLDAP feature request to me. > > Think about why you would configure such a setup, and what it actually > means. When you have a certificate of your own, signed by a particular > CA, that obviously means that you must trust that CA. If you're going to > accept a cert from another party that is signed by a different CA that > obviously means that you must also trust the other CA. There is > absolutely nothing gained from isolating these two CAs, on either side > of the session. What is gained is that the server can be explicit about what client certificates it will accept. This is useful if you want to use a separate CA for client auth and do not want to accept certs from the CA that signed the server's cert.

Suppose my server has a Verisign cert. If I add the Verisign CA chain to TLSCACertificateFile, I have just allowed all certs signed by any CA in that chain to do TLS client auth. If I want to allow clients signed by my own CA and not those signed by Verisign, I'm out of luck.

Again, Apache does this by having separate directives for assembling the certificate chain and specifying which CAs to trust for clients.

2011/8/1 Howard Chu<hyc(a)symas.com>: > David Hawes wrote: [...] > Think about why you would configure such a setup, and what it actually > means. When you have a certificate of your own, signed by a particular CA, > that obviously means that you must trust that CA. If you're going to accept > a cert from another party that is signed by a different CA that obviously > means that you must also trust the other CA. There is absolutely nothing > gained from isolating these two CAs, on either side of the session. You've never been into such a situation. That doesn't mean such an isolation is irrelevant.

Erwann ABALEA wrote: > > 2011/8/1 Howard Chu<hyc(a)symas.com>: >> >> David Hawes wrote: > > [...] >> >> Think about why you would configure such a setup, and what it actually >> means. When you have a certificate of your own, signed by a particular >> CA, >> that obviously means that you must trust that CA. If you're going to >> accept >> a cert from another party that is signed by a different CA that obviously >> means that you must also trust the other CA. There is absolutely nothing >> gained from isolating these two CAs, on either side of the session. > > You've never been into such a situation. That doesn't mean such an > isolation is irrelevant. Go and read the X.509 spec. Go and read the TLS RFC (2246). You're spouting nonsense.