4.4. Determining the Requirements for Subsystem Certificates

The CA configuration determines many of the characteristics of the certificates which it issues, regardless of the actual type of certificate being issued. Constraints on the CA's own validity period, distinguished name, and allowed encryption algorithms impact the same characteristics in their issued certificates. Additionally, the Certificate Managers have predefined profiles that set rules for different kinds of certificates that they issue, and additional profiles can be added or modified. These profile configurations also impact issued certificates.

4.4.1. Determining Which Certificates to Install

When a Certificate System subsystem is first installed and configured, the certificates necessary to access and administer it are automatically created. These include an agent's certificate, server certificate, and subsystem-specific certificates. These initial certificates are shown in Table 4.1, “Initial Subsystem Certificates”.

Table 4.1. Initial Subsystem Certificates

Subsystem Certificates
Certificate Manager
  • CA signing certificate
  • OCSP signing certificate
  • SSL server certificate
  • Subsystem certificate
  • User's (agent/administrator) certificate
  • Audit log signing certificate
RA
  • SSL server certificate
  • User's (agent/administrator) certificate
OCSP
  • OCSP signing certificate
  • SSL server certificate
  • Subsystem certificate
  • User's (agent/administrator) certificate
  • Audit log signing certificate
DRM
  • Transport certificate
  • Storage certificate
  • SSL server certificate
  • Subsystem certificate
  • User's (agent/administrator) certificate
  • Audit log signing certificate
TKS
  • SSL server certificate
  • User's (agent/administrator) certificate
  • Audit log signing certificate
TPS
  • SSL server certificate
  • User's (agent/administrator) certificate
  • Audit log signing certificate

There are some cautionary considerations about replacing existing subsystem certificates.
  • Generating new key pairs when creating a new self-signed CA certificate for a root CA will invalidate all certificates issued under the previous CA certificate.
    This means none of the certificates issued or signed by the CA using its old key will work; subordinate Certificate Managers, DRMs, OCSPs, TKSs, and TPSs will no longer function, and agents can no longer to access agent interfaces.
    This same situation occurs if a subordinate CA's CA certificate is replaced by one with a new key pair; all certificates issued by that CA are invalidated and will no longer work.
    Instead of creating new certificates from new key pairs, consider renewing the existing CA signing certificate.
  • If the CA is configured to publish to the OCSP and it has a new CA signing certificate or a new CRL signing certificate, the CA must be identified again to the OCSP.
  • If a new transport certificate is created for the DRM, the DRM information must be updated in the CA's configuration file, CS.cfg. The existing transport certificate must be replaced with the new one in the ca.connector.KRA.transportCert parameter.
  • If a CA is cloned, then when creating a new SSL server certificate for the master Certificate Manager, the clone CAs' certificate databases all need updated with the new SSL server certificate.
  • If the Certificate Manager is configured to publish certificates and CRLs to an LDAP directory and uses the SSL server certificate for SSL client authentication, then the new SSL server certificate must be requested with the appropriate extensions. After installing the certificate, the publishing directory must be configured to use the new server certificate.
  • Any number of SSL server certificates can be issued for a subsystem instance, but it really only needs one SSL certificate. This certificate can be renewed or replaced as many times as necessary.