Code signing certificates are only valid for a few months. I can't remember if the new rules are 18 months or if its less. So any code that uses the Subject Key Identifier (_signer_key_id) will only be valid for that time period because the new certificate will have a new value.
Current WinGup and Notepad++ expect a certificate key id given in verifySignedFile.h. The _signer_key_id of the downloaded version of the installer can be from a new code signing certificate, so the WinGup code will not accept the new id when compared to what it expects, the old Subject Key Identifier.
See the attached log for the exact error message. Note that the expected id in the log is from the new key (6B058...), in my case, and the executable downloaded is an old version using a previous code signing certificate with id (B70EE...). So my attached example is opposite of what will happen in reality because a newer version of the program shouldn't ever see an older version of the installer. I am testing to make sure that I signed the XML properly, but the different code signing certificates (old vs new) will still be a problem when the current code signing certificate is replaced.
I think that the proper fix is to match the Name field (_signer_display_name) instead. I don't think that its possible to predict the new code signing certificates _signer_key_id.
securityError.log
This issue was originally created in the xmlSigner project but is applicable to this project.
Code signing certificates are only valid for a few months. I can't remember if the new rules are 18 months or if its less. So any code that uses the Subject Key Identifier (_signer_key_id) will only be valid for that time period because the new certificate will have a new value.
Current WinGup and Notepad++ expect a certificate key id given in verifySignedFile.h. The _signer_key_id of the downloaded version of the installer can be from a new code signing certificate, so the WinGup code will not accept the new id when compared to what it expects, the old Subject Key Identifier.
See the attached log for the exact error message. Note that the expected id in the log is from the new key (6B058...), in my case, and the executable downloaded is an old version using a previous code signing certificate with id (B70EE...). So my attached example is opposite of what will happen in reality because a newer version of the program shouldn't ever see an older version of the installer. I am testing to make sure that I signed the XML properly, but the different code signing certificates (old vs new) will still be a problem when the current code signing certificate is replaced.
I think that the proper fix is to match the Name field (_signer_display_name) instead. I don't think that its possible to predict the new code signing certificates _signer_key_id.
securityError.log
This issue was originally created in the xmlSigner project but is applicable to this project.