Chapter 25. Understanding the certificates used internally by IdM
You can install a Red Hat Identity Management (IdM) server with an integrated certificate authority (CA) or without a CA. The certificates necessary to access and administer IdM are managed differently depending on whether your CA is integrated or not:
-
Integrated CA: certificates are automatically created and tracked by
certmonger.certmongerautomatically renews the certificates, ensuring a continuing validity of your IdM service. - Without a CA: certificates are requested from a third-party authority. In this case, you need to monitor their expiration and ensure they are renewed to ensure the continuing validity of your IdM service.
25.1. About the internal certificates in IdM
Red Hat Identity Management (IdM) uses many services accessed by using a network, including an LDAP server and an HTTP server. You access these services by using an SSL/TLS port, which requires a server certificate. You require the HTTP and LDAP server certificates during the installation of the IdM server.
You can obtain certificates in multiple ways depending on how you install and configure IdM:
With an integrated CA that can be either self-signed or signed by an external CA: IdM issues all the certificates for the users, hosts, and services managed by IdM and you do not need to provide a certificate file.
certmongerautomatically monitors the expiry dates of the certificates and they are automatically renewed when required.With an externally signed CA: the installation is a multiple step process.
-
You need to run the installation with the
--external-caoption to generate a CSR. - Submit the CSR to the external CA and retrieve the issued certificate and CA certificate chain as a PEM file or Base64 encoded certificate.
Run the IdM server install again, specifying the location and names of the newly-issued CA certificate and CA chain file. Your IdM certificate authority is configured as a subCA of the external CA and this subCA issues the required HTTP and LDAP server certificates.
certmongerautomatically monitors the expiry dates of the certificates and they are automatically renewed when required.
-
You need to run the installation with the
Without a CA: requires you to request the following certificates from a third-party authority:
- An LDAP server certificate
- An Apache server certificate
- A PKINIT certificate
Full CA certificate chain of the CA that issued the LDAP and Apache server certificates
These certificates are not tracked by
certmongerand an administrator is responsible for renewing them before they reach their expiration date.
Additional resources
25.2. Certificates internal to IdM
Your internal certificates can depend on how you installed IdM and what components were included in that installation. Depending on that installation, you might have the following certificates stored on your system.
IdM CA certificate
The IdM CA certificate is used by IdM to sign all other certificates. Note that it is not present in CA-less installations.
| caSigningCert | Description |
|---|---|
| File system location |
|
| LDAP location |
|
| Issuer | Self-signed or signed by an external CA |
| Subject |
Note that this is the default value but it can be customized during the IdM server installation. |
| Additional information |
Must have |
External CA certificate
If you are using an external CA, the chain of external CAs must be available in IdM to validate IdM certificates. For a CA-less installation, the external CA certificate must be present in various locations, including LDAP and in the /etc/ipa/ca.crt directory to validate HTTPD and LDAP certificates.
You do not have to manually add the external CA certificate to all the required locations as it is done automatically during the installation. However, if the external CA certificate is updated later, you should follow the steps in Renewing the IdM CA renewal server certificate using an external CA to ensure the new certificate is added to every location where it is required.
| External certificate | Description |
|---|---|
| File system location |
|
| LDAP location |
|
| Issuer | External CA-signed |
| Subject | External CA subject |
| Additional information |
You must have all the certificates in the chain in DER format and you must import them into LDAP. Must have |
Subsystem CA certificate
This certificate is used to authenticate to the LDAP server when writing to the LDAP database. This certificate is not present in CA-less installations.
| subsystemCert | Description |
|---|---|
| File system location |
|
| LDAP location |
|
| Issuer | IPA CA |
| Subject |
|
| Additional information |
Be wary of a serial and blob mismatch in LDAP. For example, |
Audit signing certificate
This certificate is used to sign the audit logs. Note that it is not present in CA-less installations.
| auditSigningCert | Description |
|---|---|
| File system location |
|
| LDAP location |
No dedicated LDAP location, shared via |
| Issuer | IPA CA |
| Subject |
|
| Additional information |
Must have |
OCSP signing certificate
This certificate is used to provide Online Certificate Status Protocol (OCSP) services. Note that it is not present in CA-less installations.
| ocspSigningCert | Description |
|---|---|
| File system location |
|
| LDAP location |
No dedicated LDAP location, shared via |
| Issuer | IPA CA |
| Subject |
|
| Additional information |
Tomcat servlet certificate
This certificate is used when a client contacts the PKI. Note that this server certificate is specific to the host and it is not present in CA-less installations.
| Server-Cert | Description |
|---|---|
| File system location |
|
| LDAP location | |
| Issuer | IPA CA |
| Subject | CN=$HOSTNAME,O=REALM.NAME |
| Additional information |
Registration authority certificate
Certificate used by certmonger as well as by the IdM framework to authenticate to the PKI. For example, if you run ipa cert-show 1, HTTPD communicates with the PKI and authenticates with this certificate. Not present in CA-less installations.
| RA agent | Description |
|---|---|
| File system location |
|
| LDAP location |
|
| Issuer | IPA CA |
| Subject |
|
| Additional information |
Be wary of a serial and blob mismatch in LDAP. For example, |
HTTPD front end certificate
Certificate used for the HTTPD frontend to secure connections to the Web UI and API. Must be present.
| HTTPD | Description |
|---|---|
| File system location |
|
| LDAP location | |
| Issuer | IPA CA or external CA in CA-less installations |
| Subject |
|
| Additional information |
Must contain a |
LDAP TLS and STARTTLS certificate
Certificate used for LDAP TLS and STARTTLS connections. Must be present.
| LDAP | Description |
|---|---|
| File system location |
|
| LDAP location | |
| Issuer | IPA CA or external CA in CA-less installations |
| Subject |
|
| Additional information |
Must contain a |
KDC certificate
Certificate used for PKINIT for the IdM KDC.
| KDC | Description |
|---|---|
| File system location |
|
| LDAP location | |
| Issuer | IPA CA or external CA in CA-less installations |
| Subject |
|
| Additional information |
Must have extended key usage |
25.3. IdM internal certificate renewal process
By default, certmonger tracks the internal certificates and triggers the renewal and requests the IdM CA to issue a new certificate.
If you are using an external CA and your internal certificates were issued by this CA, they are not automatically renewed. In this case, you should monitor the expiry dates of your certificates to ensure you renew them before they expire. The renewal process is time consuming and if you do not track the expiry dates carefully, your certificates will expire and some services will no longer be available.
If your internal Red Hat Identity Management (IdM) certificates expire, IdM fails to start.
The IdM CA renewal server renews the shared internal certificates 28 days before their expiration date. certmonger triggers this renewal and uploads the new certificate into cn=<nickname>,cn=ca_renewal,cn=ipa,cn=etc,$BASEDN. certmonger also triggers the renewal process on the other IdM servers but as it is executed on an non-CA renewal server, it does not request a new certificate but downloads the certificate from LDAP. Note that the Server-Cert cert-pki-ca, HTTP, LDAP, and PKINIT certificates are specific to each replica, containing the hostname in their subject.
If you manually renew a shared certificate with getcert before a certificate expires, the renewal process is not triggered on the other replicas and you must run getcert on the other replicas to perform the download of the renewed certificate from LDAP.
