sca+openldap@andreasschulze.de wrote:

as discussed on the technical ML it's uncommon to put chain certificates in TLSCACertificateFile or TLSCACertificatePath. In case of a intermediate CA like "Let's Encrypt Authority X3" it may be wrong becaus the user is forced to /TRUST/ that intermediate for a unrelated purpose.

We should be more precise here - especially regarding the term "user".

IMO it is common to put the whole CA cert chain in the cert configuration of a TLS server. This is required so that the TLS *client* only has to know the root CA cert (trust anchor) and the TLS server sends the intermediate certs. Note that some TLS implementations like GnuTLS require the CA cert chain to be "in order" (bottom-up).

The real issue here is that TLSCACertificateFile and TLSCACertificatePath are also used to specify the set of trusted CA certs to validate TLS client certs used by the TLS client to authenticate.

So I'm not sure whether your patch breaks the use-case of having more than one trusted root CA cert for validating TLS client certs issued by independent CAs.

I think we might need different directives for trusted CA certs for client cert validation and the server cert chain (similar what's done on Apache mod_ssl with SSLCertificateChainFile and SSLCACertificateFile/SSLCACertificatePath).

It could be sufficient to simply add the server CA cert chain to TLSCertificateFile and only add the trusted root CA certs to TLSCACertificateFile/TLSCACertificatePath (and no C code patch needed for that, maybe review/clarification of the docs).

Ciao, Michael.