Chapter 17. Managing Subsystem Certificates
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.
17.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 Red Hat Certificate System Planning, Installation, and Deployment Guide.
17.1.1. Certificate Manager Certificates
When a Certificate Manager is installed, the keys and requests for the CA signing certificate, SSL 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.
17.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.
17.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.
17.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 SSL 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.
17.1.1.4. SSL Server Key Pair and Certificate
Every Certificate Manager has at least one SSL 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 SSL 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 SSL-enabled communication with a publishing directory, it uses its SSL server certificate for client authentication to the publishing directory by default. The Certificate Manager can also be configured to use a different certificate for SSL client authentication.
17.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.
17.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, SSL 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.
17.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.
17.1.2.2. SSL Server Key Pair and Certificate
Every Online Certificate Status Manager has at least one SSL 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.
17.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 SSL certificate. This certificate is signed by the security domain CA.
The default nickname for the certificate is
subsystemCert cert-instance_ID.
17.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.
17.1.2.5. Recognizing Online Certificate Status Manager Certificates
Depending on the CA which signed the Online Certificate Status Manager's SSL 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 SSL 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.
17.1.3. Key Recovery Authority Certificates
17.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.
17.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.
17.1.3.3. SSL Server Certificate
Every Certificate System KRA has at least one SSL server certificate. The first SSL 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 SSL 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 SSL server certificate for server-side authentication to the KRA agent services interface. By default, the Key Recovery Authority uses a single SSL server certificate for authentication. However, additional SSL server certificates can be requested and installed for the KRA.
17.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 SSL certificate. This certificate is signed by the security domain CA.
The default nickname for the certificate is
subsystemCert cert-instance_ID.
17.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.
17.1.4. TKS Certificates
The TKS has three certificates. The SSL server and subsystem certificates are used for standard operations. An additional signing certificate is used to protect audit logs.
17.1.4.1. SSL Server Certificate
Every Certificate System TKS has at least one SSL server certificate. The first SSL server certificate is generated when the TKS is configured. The default nickname for the certificate is
Server-Cert cert-instance_ID.
17.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 SSL certificate. This certificate is signed by the security domain CA.
The default nickname for the certificate is
subsystemCert cert-instance_ID.
17.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.
17.1.5. TPS Certificates
The TPS only uses three certificates: a server certificate, subsystem certificate, and audit log signing certificate.
17.1.5.1. SSL Server Certificate
Every Certificate System TPS has at least one SSL server certificate. The first SSL server certificate is generated when the TPS is configured. The default nickname for the certificate is
Server-Cert cert-instance_ID.
17.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 SSL certificate. This certificate is signed by the security domain CA.
The default nickname for the certificate is
subsystemCert cert-instance_ID.
17.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.
17.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 17.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
pkispawnUtility section in the Red Hat Certificate System Planning, Installation, and Deployment Guide. - The pki_default.cfg(5) man page for descriptions of the parameters and examples.
17.1.7. Using an HSM to Store Subsystem Certificates
By default, keys and certificates are stored in locally-managed databases,
key4.db and cert9.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, such as the
server.xml file. 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.
