Search

Appendix B. Working with certmonger

download PDF
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.
The certmonger daemon 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 certmonger daemon monitors certificates for expiration and can renew certificates that are about to expire. The certificates that certmonger monitors are tracked in files stored in a configurable directory. The default location is /var/lib/certmonger/requests.
certmonger uses the IdM getcert command 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 getcert command used by certmonger to communicate with the IdM backend depends on which type of CA is used. The ipa-getcert command is used with a full CA, while the selfsign-getcert command is used with a self-signed CA.

Note

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, certmonger uses the ipa-getcert command.
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
The /etc/pki/nssdb file is the global NSS database, and Server-Cert is 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 -K option is required to specify the service principal. Otherwise, certmonger assumes the certificate is for a host. The -N option 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:
  • The -r option will automatically renew the certificate if the key pair already exists. This is used by default.
  • The -f option stores the certificate in the given file.
  • The -k option either stores the key in the given file or, if the key file already exists, uses the key in the file.
  • The -N option gives the subject name.
  • The -D option gives the DNS domain name.
  • The -U option sets the extended key usage flag.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.