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:
CA Signing Certificate |
|
OCSP Signing Certificate |
|
Subsystem Certificate |
|
Server Certificate |
|
Audit Signing Certificate |
|
Transport Certificate |
|
Storage Certificate |
|
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|
OCSP Signing Certificate |
|
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|
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.
|
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|