Sometimes it may be necessary to change the Signature algorithm to subsequently change an already installed certification authority hierarchy.
This is often the case because one has installed them with PKCS#1 version 2.1 and unfortunately finds out afterwards that not all applications are compatible with the resulting certificates, and thus cannot use the hierarchy.
While it is relatively easy to change the signature algorithm for certificates issued by a certification authority, it is more difficult to do so for certification authority certificates.
The following procedures can be used to subsequently modify the signature algorithm of the certification authority hierarchy:
| Method | Description |
|---|---|
| Reinstalling the certificate authority hierarchy. | This is the "safest" of all options, since it guarantees that no legacy data is created, but it is also the one that requires the most effort. In addition, new key pairs must be generated. |
| Changeover of the signature algorithm on all certification authorities and renewal of all certificates. | In this case, all certificates must be renewed, starting from the root Certification Authority. |
| Changeover of the signature algorithm on all certification authorities and re-signing of existing certificates | In this case, no renewal of the certification authority certificates is performed, but the current certificates are simply given a new signature |
Details: Changeover of the signature algorithm on all certification authorities and re-signing of the existing certificates.
The following procedure is very complex and can lead to the certification authority hierarchy becoming unusable if used incorrectly. For this reason, preference should be given to one of the two previously mentioned methods, if this is possible.
The following steps must be repeated for all Certification Authorities in the hierarchy, starting with the root Certification Authority.
In the following example, the signature algorithm of a certificate authority hierarchy is changed from PKCS#1 version 2.1 to PKCS#1 version 1.5. However, the process also works in the other direction if the commands used are adjusted accordingly.
The procedure is divided into the following substeps:
- Create a backup of the certification authority.
- Exit the certification authority service.
- Changing the signature algorithm in the registry.
- Changing the signature algorithm in capolicy.inf.
- Export the previous certification authority certificate to a file.
- Re-sign the certificate authority certificate using the desired signature algorithm.
- Replacing the certificate authority certificate with the newly signed version.
- Reestablish the connection between the certificate authority certificate and the private key.
- Adjust the certificate authority configuration to use the newly signed certificate authority certificate.
- Starting the certification authority service.
- Issuing a new certificate revocation list.
- Update revocation list distribution points and access to job information.
- Ensure the distribution of the new root certification authority certificate.
Creating a backup of the certification authority
Before making any changes to the certification authority, a backup of the current state should be made in any case. The procedure for creating a backup of the certification authority is described in the article "Create a backup of a certification authority" described.
Exiting the certification authority service
To be able to make the change, the certification authority service must be terminated. This can be done with the following command line command:
net stop certsvc
Changing the signature algorithm in the registry
The following command line command changes the signature algorithm for certificates issued by the certification authority to PKCS#1 version 1.5:
certutil -delreg CA\CSP\AlternateSignatureAlgorithm
Changing the signature algorithm in capolicy.inf
During the installation of a certification authority, the signature algorithm is usually configured via the configuration file in the Windows directory. This file should be adapted in any case. For root certification authorities, this directive is also used for renewing their own certification authority certificate, so failure to adjust it will lead to consequential errors.
The capolicy.inf is located in the Windows directory (usually C:\Windows).
The value "AlternateSignatureAlgorithm=1" must be changed to "AlternateSignatureAlgorithm=0".
Export the previous certification authority certificate to a file
Next, the current certification authority certificate must be re-signed. For this purpose, it must be available as a file. It is therefore exported from the local certificate store. This is done via the management console for certificates in the computer certificate store (certlm.msc).
The certificate is exported using the "All Tasks" - "Export" option in the context menu.
The private key is not needed at this point, so it does not need to be exported with it.
The file format used is ultimately not decisive. The default preselection can be kept.
The certificate should now be exported to a location from which it can be used for re-signing.
Re-signing the certification authority certificate using the desired signature algorithm
The certificate is now re-signed using the associated SIgnature key.
| Certificate | associated signature certificate |
|---|---|
| Master Certification Authority | The own Certification Authority certificate |
| Subordinate Certification Authority | The Certification Authority certificate of the respective higher-level Certification Authority |
To change from PKCS#1 version 2.1 to PKCS#1 version 1.5, the following command line command is used:
certutil -sign {certificate-old} {certificate-new} -AlternateSignatureAlgorithm
To change from PKCS#1 version 1.5 to PKCS#1 version 2.1, the following command line command is used:
certutil -sign {Certificate-Old} {Certificate-New} +AlternateSignatureAlgorithm
You will be prompted to select the signature certificate.
If the correct signing certificate was used, success is displayed accordingly.
Comparing the old certificate with the new one, you should notice that the serial number of both certificates is identical, but the signature algorithm differs as indicated.
Replacing the certification authority certificate with the newly signed version
Now the previous certificate authority certificate is deleted from the certificate store and replaced with the new certificate.
The private key of the certificate is preserved during deletion, there is no need to worry.
The management console for certificates in the computer certificate store (certlm.msc) is used to delete the certificate.
Then the new certificate authority certificate is imported into the same certificate store ("Local Computer" - "Personal" - "Certificates").
The default setting ("Personal") is applicable.
On a root certification authority, the certificate must also be exchanged in the same way in the "Trusted Root Certification Authorities" store.
Reestablish connection between certification authority certificate and private key
After importing the new certificate authority certificate, you notice that it supposedly does not have the private key.
The private key is still present, but not yet linked to the new certificate.
If a software key is used, it is sufficient to run the command with a user account that has local administrator privileges on the certificate authority. If a hardware security module (HSM) is used, it may be necessary to run the command in the context of the local SYSTEM account, which can be achieved with psexec or a scheduled task, for example.
The following command line command establishes the connection between the new certificate and the existing private key:
certutil -repairstore My {Thumbprint-new-certificate}
After that, the private key should be displayed.
Customize the certificate authority configuration to use the newly signed certificate authority certificate
Now that the new certificate authority certificate has been successfully imported and reconnected to the private key, the certificate authority must be informed of the change. This is done by editing the CACertHash value located in the following registry path:
HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\{Common-name-of-certification authority}
The thumbprint of the previous certification authority certificate is replaced with that of the newly signed one. Please note that the spaces are retained.
If the certification authority service does not start now, see article "The certificate authority service does not start and throws the error message "The parameter is incorrect. 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER)„.
Starting the Certification Authority Service
Now the certificate authority service can be started. For example, with the following command line command:
net start certsvc
Rework
The following finishing work still needs to be done:
- Issuing a new certificate revocation list. See article "Create and publish a certificate revocation list„.
- Update the revocation list distribution points and access to job information. The new certification authority certificate and the newly created revocation list must be copied to their publishing locations. They replace the existing files in this process.
- Ensure the distribution of the new root certification authority certificate. The new root certification authority certificate must be made known to the subscribers and the trust status must be established. The root certification authority certificate can be distributed via the Public Key Services container in Active Directory or via group policies. It replaces the previously published root certification authority certificate.
English 
Deutsch
One thought on “Den Signaturalgorithmus einer Zertifizierungsstellen-Hierarchie ändern, ohne neue Zertifizierungsstellen-Zertifikate auszustellen”
Comments are closed.