This is the second installment in a series about using Red Hat Identity Management (IdM) on Red Hat Enterprise Linux and Fedora (using the upstream FreeIPA project).

As described in part 1, IdM makes it very easy to build an enterprise-grade identity management solution, including a full enterprise PKI solution providing complete x509 certificate life cycle management.

Most organizations start with a simple self-signed Certificate Authority (CA) certificate, perhaps generated using OpenSSL; with a little configuration and a few commands, one can build a self-signed root CA and begin issuing server certificates. However, as the organization grows, this model quickly leads to scaling problems. This article will discuss how to handle some of these scenarios to avoid problematic security issues.

Scalability and Risk

If scaling is not done properly, workload will demand that more people are given access to issue certificates. More people with access increases the risk of a server RSA key being compromised --- the more people involved, the more risk is involved, and cost of an RSA key compromise is high because recovery involves revoking certificates.

Beyond that scenario, it's even possible that user certificates will be desired, for VPN access for example, which further exacerbates the need for a certificate life cycle management solution. Internally, Red Hat IT had this exact same problem.

OpenSSL is a great tool chain, but eventually home-grown OpenSSL solutions end up being one hack upon another. Fortunately, Red Hat Identity Management painlessly fills this gap.

Mitigating Risk with IDM

When you install IdM, it creates its own root CA certificate by default. Machine, service and user certificates can be issued from IdM via a simple GUI, or simple shell command--- both of which are backed by a full Role Based Access Control (RBAC) model.

IdM also provides native support for Offline Certificate Status Protocol (OCSP), meaning certificates may be revoked and clients can verify the web service they connect to are using a valid certificate. This is all configured automatically for you at IdM installation. IdM can also have its CA certificate signed by an external authority wherein IdM acts as an intermediary certificate authority.

It is generally considered a best practice to have an offline root CA. One can achieve this by generating your root CA with OpenSSL on a machine disconnected from the network, then storing your OpenSSL CA files on a thumb-drive in a physical safe. You use this offline CA to sign the IdM CSR once, then finally give the thumb-drive to your legal department to store in a safe, under lock and key.

In any case, simply use the –external-ca flag when running ipa-server-install, and follow the on-screen directions to have IdM serve as an intermediate CA. For example:

ipa-server-install -r IPA.EXAMPLE.COM -n ipa.example.com --setup-dns –forwarder=10.0.2.2 –forwarder=10.0.1.2 --zonemgr=dns@example.com --external-ca

This generates a certificate signing request (CSR) to be signed by your Root CA.  Once signed:

/usr/sbin/ipa-server-install --external-cert-file=/tmp/idm_cert.p7

When installing a replica or client, the installer will automatically place the external root CA in /etc/ipa/ca.crt, rather than the IdM intermediate CA certificate.

Generating Certificates

Once you have your IdM instance installed, it remarkably easy to issue server certificates --- there are two primary methods that I will discuss in this article.

Method A: Automatic Certificate Generation

When registering the IdM client, simply use the –request-cert flag and a certificate will automatically be issued for the client machine. Moreover, that client certificate will be tracked and automatically renewed before it expires!

ipa-client-install --request-cert

This creates an NSS DB at /etc/ipa/nssdb populated with the full certificate chain plus the client's certificate.

[user@shell nssdb]$ certutil -L -d /etc/ipa/nssdb

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

CN=CA Signing Certificate,O=EXAMPLE PKI CT,C,C
EXAMPLE.COM IPA CA CT,C,C
Local IPA host u,u,u

Adding the -n "Local IPA host" option will display the full decoded certificate.

In order to track and renew the certificate locally, the certmonger service is automatically configured.  You can fetch details of this with:

/usr/bin/ipa-getcert list

These automatically issued "machine certificates" can be used for anything requiring a host certificate, including Apache or other services. The downside is that you need to point these services to the /etc/ipa/nssdb DB directly --- SELinux will probably get in the way (which is a good thing).

You can export the cert into a PEM file for Apache to consume, but be aware you'll need to re-export the certificate once it renews in the NSS DB.

Method B: Certificate Signing Request

If you are running a service, you probably require a more flexible certificate. For example, you may want a SubjectAltName, or you may want to use the same certificate on multiple servers in a web farm. To handle these scenarios, simply generate a certificate signing request (CSR):

