Ce contenu n'est pas disponible dans la langue sélectionnée.
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 |
|