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.