I have a SHA-1 Code Signing Certificate issued from GoDaddy which expires soon.
I've requested a renewal, and re-keyed it from my current machine using the auto-key -- everything works, except when I sign my .NET assemblies with it, they get a different public key token than before!
I noticed that when I re-key via supplying a .csr
-- as long as I re-supply the same .csr
every time, the public key token does not change.
I've created my new .csr
, and .key
files using the following command (and then filling in the fields as appropriate):
openssl req -out companyname.csr -new -newkey rsa:2048 -nodes -keyout companyname.key
(The old certificate was also created using the auto-browser method, but on a VM that's corrupt and can't be used any longer. My understanding is that the auto-browser method basically generates the .csr
and .key
file for you and it's machine specific.)
For the old key that's not yet expired, I have a .key
file that GoDaddy let me download, and a .pfx
file that I generated myself using command line tools (I converted the key to a .pvk
at one point, and merged that with the .spc
file, etc.), and I know what values the CSR fields must have (as far as C, CN, O, etc.).
My Question:
Is there any way to derive what the old .csr
file must have been (or a compatible / equivalent .csr
file) from this data, such that I can re-key my certificate back to one that generates the same public key token as before?
Figured it out, looks like you can generate a new .csr
file from the existing .key
file pretty easily. Then re-keying the certificate from this .csr
allows you the generate a .pfx
that will let you strong name assemblies with the same public key token that you had before. Awesome.
The command to do it is:
openssl req -out companyname.csr -new -key companyname.key
It's that easy!