Search

Chapter 14. Managing Subsystem Certificates

download PDF
This chapter gives an overview of using certificates: what types and formats are available, how to request and create them through the HTML end-entity forms and through the Certificate System Console, and how to install certificates in the Certificate System and on different clients. Additionally, there is information on managing certificates through the Console and configuring the servers to use them.

14.1. Required Subsystem Certificates

Each subsystem has a defined set of certificates which must be issued to the subsystem instance for it to perform its operations. There are certain details of the certificate contents that are set during the Certificate Manager configuration, with different considerations for constraints, settings, and attributes depending on the types of certificates; planning the formats of certificates is covered in the Types of Certificates section in the Red Hat Certificate System 9 Planning, Installation, and Deployment Guide (Common Criteria Edition).

14.1.1. Certificate Manager Certificates

When a Certificate Manager is installed, the keys and requests for the CA signing certificate, TLS server certificate, and OCSP signing certificate are generated. The certificates are created before the configuration can be completed.
The CA certificate request is either submitted as a self-signing request to the CA, which then issues the certificate and finishes creating the self-signed root CA, or is submitted to a third-party public CA or another Certificate System CA. When the external CA returns the certificate, the certificate is installed, and installation of the subordinate CA is completed.

14.1.1.1. CA Signing Key Pair and Certificate

Every Certificate Manager has a CA signing certificate with a public key corresponding to the private key the Certificate Manager uses to sign the certificates and CRLs it issues. This certificate is created and installed when the Certificate Manager is installed. The default nickname for the certificate is caSigningCert cert-instance_ID CA, where instance_ID identifies the Certificate Manager instance. The default validity period for the certificate is five years.
The subject name of the CA signing certificate reflects the name of the CA that was set during installation. All certificates signed or issued by the Certificate Manager include this name to identify the issuer of the certificate.
The Certificate Manager's status as a root or subordinate CA is determined by whether its CA signing certificate is self-signed or is signed by another CA, which affects the subject name on the certificates.
  • If the Certificate Manager is a root CA, its CA signing certificate is self-signed, meaning the subject name and issuer name of the certificate are the same.
  • If the Certificate Manager is a subordinate CA, its CA signing certificate is signed by another CA, usually the one that is a level above in the CA hierarchy (which may or may not be a root CA). The root CA's signing certificate must be imported into individual clients and servers before the Certificate Manager can be used to issue certificates to them.

Note

The CA name cannot  be changed or all previously-issued certificates are invalidated. Similarly, reissuing a CA signing certificate with a new key pair invalidates all certificates that were signed by the old key pair.

14.1.1.2. OCSP Signing Key Pair and Certificate

The subject name of the OCSP signing certificate is in the form cn=OCSP cert-instance_ID CA, and it contains extensions, such as OCSPSigning and OCSPNoCheck, required for signing OCSP responses.
The default nickname for the OCSP signing certificate is ocspSigningCert cert-instance_ID, where instance_ID CA identifies the Certificate Manager instance.
The OCSP private key, corresponding to the OCSP signing certificate's public key, is used by the Certificate Manager to sign the OCSP responses to the OCSP-compliant clients when queried about certificate revocation status.

14.1.1.3. Subsystem Certificate

Every member of the security domain is issued a server certificate to use for communications among other domain members, which is separate from the server TLS certificate. This certificate is signed by the security domain CA; for the security domain CA itself, its subsystem certificate is signed by itself.
The default nickname for the certificate is subsystemCert cert-instance_ID.

14.1.1.4. TLS Server Key Pair and Certificate

Every Certificate Manager has at least one TLS server certificate that was first generated when the Certificate Manager was installed. The default nickname for the certificate is Server-Cert cert-instance_ID, where instance_ID identifies the Certificate Manager instance.
By default, the Certificate Manager uses a single TLS server certificate for authentication. However, additional server certificates can be requested to use for different operations, such as configuring the Certificate Manager to use separate server certificates for authenticating to the end-entity services interface and agent services interface.
If the Certificate Manager is configured for TLS-enabled communication with a publishing directory, it uses its TLS server certificate for client authentication to the publishing directory by default. The Certificate Manager can also be configured to use a different certificate for TLS client authentication.

14.1.1.5. Audit Log Signing Key Pair and Certificate

The CA keeps a secure audit log of all events which occurred on the server. To guarantee that the audit log has not been tampered with, the log file is signed by a special log signing certificate.
The audit log signing certificate is issued when the server is first configured.

Note

While other certificates can use ECC keys, the audit signing certificate must always use an RSA key.

14.1.2. Online Certificate Status Manager Certificates

