12.2. Requesting a Self-signed Certificate with certmonger
certmonger, use the
.pemextension or in an NSS database, identified by the certificate nickname. When requesting a certificate, then, the request should identify the location where the certificate will be stored and the nickname of the certificate. For example:
[root@server ~]# selfsign-getcert request -d /etc/pki/nssdb -n Server-Cert
/etc/pki/nssdbfile is the global NSS database, and
Server-Certis the nickname of this certificate. The certificate nickname must be unique within this database.
-rautomatically renews the certificate when its expiration date is close if the key pair already exists. This option is used by default.
-fstores the certificate in the given file.
-keither stores the key in the given file or, if the key file already exists, uses the key in the file.
-Kgives the Kerberos principal name of the service that will be using the certificate;
-Kis required when requesting a certificate from an IdM server and optional when requesting a self-signed or locally-signed certificate
-Ngives the subject name.
-Drequests a DNS domain name to be included in the certificate as a
-Usets the extended key usage flag.
-Arequests an IP address to be included in the certificate as a
-Isets a name for the task.
certmongeruses this name to refer to the combination of storage locations and request options, and it is also displayed in the output of the
getcert listcommand. If you do not specify this option,
certmongerassigns an automatically-generated name for the task.
-Aoptions according to the CA's own policies. For example, IdM requires that
-Nagree with the local host name. Certificates generated using the
local-getcertcommands, on the other hand, agree with the options that you specify because these commands do not enforce any policy.
Example 12.1. Using certmonger for a Service
[root@server ~]# selfsign-getcert request -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key -N CN=`hostname --fqdn` -D `hostname` -U id-kp-serverAuth