Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 26. 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.

26.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.

    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

26.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.

caSigningCertDescription

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 certificateDescription

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.

subsystemCertDescription

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.

auditSigningCertDescription

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.

ocspSigningCertDescription

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-CertDescription

File system location

  • Nickname=Server-Cert cert-pki-ca in /etc/pki/pki-tomcat/alias nssdb+

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 agentDescription

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.

HTTPDDescription

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=$HOSTNAME,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/$HOSTNAME@REALM, DNS name = $HOSTNAME.

LDAP TLS and STARTTLS certificate

Certificate used for LDAP TLS and STARTTLS connections. Must be present.

LDAPDescription

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=$HOSTNAME,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/$HOSTNAME@REALM, DNS name = $HOSTNAME.

KDC certificate

Certificate used for PKINIT for the IdM KDC.

KDCDescription

File system location

/var/kerberos/krb5kdc/kdc.crt

LDAP location

 

Issuer

IPA CA or external CA in CA-less installations

Subject

CN=$HOSTNAME,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 = $HOSTNAME.

26.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 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.

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.

26.4. Additional resources

Red Hat logoGithubRedditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

© 2024 Red Hat, Inc.