11.6. Using Certificate-Based Authentication

11.6. Using Certificate-Based Authentication

Directory Server allows certificate-based authentication for the command-line tools (which are LDAP clients) and for replication communications. Certificate-based authentication can occur between:

A single configuration parameter, nsslapd-certdir, in cn=config in dse.ldif lists the directory containing the key, certificate, and security files. The directory name should be unique and specific to the server. For example, the /etc/dirsrv/slapd-instance_name directory contains the key and certificate databases only for the Directory Server instance called instance_name. That directory will not contain key and certificate databases for any other server or client, nor will any of the key, certificate, or other security-related files for instance_name be located in any other directory.

NOTE

The Directory Server 8.0 no longer uses separate files for the key and certificate databases. With the Filesystem Hierarchy Standard, the certificate and key files have been consolidated into a single file, specified in the nsslapd-certdir parameter, and the key and certificate file is stored in the /etc/dirsrv/slapd-instance_name directory.

Previous versions of Directory Server used a single directory, /opt/redhat-ds/slapd-instance/alias, for all security-related files for all servers, and required a unique prefix, such as slapd-instance-, for the key, certificate, and security-related files. The Directory Server used the attributes nsCertFile and nsKeyFile to give the locations for the key and certificate databases.

11.6.1. Setting up Certificate-Based Authentication

To set up certificate-based authentication, do the following:

  1. Create a certificate database for the client and the server or for both servers involved in replication.

    In the Directory Server, the certificate database creation automatically takes place when a certificate is installed. For information on creating a certificate database for a client, see Section 11.7, “Configuring LDAP Clients to Use SSL”.

  2. Obtain and install a certificate on both the client and the server or on both servers involved in replication.

  3. Enable TLS/SSL on the server or on both servers involved in replication.

    For information on enabling TLS/SSL, refer to Section 11.4, “Starting the Server with SSL Enabled”.

    NOTE

    If the Red Hat Console connects to Directory Server over TLS/SSL, selecting Require client authentication disables communication. This is because, although Red Hat Console supports TLS/SSL, it does not have a certificate to use for client authentication.

  4. Map the certificate's distinguished name to a distinguished name known by the directory.

    This can set access control for the client when it binds using this certificate.

11.6.2. Allowing/Requiring Client Authentication

If Red Hat Console is configured to connect to the Directory Server using TLS/SSL and the Directory Server requires client authentication, the Red Hat Console cannot be used to manage server applications. You must use the appropriate command-line utilities instead.

However, to change the directory configuration to no longer require but allow client authentication in order to use the Red Hat Console, do the following:

  1. Stop the Directory Server. [13] 

    service dirsrv stop instance

  2. Modify the cn=encryption,cn=config entry by changing the value of the nsSSLClientAuth attribute from required to allowed.

    For information on modifying entries from the command-line, see Section 2.2.4, “Adding and Modifying Entries Using ldapmodify”.

  3. Start the Directory Server. 

    service dirsrv start instance

Now start Red Hat Console.


Note: This documentation is provided {and copyrighted} by Red Hat®, Inc. and is released via the Open Publication License. The copyright holder has added the further requirement that Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. The CentOS project redistributes these original works (in their unmodified form) as a reference for CentOS-5 because CentOS-5 is built from publicly available, open source SRPMS. The documentation is unmodified to be compliant with upstream distribution policy. Neither CentOS-5 nor the CentOS Project are in any way affiliated with or sponsored by Red Hat®, Inc.