Show Table of Contents
Appendix B. Working with certmonger
Part of managing machine authentication is managing machine certificates. On clients, IdM manages the certificate lifecycle with the certmonger service, which works together with the certificate authority (CA) provided by IdM.
certmongerdaemon and its command-line clients simplify the process of generating public/private key pairs, creating certificate requests, and submitting requests to the CA for signing. As part of managing certificates, the
certmongerdaemon monitors certificates for expiration and can renew certificates that are about to expire. The certificates that
certmongermonitors are tracked in files stored in a configurable directory. The default location is
certmongeruses the IdM
getcertcommand to manage all certificates. As covered in Section 3.4, “Examples: Installing with Different CA Configurations”, an IdM server can be configured to use different types of certificate authorities. The most common (and recommended) configuration is to use a full CA server, but it is also possible to use a much more limited, self-signed CA. The exact
getcertcommand used by
certmongerto communicate with the IdM backend depends on which type of CA is used. The
ipa-getcertcommand is used with a full CA, while the
selfsign-getcertcommand is used with a self-signed CA.
Because of general security issues, self-signed certificates are not typically used in production, but can be used for development and testing.
B.1. Requesting a Certificate with certmonger
With the IdM CA,
Certificates and keys are stored locally in plaintext files (
.pem) 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:
# ipa-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.
When requesting a certificate to be used with an IdM service, the
-Koption is required to specify the service principal. Otherwise,
certmongerassumes the certificate is for a host. The
-Noption must specify the certificate subject DN, and the subject base DN must match the base DN for the IdM server, or the request is rejected.
$ ipa-getcert request -d /etc/httpd/alias -n Server-Cert -K HTTP/client1.example.com -N 'CN=client1.example.com,O=EXAMPLE.COM'
Example B.1. Using certmonger for a Service
$ ipa-getcert request -r -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
The options vary depending on whether you are using a self-signed certificate (
selfsign-getcert) and the desired configuration for the final certificate, as well as other settings. In Example B.1, “Using certmonger for a Service”, these are common options:
-roption will automatically renew the certificate if the key pair already exists. This is used by default.
-foption stores the certificate in the given file.
-koption either stores the key in the given file or, if the key file already exists, uses the key in the file.
-Noption gives the subject name.
-Doption gives the DNS domain name.
-Uoption sets the extended key usage flag.