[user@shell example]$ openssl genrsa 2048 > example.example.com.key
Generating RSA private key, 2048 bit long modulus
.......................+++
.......+++
e is 65537 (0x10001)
[user@shell example]$ openssl req -new -key example.example.com.key -out example.example.com.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:US
State or Province Name (full name) [North Carolina]:California
Locality Name (eg, city) [Raleigh]:San Jose
Organization Name (eg, company) [Example]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:example.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:

An optional company name []:

Now, you can take this CSR and submit it via the IdM GUI, which will return a certificate.

In my example, I'll use the command line, as I find it more useful. Make sure you have the ipa-admintools package installed and you kinit using a principal with sufficient permissions:

[user@shell example]$ kinit admin
Password for admin@EXAMPLE.COM: 
[user@shell example]$ klist
Ticket cache: KEYRING:persistent:2003:2003
Default principal: admin@EXAMPLE.COM

Valid starting Expires Service principal
05/13/2016 16:50:45 05/14/2016 16:50:00 krbtgt/EXAMPLE.COM@EXAMPLE.COM

You'll want to add a new service in IdM, and services are linked to the host, so make sure the host exists in IdM first. For a load balancer certificate, just create a basic host entry:

[user@shell example]$ ipa host-add --ip-address 172.16.10.176 example.example.com
--------------------------------
Added host "example.example.com"
--------------------------------
 Host name: example.example.com
 Principal name: host/example.example.com@EXAMPLE.COM
 Password: False
 Keytab: False
 Managed by: example.example.com

[user@shell example]$ ipa service-add HTTP/example.example.com
----------------------------------------------------
Added service "HTTP/example.example.com@EXAMPLE.COM"
----------------------------------------------------
 Principal: HTTP/example.example.com@EXAMPLE.COM
 Managed by: example.example.com

Now you may submit the CSR for processing, then download the signed certificate in PEM format:

[user@shell example]$ ipa cert-request --add --principal=HTTP/example.example.com example.example.com.csr 
 Certificate: [...]
 Subject: CN=example.example.com,OU=pki-ipa,O=IPA
 Issuer: CN=Certificate Authority,O=EXAMPLE.COM
 Not Before: Fri May 13 20:03:19 2016 UTC
 Not After: Mon May 14 20:03:19 2018 UTC
 Fingerprint (MD5): d6:f7:3b:cc:b3:bd:93:5d:29:7b:cf:44:24:2f:41:89
 Fingerprint (SHA1): e5:c6:d7:18:11:5c:b7:bd:4e:d1:a4:69:26:15:9b:5c:77:df:58:d6
 Serial number: 536739843
 Serial number (hex): 0x1FFE0003


[user@shell example]$ ipa cert-show 536739843 --out example.example.com.crt
 Certificate: [...]
 Subject: CN=example.example.com,OU=pki-ipa,O=IPA
 Issuer: CN=Certificate Authority,O=EXAMPLE.COM
 Not Before: Fri May 13 20:03:19 2016 UTC
 Not After: Mon May 14 20:03:19 2018 UTC
 Fingerprint (MD5): d6:f7:3b:cc:b3:bd:93:5d:29:7b:cf:44:24:2f:41:89
 Fingerprint (SHA1): e5:c6:d7:18:11:5c:b7:bd:4e:d1:a4:69:26:15:9b:5c:77:df:58:d6
 Serial number (hex): 0x1FFE0003
 Serial number: 536739843

You may verify the certificate with OpenSSL:

[user@shell example]$ openssl x509 -in example.example.com.crt -noout -subject -issuer -enddate -ocsp_uri 
subject= /O=IPA/OU=pki-ipa/CN=example.example.com
issuer= /O=EXAMPLE.COM/CN=Certificate Authority
notAfter=May 14 20:03:19 2018 GMT
http://ipa-ca.example.com:80/ca/ocsp

Note: IdM automatically configures an OCSP service and embeds the URI in all certificates issued.

Conclusion

That is it! With a minimal amount of work, you can install an enterprise-grade PKI system and begin issuing server and user certificates immediately. Moreover, all the components are fully configurable and expandable, allowing you to scale and customize your IdM system to meet your organization's PKI needs.  The IdM documentation is a great resource to use for more information, as well as additional customizations.

Last updated: March 15, 2023