Red Hat Bugzilla – Bug 649048
Document preferred use of TLS_CACERT instead of TLS_CACERTDIR to specify Certificate Authorities
Last modified: 2012-04-11 03:52:49 EDT
Description of problem:
Although the use of TLS_CACERTDIR seems to be discouraged,
there don't seem to be any statements to that effect in any of the
OpenLDAP documentation. The OpenLDAP Software 2.3 Administrators
188.8.131.52. TLSCACertificatePath <path>
In general, it is simpler to use the TLSCACertificateFile
but that doesn't seem to be very discouraging to me, and it's not
completely applicable to the client configuration.
The use of TLS_CACERTDIR in OpenLDAP clients causes several
issues, so documenting the fact that TLS_CACERT should be used
instead of TLS_CACERTDIR should be strongly documented.
Version-Release number of selected component (if applicable):
See Bug 585030 for some history on this issue.
Created attachment 457275 [details]
Adds some text to ldap.conf.5 to discourage the use of TLS_CACERTDIR and encourage the use of TLS_CACERT.
I don't think that: "In general, it is simpler to use the TLSCACertificateFile directive instead." discourages from using TLS_CACERTDIR.
But I agree, that it is not very clear in ldap.conf.5. I propose adding sentence "The specified directory must be managed with the OpenSSL c_rehash utility.". It is done the same in new OpenLDAP 2.4 and it will make the things clearer.
In my opinion, managing a lot of certificates is easier when using TLS_CACERTDIR. (Easy removing, easy adding.)
Bryan, what do you think?
The root problem here is an issue where having an unreadable file in TLS_CACERTDIR can cause programs that call ldap_start_tls_s() to fail. An example of an "unreadable" file is a file that has root-only permissions (i.e. -rw------- 1 root root) but the program that is reading the certs in TLS_CACERTDIR is an non-root user.
This is a real-world problem because mod_ssl creates a a root-only file in /etc/pki/tls/certs/. If the system is configured to hold _all_ certs in /etc/pki/tls/certs, then the root-only file that mod_ssl creates will break other applications' use of that directory.
In Bug 585030, We asked to get the cert created by mod_ssl to be readable by non-root users, but we were told:
...configuring any application to read all certs from:
and treat such certs as trusted CA certs is a misconfiguration.
That directory is not intended to by used in that way, nor is it
documented to be used that way.
When a request was made in Bug 185080 to get the behavior of openldap changed so that not being able to read one cert file would not cause entire programs to fail, they were told that the behavior wouldn't be changed (See Comment 4 of Bug 185080).
So it would seem that our only recourse it to change the documentation to match some of the comments like "The use of TLS_CACERTDIR / TLSCACertificatePath is
discouraged in all of the OpenLDAP documentation." (in http://marc.info/?l=openssl-dev&m=114240877016822&w=4).
I agree that the following statement in the Administration Guide is _not_ very discouraging:
184.108.40.206. TLSCACertificatePath <path>
This directive specifies the path of a directory that
contains individual CA certificates in separate files. In
addition, this directory must be specially managed using
the OpenSSL c_rehash utility. When using this feature, the
OpenSSL library will attempt to locate certificate files
based on a hash of their name and serial number. The
c_rehash utility is used to generate symbolic links with
the hashed names that point to the actual certificate
files. As such, this option can only be used with a
filesystem that actually supports symbolic links. In
general, it is simpler to use the TLSCACertificateFile
Which is why I've asked for the changes in Comment 1 of this Bug.
(In reply to comment #3)
> The root problem here is an issue where having an unreadable file in
> TLS_CACERTDIR can cause programs that call ldap_start_tls_s() to fail. An
> example of an "unreadable" file is a file that has root-only permissions (i.e.
> -rw------- 1 root root) but the program that is reading the certs in
> TLS_CACERTDIR is an non-root user.
I see. This seems to depend on #609722, where fix already exists. I added rhel-5.7.0? flag.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
The ldap.conf(5) manual page has been modified in order to prefer usage of the TLS_CACERT option instead of the TLS_CACERTDIR option to specify Certificate Authorities.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.