Chapter 25. Understanding the certificates used internally by IdM
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 . certmonger automatically 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 Enterprise Linux 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. certmonger automatically 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-ca option 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. certmonger automatically monitors the expiry dates of the certificates and they are automatically renewed when required. 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 certmonger and an administrator is responsible for renewing them before they reach their expiration date. Additional resources Planning your CA services 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 nickname=caSigningCert cert-pki-ca in /etc/pki/pki-tomcat/alias NSS database nickname=REALM.NAME IPA CA in /etc/ipa/nssdb/ and /etc/ipa/ca.crt (populated from LDAP) LDAP location cn=REALM.NAME IPA CA,cn=certificates,cn=ipa,cn=etc,dc=realm,dc=name and ou=authorities,ou=ca,o=ipaca Issuer Self-signed or signed by an external CA Subject O = REALM.NAME, CN = Certificate Authority Note that this is the default value but it can be customized during the IdM server installation. Additional information Must have CA:true critical constraint and must have CT,C,C trust flags in the NSS database. 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. Note 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 /etc/pki/pki-tomcat/alias nssdb and as part of chain in /etc/ipa/ca.crt (populated from LDAP) LDAP location cn=SUBJECT,cn=certificates,cn=ipa,cn=etc,dc=realm,dc=name and ou=authorities,ou=ca,o=ipaca 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 CT,C,C trust flags in the NSS database. 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 nickname=subsystemCert cert-pki-ca in /etc/pki/pki-tomcat/alias nssdb LDAP location uid=pkidbuser,ou=people,o=ipaca Issuer IPA CA Subject CN=CA Subsystem,O=REALM.NAME Additional information Be wary of a serial and blob mismatch in LDAP. For example, 2;SERIAL;CN=Certificate Authority,O=REALM.NAME;CN=CA Subsystem,O=REALM.NAME and userCertificate must match the one on the file system. 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 nickname=auditSigningCert cert-pki-ca in /etc/pki/pki-tomcat/alias nssdb LDAP location No dedicated LDAP location, shared via ou=certificateRepository,ou=ca,o=ipaca Issuer IPA CA Subject CN=CA Audit,O=REALM.NAME Additional information Must have ,,P trust flags in the NSS database. 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 nickname=ocspSigningCert cert-pki-ca in /etc/pki/pki-tomcat/alias nssdb LDAP location No dedicated LDAP location, shared via ou=certificateRepository,ou=ca,o=ipaca Issuer IPA CA Subject CN=OCSP Subsystem,O=REALM.NAME 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 Nickname=Server-Cert cert-pki-ca in /etc/pki/pki-tomcat/alias nssdb+ LDAP location Issuer IPA CA Subject CN=USDHOSTNAME,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 /var/lib/ipa/ra-agent.pem (used to be in /etc/httpd/alias before RHEL 7.4) LDAP location uid=ipara,ou=people,o=ipaca Issuer IPA CA Subject CN=IPA RA,O=REALM.NAME Additional information Be wary of a serial and blob mismatch in LDAP. For example, 2;SERIAL;CN=Certificate Authority,O=REALM.NAME;CN=IPA RA,O=REALM.NAME and userCertificate must match the one on the file system. 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 /var/lib/ipa/certs/httpd.crt (used to be in /etc/httpd/alias before RHEL 8) LDAP location Issuer IPA CA or external CA in CA-less installations Subject CN=USDHOSTNAME,O=REALM.NAME Additional information Must contain a Certificate Subject Alt Name extension with principal name as otherName = 1.3.6.1.4.1.311.20.2.3;UTF8:HTTP/USDHOSTNAME@REALM, DNS name = USDHOSTNAME . LDAP TLS and STARTTLS certificate Certificate used for LDAP TLS and STARTTLS connections. Must be present. LDAP Description File system location nickname=Server-Cert in /etc/dirsrv/slapd-DOMAIN NSS database (can be other nickname, matching nsSSLPersonalitySSL in dse.ldif ) LDAP location Issuer IPA CA or external CA in CA-less installations Subject CN=USDHOSTNAME,O=REALM.NAME Additional information Must contain a Certificate Subject Alt Name extension with principal name as otherName = 1.3.6.1.4.1.311.20.2.3;UTF8:ldap/USDHOSTNAME@REALM, DNS name = USDHOSTNAME . KDC certificate Certificate used for PKINIT for the IdM KDC. KDC Description File system location /var/kerberos/krb5kdc/kdc.crt LDAP location Issuer IPA CA or external CA in CA-less installations Subject CN=USDHOSTNAME,O=REALM.NAME Additional information Must have extended key usage id-pkinit-KPkdc (1.3.6.1.5.2.3.5) , principal name as otherName = 1.3.6.1.4.1.311.20.2.3;UTF8:krbtgt/REALM@REALM, DNS name = USDHOSTNAME . 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. Warning If your internal Red Hat Enterprise Linux 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,USDBASEDN . 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. Note 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. 25.4. Additional resources Using IdM CA renewal server Renewing expired system certificates when IdM is offline Replacing the web server and LDAP server certificates if they have not yet expired on an IdM replica Replacing the web server and LDAP server certificates if they have expired in the whole IdM deployment