Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual page 76

Chapter 5. Planning the Certificate System
Subsystem
DRM
TKS
TPS
Table 5.1. Initial Subsystem Certificates
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
66