Full_Name: Andreas Schulze Version: RE24 testing call (2.4.45) OS: Linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-20170211.patch Submission from: (NULL) (2001:a60:f0b4:e502:80b6:610b:8fc2:abfe) 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. from https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_use_certificate.html#NOTES: SSL_CTX_use_certificate_chain_file() should be used instead of the SSL_CTX_use_certificate_file() function in order to allow the use of complete certificate chains even when no trusted CA storage is used or when the CA issuing the certificate shall not be added to the trusted CA storage. The patch andreas-schulze-20170211.patch only apply for openssl.
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.
Am 12.02.2017 um 12:04 schrieb Michael Ströder: > 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". agree > 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). As I don't use GnuTLS I can't tell something about it's internals > 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. correct. That's also what "man 3 SSL_CTX_use_certificate" mention. > 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 may imagine a setup with RSA and EC certificates. Two certs are more complex then one. But if an admin decide to use diferent CAs it's his decision for more complexity > 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). also: I don't us apache, can't tell if that way is is the best. Postfix,dovecot, nginx for example don't require a "SSLCertificateChainFile" directive. > 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). that's what the patch try. currently I tried to add cert+chain to a file used as TLSCertificateFile The chain is ignored as expected and documented in "man 3 SSL_CTX_use_certificate_file" simply replacing SSL_CTX_use_certificate_file by SSL_CTX_use_certificate_chain_file fix that. I now can put cert+chain (excluding a root) ti the file used as TLSCertificateFile. as simple as it could be. But: I'm aware there are other use cases that will break stuff, years old. So my ITS it more intended to point out a problem then simply changing openldap to my needs. Andreas
sca+openldap@andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: RE24 testing call (2.4.45) > OS: Linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-20170211.patch > Submission from: (NULL) (2001:a60:f0b4:e502:80b6:610b:8fc2:abfe) > > as discussed on the technical ML it's uncommon to put chain certificates in > TLSCACertificateFile or TLSCACertificatePath. It is explicitly documented. http://www.openldap.org/doc/admin24/tls.html Section 16.2.1.1. You may argue that it is uncommon for people to read the docs but that doesn't constitute a software bug. > 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. That doesn't follow. The file used by slapd is only used to authenticate LDAP clients. There is no bug here, this ITS is invalid. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
michael@stroeder.com wrote: > 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. It's pretty much unheard of for an LDAP server to trust TLS client certs issued by a CA different from the LDAP server's own CA. Since client certs are usually issued only to allow authentication, an LDAP server will only trust its own CA to issue identities to clients. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote: > It's pretty much unheard of for an LDAP server to trust TLS client certs issued by a CA > different from the LDAP server's own CA. Since client certs are usually issued only to > allow authentication, an LDAP server will only trust its own CA to issue identities to > clients. Not sure what you consider to be "pretty much unheard of". But I vaguely remember having already described this use case: 1. Assume *all* clients have to authenticate to the LDAP server to get properly authorized to even see data (no anon access). 2. Furthermore there is a config management system available at the site which already issues client certs for its own internal use (e.g. puppet with master and CA). In this case you want to (re)use the config mgmt client certs to simple authenticate those particular LDAP clients but not want to use the config mgmt CA to be trusted also to issue server certs which ensures MITM protection for all other LDAP clients probably sending bind requests with clear-text passwords. => OpenLDAP's configuration should it possible to define different root CA chains for the local server cert and accepted client certs validation. Ciao, Michael. P.S.: You might have guessed: I'm using this in Æ-DIR to avoid having to set server passwords for thousands of servers.
FWIW, tls_g already has the behaviour that (I think) this ticket asks for: if you set TLSCertificateFile to a file containing concatenated server and intermediate certs, it sends the chain of both. I found that useful in a setup very similar to what Andreas and Michael describe: slapd with a server certificate issued by an external/public CA, but trusting only a specific internal CA to authenticate clients. The comparison to mod_ssl is apt. Note that in recent versions httpd also supports loading the entire chain from SSLCertificateFile.
--On Tuesday, February 14, 2017 3:16 AM +0000 ryan@nardis.ca wrote: > I found that useful in a setup very similar to what Andreas and Michael > describe: slapd with a server certificate issued by an external/public > CA, but trusting only a specific internal CA to authenticate clients. I found this to be a very common scenario while working for Zimbra. Many of the clients had a commercial sever cert but used their own CA for internal client cert auth. It would be extremely helpful for OpenLDAP to better support these types of configurations. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
moved from Incoming to Software Enhancements
See also ITS#5582, ITS#8529, ITS#6248
changed notes
Created attachment 654 [details] andreas-schulze-2017-02-11.patch
fixed in master
Commits: • 680091b5 by Andreas Schulze at 2021-04-12T20:32:09+01:00 ITS#8586 load cert+chain from TLSCertificateFile • e16b0a73 by Howard Chu at 2021-04-12T20:32:12+01:00 ITS#8586 server cert manpage tweaks