Description of problem: Although the use of TLS_CACERTDIR seems to be discouraged[1][2], there don't seem to be any statements to that effect in any of the OpenLDAP documentation. The OpenLDAP Software 2.3 Administrators Guide says[2]: 12.2.1.2. TLSCACertificatePath <path> [...] In general, it is simpler to use the TLSCACertificateFile directive instead. 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): openldap-2_3_43-12_el5_5_2 Additional info: See Bug 585030 for some history on this issue. [1]http://marc.info/?l=openssl-dev&m=114240877016822&w=4 [2]https://bugzilla.redhat.com/show_bug.cgi?id=585030#c1 [3]http://www.openldap.org/doc/admin23/tls.html
Created attachment 457275 [details] Proposed Patch 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?
Hi Jan, 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: /etc/pki/tls/certs/ 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: 12.2.1.2. 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 directive instead. Which is why I've asked for the changes in Comment 1 of this Bug. ~ Bryan
(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. New Contents: 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. http://rhn.redhat.com/errata/RHEA-2011-1009.html