Managing Certificates

This section describes how to manage SSL certificates in Directory Server.

To run SSL on Directory Server, you must either use a self-signed
certificate or a Public Key Infrastructure (PKI) solution.

The PKI solution involves an external Certificate Authority (CA). For
a PKI solution, you need a CA-signed server certificate, which contains both
a public key and a private key. This certificate is specific to one Directory Server.
You also need a trusted CA certificate, which contains a public key. The trusted
CA certificate ensures that all server certificates from your CA are trusted.
This certificate is sometimes called a CA root key or root certificate.

Note –

If you are using certificates for test purposes, you probably
want to use self-signed certificates. However, in production, using self-signed
certificates is not very secure. In production, use trusted Certificate Authority
(CA) certificates.

The procedures in this section use the dsadm and dsconf commands. For information about these commands, see the dsadm(1M) and dsconf(1M) man pages.

This section provides the following information about configuring certificates
on Directory Server:

To View the Default Self-Signed Certificate

When a Directory Server instance is first created, it contains a
default self-signed certificate. A self-signed certificate is
a public and private key pair, where the public key is signed by the private
key. A self-signed certificate is valid for 24 months.

In order to completely identify the server, Certificate Authorities
might require all of the attributes that are shown in this example. For a
description of each attribute, see the dsadm(1M) man page.

When you request a certificate by using dsadm request-cert,
the resulting certificate request is a binary certificate request unless you
specify ASCII as output format. If you specify ASCII, the resulting certificate
request is a PKCS #10 certificate request in PEM format. PEM is the Privacy
Enhanced Mail format specified by RFCs 1421 through 1424 (http://www.ietf.org/rfc/rfc1421.txt) and is used to represent a base64-encoded certificate request
in US-ASCII characters. The content of the request looks similar to the following
example:

You must save the request at a secure place for future reference. You
may need the request for renewal.

Transmit the certificate request to your
Certificate Authority, according to its procedures.

The process for obtaining your Certificate Authority certificate
depends on the certificate authority that you use. Some commercial CAs provide
a website that allows you to automatically download the certificate. Other
CAs will send it to you in email upon request.

After you have sent your request, you must wait for the CA to respond
with your certificate. Response time for your request varies. For example,
if your CA is internal to your company, the CA might only take a day or two
to respond to your request. If your selected CA is external to your company,
the CA could take several weeks to respond to your request.

Save the certificate that you receive from the Certificate Authority.

Back up your certificates in a safe location. If you ever lose
the certificates, you can reinstall them by using your backup file. You can
save them in text files. The PKCS #11 certificate in PEM format looks similar
to the following example:

By default, an instance of Directory Server contains a default server
certificate called defaultCert. The text Same
as issuer indicates that the default certificate is a self-signed
server certificate.

To Export and Import a CA-Signed Server Certificate

In some cases you might want to export the public and private keys of
a certificate so that you can later import the certificate. For example, you
might want the certificate to be used by another server.

The commands in this procedure can be used with certificates that contain
wild cards, for example "cn=*,o=example".

Configuring the Certificate Database Password

By default, Directory Server manages the SSL certificate database
password internally through a stored password. When managing certificates,
the user does not need to type a certificate password or specify the password
file. This option is not very secure because the password is only hidden,
not encrypted.

However, if you want to have more control over the use of certificates,
you can configure the server so that the user is prompted for a password on
the command line. In this case, the user must type the certificate database
password for all dsadm subcommands except autostart, backup, disable-service, enable-service, info, reindex, restore, and stop. The certificate database is located in the directory instance-path/alias.

To Configure the Server So the User is Prompted for
a Certificate Password