Hello,
Using multiple CA certificates with the TLSCACertificateFile directive is not working in my setup. The man page (1) clearly states that multiple certificates can be appended to the file.
Only the first CA in the file appear to be used. I confirmed this by changing the order of the certificate in the file.
I am using self-signed CA Certificate which is used for validating the provider server certificate during replication. I see this behaviour in both the latest OpenLDAP release and an older release. In both case I am using OpenSSL.
I just realized one important point abound my setup: Both CA certificate have the same DN. Other that that they are completely different certificate (different key, expiry date). Both CA certificate are valid (not expired).
I will test tomorrow if appending another CA certificate with a different CN makes a difference.
I am wondering if some people are successfully using multiples certificates with the TLSCACertificateFile directive. Thanks.
Best,
Alex
(1) http://www.openldap.org/software/man.cgi?query=slapd.conf
On Wed, May 17 2017 at 00:42:25 +0900, Alexandre Rosenberg scribbled in "TLSCACertificateFile directive and multiple CA certificates":
Hello,
Hi Alex,
Using multiple CA certificates with the TLSCACertificateFile directive is not working in my setup. The man page (1) clearly states that multiple certificates can be appended to the file.
Only the first CA in the file appear to be used. I confirmed this by changing the order of the certificate in the file.
How are testing to confirm this?
I am using self-signed CA Certificate which is used for validating the provider server certificate during replication. I see this behaviour in both the latest OpenLDAP release and an older release. In both case I am using OpenSSL.
I just realized one important point abound my setup: Both CA certificate have the same DN. Other that that they are completely different certificate (different key, expiry date). Both CA certificate are valid (not expired).
Depending on how you're testing things, the duplicate DN may well be the _an_ issue, but possibly not a real issue...
I will test tomorrow if appending another CA certificate with a different CN makes a difference.
I am wondering if some people are successfully using multiples certificates with the TLSCACertificateFile directive. Thanks.
Yes we're successfully using multiple certificates with a TLSCACertificateFile directive.
It might well be interesting, and useful, for you to explain what you're trying to accomplish, as it's possible that you're misunderstanding what the directive is actually there to achieve.
The purpose of a CA Certificate file is to allow you to describe the path of trust between your TLSCertificateFile (the certificate used to assert the authentication and identity of your DSA) and the eventually trusted Root CA certificate that a connecting client will have on their system.
The reason it's often required is that the path of trust to the Root CA traverses across several intermediate signing certificates (less likely to be the case when using a selection of self-signed certificates) -- each certificate has a "Subject" (the DN you mention above), and an "Issuer" (which is the Subject of it's "parent" signing certificate). A simple(ish) way of showing this is to use the openssl s_client subcommand to do something like the following:
#---8<----------------------------------------------------------------- $ echo | openssl s_client -connect $YOUR_LDAP_HOSTNAME:636 -showcerts #---8<-----------------------------------------------------------------
and review the "Certificate chain" output. You will have to adjust the command if you're using TLS negotiation over port 389 rather than the dedicated ldaps port (636).
Cheers.
Dameon.
Dameon Wagner dameon.wagner@it.ox.ac.uk schrieb am 17.05.2017 um 10:34 in
Nachricht 20170517083438.GJ3001@maia.oucs.ox.ac.uk:
On Wed, May 17 2017 at 00:42:25 +0900, Alexandre Rosenberg scribbled in "TLSCACertificateFile directive and multiple CA certificates":
Hello,
Hi Alex,
Using multiple CA certificates with the TLSCACertificateFile directive is not working in my setup. The man page (1) clearly states that multiple certificates can be appended to the file.
Only the first CA in the file appear to be used. I confirmed this by changing the order of the certificate in the file.
How are testing to confirm this?
I am using self-signed CA Certificate which is used for validating the provider server certificate during replication. I see this behaviour in both the latest OpenLDAP release and an older release. In both case I am using OpenSSL.
I just realized one important point abound my setup: Both CA certificate have the same DN. Other that that they are completely different certificate (different key, expiry date). Both CA certificate are valid (not expired).
Depending on how you're testing things, the duplicate DN may well be the _an_ issue, but possibly not a real issue...
I think the duplicate DN is a problem, because the DN (subject) is used to find a matching certificate. Then if that seems valid (regarding expiration dates), it'll be used. And I think to search is terminated here.
From a PKI point of view there's no problem with this algorithm, right?
I will test tomorrow if appending another CA certificate with a different CN makes a difference.
I am wondering if some people are successfully using multiples certificates with the TLSCACertificateFile directive. Thanks.
Yes we're successfully using multiple certificates with a TLSCACertificateFile directive.
It might well be interesting, and useful, for you to explain what you're trying to accomplish, as it's possible that you're misunderstanding what the directive is actually there to achieve.
The purpose of a CA Certificate file is to allow you to describe the path of trust between your TLSCertificateFile (the certificate used to assert the authentication and identity of your DSA) and the eventually trusted Root CA certificate that a connecting client will have on their system.
The reason it's often required is that the path of trust to the Root CA traverses across several intermediate signing certificates (less likely to be the case when using a selection of self-signed certificates) -- each certificate has a "Subject" (the DN you mention above), and an "Issuer" (which is the Subject of it's "parent" signing certificate). A simple(ish) way of showing this is to use the openssl s_client subcommand to do something like the following:
#---8<----------------------------------------------------------------- $ echo | openssl s_client -connect $YOUR_LDAP_HOSTNAME:636 -showcerts #---8<-----------------------------------------------------------------
and review the "Certificate chain" output. You will have to adjust the command if you're using TLS negotiation over port 389 rather than the dedicated ldaps port (636).
Cheers.
Dameon.
--
<> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dr. Dameon Wagner, Systems Development and Support IT Services, University of Oxford
<> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
On Wed, May 17 2017 at 11:19:48 +0200, Ulrich Windl scribbled in "Antw: Re: TLSCACertificateFile directive and multiple CA certificates":
Dameon Wagner dameon.wagner@it.ox.ac.uk schrieb am 17.05.2017 um 10:34 in
<SNIP>
I just realized one important point abound my setup: Both CA certificate have the same DN. Other that that they are completely different certificate (different key, expiry date). Both CA certificate are valid (not expired).
Depending on how you're testing things, the duplicate DN may well be the _an_ issue, but possibly not a real issue...
I think the duplicate DN is a problem, because the DN (subject) is used to find a matching certificate. Then if that seems valid (regarding expiration dates), it'll be used. And I think to search is terminated here.
Indeed, it's definitely a problem, but I think the main problem is a misunderstanding about what the TLSCACertificateFile directive is for (and what Alex wants to achieve in using it).
From a PKI point of view there's no problem with this algorithm, right?
I don't think so. The documentation is clear that order doesn't matter in the file pointed at by TLSCACertificateFile, but that mostly refers to not having to apply the certificate chain in order of descent, rather than any order of priority -- so long as the chain can be traversed without gaps using the certificates concatenated in the file, it should be happy.
(I won't comment on how carefully pedantic sysadmins like myself craft our chain files :)
Cheers.
Dameon.
openldap-technical@openldap.org
-
Alexandre Rosenberg -
Dameon Wagner -
Ulrich Windl