Bug 649048 - Document preferred use of TLS_CACERT instead of TLS_CACERTDIR to specify Certificate Authorities
Summary: Document preferred use of TLS_CACERT instead of TLS_CACERTDIR to specify Cert...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: man-pages-overrides
Version: 5.5
Hardware: All
OS: All
medium
medium
Target Milestone: rc
: ---
Assignee: Ivana Varekova
QA Contact:
URL:
Whiteboard:
Depends On: 609722 811468
Blocks: 590060 699652
TreeView+ depends on / blocked
 
Reported: 2010-11-02 20:26 UTC by Bryan Mason
Modified: 2018-11-14 20:19 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
: 699652 (view as bug list)
Environment:
Last Closed: 2011-07-21 07:36:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Proposed Patch (2.05 KB, patch)
2010-11-02 20:29 UTC, Bryan Mason
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:1009 0 normal SHIPPED_LIVE new package: man-pages-overrides 2011-07-20 15:44:41 UTC

Description Bryan Mason 2010-11-02 20:26:03 UTC
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

Comment 1 Bryan Mason 2010-11-02 20:29:54 UTC
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.

Comment 2 Jan Vcelak 2010-11-03 09:42:34 UTC
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?

Comment 3 Bryan Mason 2010-11-08 23:47:34 UTC
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

Comment 4 Jan Vcelak 2010-11-10 12:39:04 UTC
(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.

Comment 11 Miroslav Svoboda 2011-07-15 16:36:36 UTC
    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.

Comment 12 errata-xmlrpc 2011-07-21 07:36:52 UTC
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


Note You need to log in before you can comment on or make changes to this bug.