7.6. Using certutil
certutil, which locally creates self-signed CA and client certificates, certificate databases, and keys. The default location for the Directory Server certutil tool is
certutilcan also be downloaded from https://ftp.mozilla.org/pub/security/nss/releases/.
7.6.1. Creating Directory Server Certificates through the Command Line
- Open the directory where the Directory Server certificate databases are stored.
[root@server ~]# cd /etc/dirsrv/slapd-instance_name
- Make a backup copy of all of the filed in the directory as a precaution. If something goes awry with while managing certificates, the databases can then be restored. For example:
[root@server ~]# tar -cf /tmp/db-backup.tar *
- Create a password file for the security token password.
[root@server ~]# vi /tmp/pwdfile secretpwThis password locks the server's private key in the key database and is used when the keys and certificates are first created. The password in this file is also the default password to encrypt PK12 files used by
pk12util. Because this password is stored in plaintext, the password file should be owned by the user as which Directory Server runs, by default
nobody. If a different account was set during the installation, like Red Hat recommends, use this account and group instead for a higher security. The password file must be set as read-only for the Directory Server user and allow no access to anyone else (mode
0400). It's a good idea to have a secure backup of this file.
- Set the environment variable for the shell to include the
certutildirectory path. For example:
[root@server ~]# export PATH=/usr/bin/:$PATHThe command varies depending on the shell.
- Create the key and certificate databases databases.
[root@server ~]# certutil -N -d . -f /tmp/pwdfile
- Generate the self-signed CA certificate.
certutilcreates the required key pairs and the certificate. This certificate is used to generate the other server certificates and can be exported for use with other servers and clients.
[root@server ~]# certutil -S -n "CA certificate" -s "cn=My Org CA cert,dc=example,dc=com" -2 -x -t "CT,," -m 1000 -v 120 -d . -k rsa -f /tmp/pwdfile
- Generate the Directory Server client certificate.
[root@server ~]# certutil -S -n "Server-Cert" -s "cn=FQDN" -c "CA certificate" -t "u,u,u" -m 1001 -v 120 -d . -k rsa -f /tmp/pwdfileThe value of the
-sargument is very important. The leftmost RDN must be
cn=FQDN (where FQDN is the fully-qualified host and domain name of the Directory Server). For example, to issue a certificate for a server with the name
ldap.example.com, specify at least
-s "cn=ldap.example.com"; it is beneficial to have a more descriptive name to help with server identification, such as
"cn=ldap.example.com,ou=DS1". The FQDN must be available for DNS and reverse DNS lookups to Directory Server clients because certificate validation may fail if the clients cannot properly resolve the FQDN, and some clients refuse to connect if a server certificate does not have its FQDN in the subject. Additionally, using the format
cn=hostname.domain is essential for Directory Server clients to protect themselves from man in the middle attacks.
NoteThere should only be one
cnin a certificate subject name. To add detail to the subject name, use
cnas the RDN and another attribute — like
c— for the other subject name elements.To provide a subjectAltName, as well as the nickname, use the
-8argument in addition to the
-sargument.To use the Directory Server behind a DNS round robin or any other scheme which aliases a single server certificate to multiple host names, see the TLS/SSL information about server name wildcards or subjectAltName.Server certificates for other servers are created using a similar command as for the Directory Server certificate. Make sure that every
-noption (nickname) and
-moption (serial number) is unique for every certificate, and make sure that the
-soption gives the correct FQDN for the server.
NoteKeep careful track on the numbers set with the
-moption sets the unique identifier for the server certificate, and a CA cannot issue two certificates with the same ID. Keep a log of issued serial numbers so that no number is ever duplicated.
- Export the CA certificate for use with other servers and clients. A client usually requires the CA certificate to validate the server certificate in an TLS/SSL connection. Use
certutilto export the CA certificate in ASCII/PEM format:
[root@server ~]# certutil -d . -L -n "CA certificate" -a > cacert.ascThe way that the CA certificate is imported is different for every client. For example,
certutilcan import a CA certificate into another Directory Server certificate database:
[root@server ~]# cd /etc/dirsrv/slapd-otherserver [root@server ~]# certutil -A -d . -n "CA certificate" -t "CT,," -a -i cacert.asc
pk12utilto export other server certificates and keys created with
certutilso that they can be used on a remote server.
[root@server ~]# pk12util -d . -o ldap1.p12 -n Server-Cert -w /tmp/pwdfile -k /tmp/pwdfileThe
-wargument is the password used to encrypt the
.p12file for transport. The
-kargument specifies the password for the key database containing the server certificate being exported to
- If the Directory Server will run with TLS/SSL enabled, then create a password file (
pin.txt) for the server to use so it will not prompt you for a password every time it restarts. Creating the password file is described in Section 7.4.4, “Creating a Password File for the Directory Server”.
certutilare automatically available in the Encryption tab of the Console. There is no need to import them because they are already in the certificate database.
7.6.2. certutil Usage
certutilcan be used for a variety of tasks to manage certificates and keys, such as generating certificate requests and removing certificates from the certificate database. Some of the most common options are listed in Table 7.1, “certutil Options”. For the full list of commands and arguments, run
certutil -Hfrom the command line.
Table 7.1. certutil Options
|-x||Creates a self-signed CA certificate.|
|-S||Creates a server or client certificate.|
|-R||Generates a certificate request.|
|-N||Creates new security databases.|
|-L||Lists all of the certificates in the database.|
|-A||Adds a certificate to the certificate database.|
|-n||Gives the name of the certificate.|
|-d||Certificate database directory; this is the directory for the subsystem instance.|
|-m||The serial number for the certificate.|
|-k|| The key type to use; the only option is |
|-g||The key size. The recommended size for RSA keys is 2048.|
|-s||The subject name of the certificate.|
|-t||The trust arguments for the certificate, meaning the purposes for which the certificate is allowed to be used.|
|-v||The validity period, in months.|
|numbers 1-8|| These set the available certificate extensions. Only eight can be specified through the |
|-a||Outputs the certificate request to an ASCII file instead of binary.|
|-o||The output file to which to save the certificate request.|
|-i||An input file containing a certificate.|
|-f||The path to a password file for the security databases password.|
Table 7.2. certutil Examples
|certutil -L -d .||Lists the certificates in the database.|
|certutil -N -d .|| Creates new key (|
|certutil -S -n "CA certificate" -s "cn=My Org CA cert,dc=example,dc=com" -2 -x -t "CT,," -m 1000 -v 120 -d . -k rsa||Creates a self-signed CA certificate.|
|certutil -S -n "Server-Cert" -s "cn=FQDN" -c "CA certificate" -t "u,u,u" -m 1001 -v 120 -d . -k rsa||Creates a client certificate.|
|certutil -L -d . -n "cert_name"||"Pretty prints" the specified certificate; the cert_name can specify either a CA certificate or a client certificate.|
|certutil -L -d . -n "cert_name" > certfile.asc||Exports the specified certificate out of the database to ASCII (PEM) format.|
|certutil -L -d . -n "cert_name" -r > certfile.bin|| Exports the specified certificate out of the database to binary format; this can be used with Directory Server attributes such as |