Re-signing a certificate from a different CA with certutil
The certutil -sign verb allows, according to the documentation, to re-sign a certificate, but I was wondering whether "re-sign" includes signing a certificate that has previously been signed by another Certification Authority.
The use case I had in mind was accepting self-signed certificates as a form of certificate signing requests. There are a number of software products out there that, out of the box, provide the ability to generate a self-signed certificate to be used for testing or for the initial setup before a certificate signed by a CA is configured. So I wanted to test whether those self-signed certificates (assuming they are securely generated during installation and not simply included with the software) could be used as a request to a CA.
The idea would then be to get a self-signed certificate and try to sign it with an AD CS Certification Authority using certutil -sign. For testing purposes I exported one of the trusted Root CAs in the system (a self-signed certificate) and tried to run:
certutil -sign RootCA.cer RootCAReSign.cer now+1:00
But what I got is:
"No certificate available" - "No certificates meet the application criteria"
I then tried to re-sign a certificate previously signed by that same CA, to make sure the CA and the command were correct, and it worked. So it looks like the "re-sign" capability in certutil -sign really refers to signing again by the same CA.
Not clear what the application criteria for certificate matching is, though. I have tested two different scenarios:
- With a CA where the CA certificate was renewed after expiration using the same DN for the CA and a new private key, and the certutil command would only show me as option the CA that originally signed the certificate
- With a CA where the CA certificate was renewed after expiration using the same DN for the CA and the same private key, and the certutil command allows me to sign with either CA and even if I choose the expired CA certificate the output (re-signed certificate) is not constrained by that expiration.
The above makes me think that certificate matching is performed based on the Issuer DN (since that will remain the same in the new re-signed certificate) and the Authority Key Identifier.
The use case I had in mind was accepting self-signed certificates as a form of certificate signing requests. There are a number of software products out there that, out of the box, provide the ability to generate a self-signed certificate to be used for testing or for the initial setup before a certificate signed by a CA is configured. So I wanted to test whether those self-signed certificates (assuming they are securely generated during installation and not simply included with the software) could be used as a request to a CA.
The idea would then be to get a self-signed certificate and try to sign it with an AD CS Certification Authority using certutil -sign. For testing purposes I exported one of the trusted Root CAs in the system (a self-signed certificate) and tried to run:
certutil -sign RootCA.cer RootCAReSign.cer now+1:00
But what I got is:
"No certificate available" - "No certificates meet the application criteria"
I then tried to re-sign a certificate previously signed by that same CA, to make sure the CA and the command were correct, and it worked. So it looks like the "re-sign" capability in certutil -sign really refers to signing again by the same CA.
Not clear what the application criteria for certificate matching is, though. I have tested two different scenarios:
- With a CA where the CA certificate was renewed after expiration using the same DN for the CA and a new private key, and the certutil command would only show me as option the CA that originally signed the certificate
- With a CA where the CA certificate was renewed after expiration using the same DN for the CA and the same private key, and the certutil command allows me to sign with either CA and even if I choose the expired CA certificate the output (re-signed certificate) is not constrained by that expiration.
The above makes me think that certificate matching is performed based on the Issuer DN (since that will remain the same in the new re-signed certificate) and the Authority Key Identifier.
Comments
Post a Comment