openldap-bugs February 2017

openldap-bugs@openldap.org

22 participants
59 discussions

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by michael＠stroeder.com 13 Feb '17

13 Feb '17

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.

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by hyc＠symas.com 13 Feb '17

13 Feb '17

michael(a)stroeder.com wrote: > sca+openldap(a)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/

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by hyc＠symas.com 13 Feb '17

13 Feb '17

sca+openldap(a)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/

1 0

Re: (ITS#8335) MDB_MULTIPLE issues
by hyc＠symas.com 13 Feb '17

13 Feb '17

h.b.furuseth(a)usit.uio.no wrote: > On 07/12/15 10:14, h.b.furuseth(a)usit.uio.no wrote: >> Put(0 data items, MDB_MULTIPLE) stores 1 item. The doc does >> not warn against 0 items. I suggest supporting 0 items, it >> is a commonly supported convenience elsewhere (e.g. memcpy). > > I.e. supporting it as a no-op. But on second thought I think > that's misleading and EINVAL is better: If the key doesn't exist, > this is an attempt to create a key with no data. Unsupported. > Bryan Matsuo just posted a test case to openldap-technical. EINVAL makes sense here. > datacount > UINT_MAX is truncated to unsigned int: > data[1].mv_size = 0x100000002 puts 2 items. > datacount * datasize can exceed UINT_MAX, which mdb_page_spill() > truncates to unsigned int. Such a massive put() will likely > fail anyway, but it should at least try to spill properly first. We should probably check if mv_size is greater than UINT_MAX and return EINVAL. (Or ERANGE.) >> Why does MDB_MULTIPLE require a cursor? mdb_put() rejects it. Because get only works with a cursor. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by sca＠andreasschulze.de 12 Feb '17

12 Feb '17

Am 12.02.2017 um 12:04 schrieb Michael Ströder: > sca+openldap(a)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

1 0

Re: (ITS#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no 12 Feb '17

12 Feb '17

On 07/12/15 10:14, h.b.furuseth(a)usit.uio.no wrote: > Put(0 data items, MDB_MULTIPLE) stores 1 item. The doc does > not warn against 0 items. I suggest supporting 0 items, it > is a commonly supported convenience elsewhere (e.g. memcpy). I.e. supporting it as a no-op. But on second thought I think that's misleading and EINVAL is better: If the key doesn't exist, this is an attempt to create a key with no data. Unsupported. Bryan Matsuo just posted a test case to openldap-technical. datacount > UINT_MAX is truncated to unsigned int: data[1].mv_size = 0x100000002 puts 2 items. datacount * datasize can exceed UINT_MAX, which mdb_page_spill() truncates to unsigned int. Such a massive put() will likely fail anyway, but it should at least try to spill properly first. > Why does MDB_MULTIPLE require a cursor? mdb_put() rejects it.

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by michael＠stroeder.com 12 Feb '17

12 Feb '17

sca+openldap(a)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.

1 0

Re: (ITS#8485) [PATCH] Adding support for encrypted server private keys
by balmerpeak92＠gmail.com 11 Feb '17

11 Feb '17

--f403045f155e1c46d105484cea3d Content-Type: text/plain; charset=UTF-8 This would be a very helpful feature for me - I have a web server that has to regularly interact with a corporately maintained secure LDAP server. I'd love to be able to store the certs for this interaction encrypted for added security. --f403045f155e1c46d105484cea3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">This would be a very helpful feature for me - I have a web= server that has to regularly interact with a corporately maintained secure= LDAP server. I'd love to be able to store the certs for this interacti= on encrypted for added security.<br></div> --f403045f155e1c46d105484cea3d--

1 0

(ITS#8587) correct spelling errors: wrong: emtpy, correct: empty
by sca+openldap＠andreasschulze.de 11 Feb '17

11 Feb '17

Full_Name: Andreas Schulze Version: RE24 testing call (2.4.45) OS: Linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-20170211-2.patch Submission from: (NULL) (2001:a60:f0b4:e502:80b6:610b:8fc2:abfe) there are 4 occurrence of "emtpy" which are supposed to be written as "empty"

1 0

(ITS#8586) load cert+chain from TLSCertificateFile
by sca+openldap＠andreasschulze.de 11 Feb '17

11 Feb '17

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.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2017