Whenever I set olcTLSCACertificateFile to /etc/pki/tls/certs/ca-bundle.crt LDAP clients get cert errors connecting to the server. But it works fine when I point olcTLSCACertificateFile at the actual server cert instead of the CA bundle.
With olcTLSCACertificateFile pointed at /etc/pki/tls/certs/ca-bundle.crt: CLIENT: # LDAPTLS_CACERT=/etc/pki/tls/certs/ca-bundle.crt ldapsearch -H 'ldap://fqdn.to.my.server' -ZZ -x -b '' -s base '+' ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (unable to get local issuer certificate) SERVER (from "slapd -d conns"): TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca.
Why is this happening. olcTLSCACertificateFile is supposed to control the certificates that OpenLDAP will recognize, not affect the certificate it gives to clients (right?).
This is OpenLDAP 2.4.31
-Patrick
Patrick Hemmer wrote:
Whenever I set olcTLSCACertificateFile to /etc/pki/tls/certs/ca-bundle.crt LDAP clients get cert errors connecting to the server. But it works fine when I point olcTLSCACertificateFile at the actual server cert instead of the CA bundle.
With olcTLSCACertificateFile pointed at /etc/pki/tls/certs/ca-bundle.crt: CLIENT: # LDAPTLS_CACERT=/etc/pki/tls/certs/ca-bundle.crt ldapsearch -H 'ldap://fqdn.to.my.server' -ZZ -x -b '' -s base '+' ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (unable to get local issuer certificate) SERVER (from "slapd -d conns"): TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca.
Why is this happening. olcTLSCACertificateFile is supposed to control the certificates that OpenLDAP will recognize, not affect the certificate it gives to clients (right?).
This is OpenLDAP 2.4.31
Use the debug flag and provide more information. Nobody can answer this post with the details you've provided.
Sent: Tue Jun 12 2012 12:08:52 GMT-0400 (EDT) From: Patrick Hemmer openldap@stormcloud9.net To: openldap-technical@openldap.org Subject: TLS issues when setting olcTLSCACertificateFile to the CA bundle
Whenever I set olcTLSCACertificateFile to /etc/pki/tls/certs/ca-bundle.crt LDAP clients get cert errors connecting to the server. But it works fine when I point olcTLSCACertificateFile at the actual server cert instead of the CA bundle.
With olcTLSCACertificateFile pointed at /etc/pki/tls/certs/ca-bundle.crt: CLIENT: # LDAPTLS_CACERT=/etc/pki/tls/certs/ca-bundle.crt ldapsearch -H 'ldap://fqdn.to.my.server' -ZZ -x -b '' -s base '+' ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (unable to get local issuer certificate) SERVER (from "slapd -d conns"): TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca.
Why is this happening. olcTLSCACertificateFile is supposed to control the certificates that OpenLDAP will recognize, not affect the certificate it gives to clients (right?).
This is OpenLDAP 2.4.31
-Patrick
So I found the cause of this issue. What is happening is that I have the chain cert bundled in with the server's cert. Apparently the chain cert MUST be placed in the file referenced by olcTLSCACertificateFile. However this now introduces a problem. We are requiring client certificates for all connections, and we are using our own CA cert to sign the client certs, and then telling OpenLDAP to trust only our CA. However by having to add the chain cert to the CAs that OpenLDAP will recognize, other clients signed with that chain cert can now connect, not just clients signed with our CA.
OpenLDAP does not appear to have any method for specifying that a cert file should only be used as the chain cert of the server's certificate. While browsing around trying to understand exactly what was going on, I found other projects like apache httpd have configuration parameters ( SSLCertificateChainFile) to specify chain cert files for exactly this reason. Is there any particular reason OpenLDAP does not have this capability?
So you problem is, that you have signed your server cert with a CA from a CA chain and your clients with another CA and you don't want clients to connect, not signed by your client CA?
This sounds more like a case for ACLs and matching rules, since you AFAIK you cannot tell ldap to only trust a CA for server cert verification purposes. A CA is trusted or not.
Sent: Sat Jun 16 2012 03:31:40 GMT-0400 (EDT) From: Bernd May bernd@net.t-labs.tu-berlin.de To: Patrick Hemmer openldap@stormcloud9.net openldap-technical@openldap.org Subject: Re: TLS issues when setting olcTLSCACertificateFile to the CA bundle
So you problem is, that you have signed your server cert with a CA from a CA chain and your clients with another CA and you don't want clients to connect, not signed by your client CA?
This sounds more like a case for ACLs and matching rules, since you AFAIK you cannot tell ldap to only trust a CA for server cert verification purposes. A CA is trusted or not.
The assessment is correct, but I beg to differ on the statement "A CA is trusted or not".
Server certs are used by the client to verify the remote server is who it says it is. Client certs are used by the server to verify the client is allowed to talk to it. There is a very big difference between the two. The server doesnt care one bit if the CN of a client cert doesnt match the reverse DNS lookup of the IP the connection came from. All it cares is that the cert presented by the client is signed by a recognized CA. As such if you dont restrict the CAs that OpenLDAP will recognize for client certificates, any john-doe server with a certificate could connect (at which point client certs become useless).
-Patrick
--On Saturday, June 16, 2012 2:31 PM -0400 Patrick Hemmer openldap@stormcloud9.net wrote:
Sent: Sat Jun 16 2012 03:31:40 GMT-0400 (EDT) From: Bernd May bernd@net.t-labs.tu-berlin.de To: Patrick Hemmer openldap@stormcloud9.net openldap-technical@openldap.org Subject: Re: TLS issues when setting olcTLSCACertificateFile to the CA bundle
So you problem is, that you have signed your server cert with a CA from a CA chain and your clients with another CA and you don't want clients to connect, not signed by your client CA?
This sounds more like a case for ACLs and matching rules, since you AFAIK you cannot tell ldap to only trust a CA for server cert verification purposes. A CA is trusted or not.
The assessment is correct, but I beg to differ on the statement "A CA is trusted or not".
Server certs are used by the client to verify the remote server is who it says it is. Client certs are used by the server to verify the client is allowed to talk to it. There is a very big difference between the two. The server doesnt care one bit if the CN of a client cert doesnt match the reverse DNS lookup of the IP the connection came from. All it cares is that the cert presented by the client is signed by a recognized CA. As such if you dont restrict the CAs that OpenLDAP will recognize for client certificates, any john-doe server with a certificate could connect (at which point client certs become useless).
I would suggest you use olcTLSCACertificatePath and point to a directory containing the CA certs that should be used for validation of certs.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Saturday, June 16, 2012 2:31 PM -0400 Patrick Hemmer openldap@stormcloud9.net wrote:
Sent: Sat Jun 16 2012 03:31:40 GMT-0400 (EDT) From: Bernd May bernd@net.t-labs.tu-berlin.de To: Patrick Hemmer openldap@stormcloud9.net openldap-technical@openldap.org Subject: Re: TLS issues when setting olcTLSCACertificateFile to the CA bundle
So you problem is, that you have signed your server cert with a CA from a CA chain and your clients with another CA and you don't want clients to connect, not signed by your client CA?
This sounds more like a case for ACLs and matching rules, since you AFAIK you cannot tell ldap to only trust a CA for server cert verification purposes. A CA is trusted or not.
The assessment is correct, but I beg to differ on the statement "A CA is trusted or not".
Server certs are used by the client to verify the remote server is who it says it is. Client certs are used by the server to verify the client is allowed to talk to it. There is a very big difference between the two. The server doesnt care one bit if the CN of a client cert doesnt match the reverse DNS lookup of the IP the connection came from. All it cares is that the cert presented by the client is signed by a recognized CA. As such if you dont restrict the CAs that OpenLDAP will recognize for client certificates, any john-doe server with a certificate could connect (at which point client certs become useless).
The TLS chapter of the Admin Guide already covers this.
I would suggest you use olcTLSCACertificatePath and point to a directory containing the CA certs that should be used for validation of certs.
No. There's no behavioral difference between the ...Path vs ...File. The use of ...Path is annoying because it requires the maintenance script to generate the hash symlinks, but aside from that, all certs in either location are used.
Sent: Sat Jun 16 2012 19:42:59 GMT-0400 (EDT) From: Howard Chu hyc@symas.com To: Quanah Gibson-Mount quanah@zimbra.com bernd@net.t-labs.tu-berlin.de, Patrick Hemmer openldap@stormcloud9.net, openldap-technical@openldap.org Subject: Re: TLS issues when setting olcTLSCACertificateFile to the CA bundle
Quanah Gibson-Mount wrote:
--On Saturday, June 16, 2012 2:31 PM -0400 Patrick Hemmer openldap@stormcloud9.net wrote:
Sent: Sat Jun 16 2012 03:31:40 GMT-0400 (EDT) From: Bernd May bernd@net.t-labs.tu-berlin.de To: Patrick Hemmer openldap@stormcloud9.net openldap-technical@openldap.org Subject: Re: TLS issues when setting olcTLSCACertificateFile to the CA bundle
So you problem is, that you have signed your server cert with a CA from a CA chain and your clients with another CA and you don't want clients to connect, not signed by your client CA?
This sounds more like a case for ACLs and matching rules, since you AFAIK you cannot tell ldap to only trust a CA for server cert verification purposes. A CA is trusted or not.
The assessment is correct, but I beg to differ on the statement "A CA is trusted or not".
Server certs are used by the client to verify the remote server is who it says it is. Client certs are used by the server to verify the client is allowed to talk to it. There is a very big difference between the two. The server doesnt care one bit if the CN of a client cert doesnt match the reverse DNS lookup of the IP the connection came from. All it cares is that the cert presented by the client is signed by a recognized CA. As such if you dont restrict the CAs that OpenLDAP will recognize for client certificates, any john-doe server with a certificate could connect (at which point client certs become useless).
The TLS chapter of the Admin Guide already covers this.
What in particular are you referring to? The only relevant part I see is this: : The server must be configured with the CA certificates and also its own server certificate and private key. : Typically a single CA will have issued the server certificate and all of the trusted client certificates, so the server only needs to trust that one signing CA
However my situation isnt the typical case mentioned, as I have a different CA signing the server's cert and the client's certs.
I would suggest you use olcTLSCACertificatePath and point to a directory containing the CA certs that should be used for validation of certs.
No. There's no behavioral difference between the ...Path vs ...File. The use of ...Path is annoying because it requires the maintenance script to generate the hash symlinks, but aside from that, all certs in either location are used.
On Sat, Jun 16, 2012 at 02:31:31PM -0400, Patrick Hemmer wrote:
Server certs are used by the client to verify the remote server is who it says it is. Client certs are used by the server to verify the client is allowed to talk to it. There is a very big difference between the two. The server doesnt care one bit if the CN of a client cert doesnt match the reverse DNS lookup of the IP the connection came from. All it cares is that the cert presented by the client is signed by a recognized CA. As such if you dont restrict the CAs that OpenLDAP will recognize for client certificates, any john-doe server with a certificate could connect (at which point client certs become useless).
There is a good point here, and I think it may require some new config items to address it.
Slapd needs to know about at least three CAs. In many cases they are the same actual CA, but the functions of each are distinct:
1) The CA that signed slapd's own server certificate. The CA certificate for this one should be supplied to clients as part of the TLS setup.
2) The CA that signed the server certificate of any replication supplier, so that TLS connections to that supplier can be verified.
3) The CA that signed the authentication certificates used by clients when they make ldap connections to slapd. This is used to verify the client certificates.
At present, (1) and (3) are both configured using TLSCACertificateFile or TLSCACertificatePath. (2) is configured in the syncrepl clause, with fallback to ldap.conf or by setting the LDAPTLS_CACERT environment variable when starting slapd, as in this case slapd is acting as a client.
The issue of CA *chains* is separate, and in all cases above it should be valid to use a file containing however many certificates there are in the chain.
I think we need a way to configure each of the 3 cases separately.
Case (1) is adequately covered by the existing config variables.
Case (2) is covered by the tls_cacert options in the syncrepl clause, which allows for the possibility of each remote supplier having a certificate signed by a different CA.
Case (3) seems to need new config items. Looking at the TLS section of slapd.conf(5) I think it would be necessary to duplicate all the TLS* items as TLSClient* items (except for TLSVerifyClient itself, which should perhaps be renamed as TLSClientVerify to fit the naming scheme)
Comments?
Andrew
openldap-technical@openldap.org
-
Andrew Findlay -
Bernd May -
Howard Chu -
Patrick Hemmer -
Quanah Gibson-Mount