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