16.4. Changing the Names of Subsystem Certificates
One alternative to renewing certificates is replacing them with new certificates, meaning that a new certificate is generated with new keys. Generally, a new certificate can be added to the database and the old one deleted, a simple one-to-one swap. This is possible because the individual subsystem servers identify certificates based on their nickname; as long as the certificate nickname remains the same, the server can find the required certificate even if other factors — like the subject name, serial number, or key — are different.
However, in some situations, the new certificate may have a new certificate nickname, as well. In that case, the certificate nickname needs to be updated in all of the required settings in the subsystem's
CS.cfg
configuration file.
Important
Always restart a subsystem after editing the
CS.cfg
file.
These tables list all of the configuration parameters for each of the subsystem's certificates:
Table 16.3. CA Certificate Nickname Parameters
CA Signing Certificate |
|
OCSP Signing Certificate |
|
Subsystem Certificate |
|
Server Certificate |
|
Audit Signing Certificate |
|
Table 16.4. KRA Certificate Nickname Parameters
Transport Certificate |
|
Storage Certificate |
|
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|
Table 16.5. OCSP Certificate Nickname Parameters
OCSP Signing Certificate |
|
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|
Table 16.6. TKS Certificate Nickname Parameters
KRA Transport Certificate[a] |
|
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|
[a]
This needs changed in the TKS configuration if the KRA transport certificate nickname changes, even if the TKS certificates all stay the same.
|
Table 16.7. TPS Nickname Parameters in CS.cfg
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|