Chapter 5. Planning your CA services

Identity Management (IdM) in Red Hat Enterprise Linux provides different types of certificate authority (CA) configurations. The following sections describe different scenarios and provide advice to help you determine which configuration is best for your use case.

CA subject DN
The Certificate Authority (CA) subject distinguished name (DN) is the name of the CA. It must be globally unique in the Identity Management (IdM) CA infrastructure and cannot be changed after the installation. In case you need the IdM CA to be externally signed, you might need to consult the administrator of the external CA about the form your IdM CA Subject DN should take.

5.1. CA Services available in an IdM server

You can install an Identity Management (IdM) server with an integrated IdM certificate authority (CA) or without a CA.

Table 5.1. Comparing IdM with integrated CA and without a CA

 Integrated CAWithout a CA

Overview:

IdM uses its own public key infrastructure (PKI) service with a CA signing certificate to create and sign the certificates in the IdM domain.

  • If the root CA is the integrated CA, IdM uses a self-signed CA certificate.
  • If the root CA is an external CA, the integrated IdM CA is subordinate to the external CA. The CA certificate used by IdM is signed by the external CA, but all certificates for the IdM domain are issued by the integrated Certificate System instance.
  • Integrated CA is also able to issue certificates for users, hosts, or services.

The external CA can be a corporate CA or a third-party CA.

IdM does not set up its own CA, but uses signed host certificates from an external CA.

Installing a server 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

Limitations:

If the integrated CA is subordinate to an external CA, the certificates issued within the IdM domain are potentially subject to restrictions set by the external CA for various certificate attributes, such as:

  • The validity period.
  • Constraints on what subject names can appear on certificates issued by the IDM CA or its subordinates..
  • Constraints on whether the IDM CA can itself, issue subordinate CA certificates, or how "deep" the chain of subordinate certificates can go.

Managing certificates outside of IdM causes many additional activities, such as :

  • Creating, uploading, and renewing certificates is a manual process.
  • The certmonger service does not track the IPA certificates (LDAP server, Apache server, and PKINIT certificates) and does not notify you when the certificates are about to expire. The administrators must manually set up notifications for externally issued certificates, or set tracking requests for those certificates if they want certmonger to track them.

Works best for:

Environments that allow you to create and use your own certificate infrastructure.

Very rare cases when restrictions within the infrastructure do not allow you to install certificate services integrated with the server.

Note

Switching from the self-signed CA to an externally-signed CA, or the other way around, as well as changing which external CA issues the IdM CA certificate, is possible even after the installation. It is also possible to configure an integrated CA even after an installation without a CA. For more details, see Installing an IdM server: With integrated DNS, without a CA.

Additional resources

5.2. Guidelines for distribution of CA services

The following steps provide guidelines for the distribution of your certificate authority (CA) services.

Procedure

  1. Install the CA services on more than one server in the topology.

    Replicas configured without a CA forward all certificate operation requests to the CA servers in your topology.

    Warning

    If you lose all servers with a CA, you lose all the CA configuration without any chance of recovery. In this case you must configure a new CA and issue and install new certificates.

  2. Maintain a sufficient number of CA servers to handle the CA requests in your deployment.

See the following table for further recommendations on appropriate number of CA servers:

Table 5.2. Guidelines for setting up appropriate number of CA servers

Description of the deploymentSuggested number of CA servers

A deployment with a very large number of certificates issued

Three or four CA servers

A deployment with bandwidth or availability problems between multiple regions

One CA server per region, with a minimum of three servers total for the deployment

All other deployments

Two CA servers

Important

Four CA servers in the topology are usually enough if the number of concurrent certificate requests is not high. The replication processes between more than four CA servers can increase processor usage and lead to performance degradation.

5.3. Random serial numbers in IdM

As of RHEL 9.1, Identity Management (IdM) includes dogtagpki 11.2.0, which allows you to use Random Serial Numbers version 3 (RSNv3). The ansible-freeipa ipaserver role includes the ipaserver_random_serial_numbers variable with the RHEL 9.3 update.

With RSNv3 enabled, IdM generates fully random serial numbers for certificates and requests in PKI without range management. RSNv3 also prevents collisions in case you reinstall IdM. The size of each certificate serial number is up to 40-digit decimal values as RSNv3 uses a 128-bit random value for the serial number. This makes the number effectively random.

Note

Previously, the Dogtag upstream project used range-based serial numbers in order to ensure uniqueness across multiple clones. However, based on this experience, the Dogtag team determined that range-based serial numbers would not fit well into cloud environments with short-lived certificates.

RSNv3 is supported only for new IdM CA installations. By default, you install the first IdM CA when you install the primary IdM server by using the ipa-server-install command. However, if you originally installed your IdM environment without a CA, you can add the CA service later by using the ipa-ca-install command. To enable RSNv3, use the ipa-server-install or ipa-ca-install command with the --random-serial-numbers option.

If enabled, it is required to use RSNv3 on all public-key infrastructure (PKI) services in the deployment, including the CA and Key Recovery Authority (KRA). A check is performed when KRA is installed to automatically enable RSNv3 if it is enabled on the underlying CA.

Additional resources