When the Online Certificate Status Manager is first configured, the keys for all required certificates are created, and the certificate requests for the OCSP signing, TLS server, audit log signing, and subsystem certificates are made. These certificate requests are submitted to a CA (either a Certificate System CA or a third-party CA) and must be installed in the Online Certificate Status Manager database to complete the configuration process.

14.1.2.1. OCSP Signing Key Pair and Certificate

Every Online Certificate Status Manager has a certificate, the OCSP signing certificate, which has a public key corresponding to the private key the Online Certificate Status Manager uses to sign OCSP responses. The Online Certificate Status Manager's signature provides persistent proof that the Online Certificate Status Manager has processed the request. This certificate is generated when the Online Certificate Status Manager is configured. The default nickname for the certificate is ocspSigningCert cert-instance_ID, where instance_ID OSCP is the Online Certificate Status Manager instance name.

14.1.2.2. TLS Server Key Pair and Certificate

Every Online Certificate Status Manager has at least one TLS server certificate which was generated when the Online Certificate Status Manager was configured. The default nickname for the certificate is Server-Cert cert-instance_ID, where instance_ID identifies the Online Certificate Status Manager instance name.
The Online Certificate Status Manager uses its server certificate for server-side authentication for the Online Certificate Status Manager agent services page.
The Online Certificate Status Manager uses a single server certificate for authentication purposes. Additional server certificates can be installed and used for different purposes.

14.1.2.3. Subsystem Certificate

Every member of the security domain is issued a server certificate to use for communications among other domain members, which is separate from the server TLS certificate. This certificate is signed by the security domain CA.
The default nickname for the certificate is subsystemCert cert-instance_ID.

14.1.2.4. Audit Log Signing Key Pair and Certificate

The OCSP keeps a secure audit log of all events which occurred on the server. To guarantee that the audit log has not been tampered with, the log file is signed by a special log signing certificate.
The audit log signing certificate is issued when the server is first configured.

Note

While other certificates can use ECC keys, the audit signing certificate must always use an RSA key.

14.1.2.5. Recognizing Online Certificate Status Manager Certificates

Depending on the CA which signed the Online Certificate Status Manager's TLS server certificate, it may be necessary to get the certificate and issuing CA recognized by the Certificate Manager.
  • If the Online Certificate Status Manager's server certificate is signed by the CA that is publishing CRLs, then nothing needs to be done.
  • If the Online Certificate Status Manager's server certificate is signed by the same root CA that signed the subordinate Certificate Manager's certificates, then the root CA must be marked as a trusted CA in the subordinate Certificate Manager's certificate database.
  • If the Online Certificate Status Manager's TLS server certificate is signed by a different root CA, then the root CA certificate must be imported into the subordinate Certificate Manager's certificate database and marked as a trusted CA.
If the Online Certificate Status Manager's server certificate is signed by a CA within the selected security domain, the certificate chain is imported and marked when the Online Certificate Status Manager is configured. No other configuration is required. However, if the server certificate is signed by an external CA, the certificate chain has to be imported for the configuration to be completed.

Note

Not every CA within the security domain is automatically trusted by the OCSP Manager when it is configured. Every CA in the certificate chain of the CA configured in the CA panel is, however, trusted automatically by the OCSP Manager. Other CAs within the security domain but not in the certificate chain must be added manually.

14.1.3. Key Recovery Authority Certificates

The KRA uses the following key pairs and certificates:

14.1.3.1. Transport Key Pair and Certificate

Every KRA has a transport certificate. The public key of the key pair that is used to generate the transport certificate is used by the client software to encrypt an end entity's private encryption key before it is sent to the KRA for archival; only those clients capable of generating dual-key pairs use the transport certificate.

14.1.3.2. Storage Key Pair

Every KRA has a storage key pair. The KRA uses the public component of this key pair to encrypt (or wrap) private encryption keys when archiving the keys. It uses the private component to decrypt (or unwrap) the archived key during recovery. For more information on how this key pair is used, see Chapter 4, Setting up Key Archival and Recovery.
Keys encrypted with the storage key can be retrieved only by authorized key recovery agents.

14.1.3.3. TLS Server Certificate

Every Certificate System KRA has at least one TLS server certificate. The first TLS server certificate is generated when the KRA is configured. The default nickname for the certificate is Server-Cert cert-instance_ID, where instance_id identifies the KRA instance is installed.
The KRA's TLS server certificate was issued by the CA to which the certificate request was submitted, which can be a Certificate System CA or a third-party CA. To view the issuer name, open the certificate details in the System Keys and Certificates option in the KRA Console.
The KRA uses its TLS server certificate for server-side authentication to the KRA agent services interface. By default, the Key Recovery Authority uses a single TLS server certificate for authentication. However, additional TLS server certificates can be requested and installed for the KRA.

14.1.3.4. Subsystem Certificate

Every member of the security domain is issued a server certificate to use for communications among other domain members, which is separate from the server TLS certificate. This certificate is signed by the security domain CA.
The default nickname for the certificate is subsystemCert cert-instance_ID.

14.1.3.5. Audit Log Signing Key Pair and Certificate

The KRA keeps a secure audit log of all events which occurred on the server. To guarantee that the audit log has not been tampered with, the log file is signed by a special log signing certificate.
The audit log signing certificate is issued when the server is first configured.

Note

While other certificates can use ECC keys, the audit signing certificate must always use an RSA key.

14.1.4. TKS Certificates

The TKS has three certificates. The TLS server and subsystem certificates are used for standard operations. An additional signing certificate is used to protect audit logs.

14.1.4.1. TLS Server Certificate

Every Certificate System TKS has at least one TLS server certificate. The first TLS server certificate is generated when the TKS is configured. The default nickname for the certificate is Server-Cert cert-instance_ID.

14.1.4.2. Subsystem Certificate

Every member of the security domain is issued a server certificate to use for communications among other domain members, which is separate from the server TLS certificate. This certificate is signed by the security domain CA.
The default nickname for the certificate is subsystemCert cert-instance_ID.

14.1.4.3. Audit Log Signing Key Pair and Certificate

The TKS keeps a secure audit log of all events which occurred on the server. To guarantee that the audit log has not been tampered with, the log file is signed by a special log signing certificate.
The audit log signing certificate is issued when the server is first configured.

Note

While other certificates can use ECC keys, the audit signing certificate must always use an RSA key.

14.1.5. TPS Certificates

The TPS only uses three certificates: a server certificate, subsystem certificate, and audit log signing certificate.

14.1.5.1. TLS Server Certificate

Every Certificate System TPS has at least one TLS server certificate. The first TLS server certificate is generated when the TPS is configured. The default nickname for the certificate is Server-Cert cert-instance_ID.

14.1.5.2. Subsystem Certificate

Every member of the security domain is issued a server certificate to use for communications among other domain members, which is separate from the server TLS certificate. This certificate is signed by the security domain CA.
The default nickname for the certificate is subsystemCert cert-instance_ID.

14.1.5.3. Audit Log Signing Key Pair and Certificate

The TPS keeps a secure audit log of all events which occurred on the server. To guarantee that the audit log has not been tampered with, the log file is signed by a special log signing certificate.
The audit log signing certificate is issued when the server is first configured.

14.1.6. About Subsystem Certificate Key Types

When you create a new instance, you can specify the key type and key size in the configuration file passed to the pkispawn utility.

Example 14.1. Key Type-related Configuration Parameters for a CA

The following are key type-related parameters including example values. You can set these parameters in the configuration file which you pass to pkispawn when creating a new CA.
pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=2048
pki_ocsp_signing_key_type=rsa

pki_ca_signing_key_algorithm=SHA256withRSA
pki_ca_signing_key_size=2048
pki_ca_signing_key_type=rsa

pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_key_size=2048
pki_sslserver_key_type=rsa

pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_key_size=2048
pki_subsystem_key_type=rsa

pki_admin_keysize=2048
pki_admin_key_size=2048
pki_admin_key_type=rsa

pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=2048
pki_audit_signing_key_type=rsa

Note

The values in the example are for a CA. Other subsystems require different parameters.
For further details, see:
  • The Understanding the pkispawn Utility section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition).
  • The pki_default.cfg(5) man page for descriptions of the parameters and examples.

14.1.7. Using an HSM to Store Subsystem Certificates

By default, keys and certificates are stored in locally-managed databases, key3.db and cert8.db, respectively, in the /var/lib/pki/instance_name/alias/ directory. However, Red Hat Certificate System also supports hardware security modules (HSM), external devices which can store keys and certificates in a centralized place on the network. Using an HSM can make some functions, like cloning, easier because the keys and certificates for the instance are readily accessible.
When an HSM is used to store certificates, then the HSM name is prepended to the certificate nickname, and the full name is used in the subsystem configuration. For example:
serverCert="nethsm:Server-Cert cert-instance_ID

Note

A single HSM can be used to store certificates and keys for mulitple subsystem instances, which may be installed on multiple hosts. When an HSM is used, any certificate nickname for a subsystem must be unique for every subsystem instance managed on the HSM.
Certificate System supports two types of HSM, nCipher netHSM and Chrysalis LunaSA.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.