New EV code signing certificate stored in Azure Key Vault triggers windows smart screen warning on signed executables

Question

We have used a GlobalSign issued EV code signing certificate since 2021 and it is due to expire at the end of August 2024.

We use this certificate to sign our installer executables as part of our build system, the signing process uses the azuresigntool application (version 2.0.17) which used a shared secret to access an azure signing application with a shared secret that provides access to our key vault held code signing certificate.

To date the process works, we have signed executables that do not trigger the windows smart screen warning when executed.

Due to changes in our company staff assignments it was decided that, rather than renew the existing certificate, we should generate a new one with an updated contact email address.

We have gone through the vetting and issuance procedure with GlobalSign and have successfully imported the new certificate into our Key Vault so we have our old EV signing certificate that expires shortly and our new certificate that is valid for the next 3 years.

The problem we have is that if we use our new certificate to sign our executables the windows smart screen warning is displayed stating that the executable is untrusted for example:

I have been in communication with GlobalSign support and it was suggested we should try to import the certificate chain into our key vault. When the certificate was issued we received the signing certificate, an intermediate certificate and a root certificate.

I had to do a bit of research but managed to create a .p7b file (using openssl) containing the 3 certificates, this was initially rejected by the azure merge operation but from an article I found (on this forum I think) I modified the .p7b file header and footer to specify 'CERTIFICATE' instead of 'PKCS7' and the merge operation was successful (although there is no indication that the root/intermediate certificates were accepted into the vault).

Having done this I have attempted to use the new code signing certificate from our build process but it continues to trigger the windows warning message.

I have compared executable files signed with the old and new code signing certificates and their chains appear to be identical for example:

I have compared the details of each of the GlobalSign certificates in the chain and they have the same serial numbers and thumbprints and appear to be identical so from this I conclude that the failure to achieve the required level of trust to satisfy windows cannot be down to the intermediate certificates not being trusted.

Our old and new certificates have different subject names that include differences in email address (E) and state (S) properties but are identical apart from that (so they have the same CN attribute name as you can see above both certificates have the same title).

Could having the same CN attribute in both versions of the signing certificate be causing trust issues here?

Any insight into how the trust is accumulated may help, presumably it is part of the signature such that no network lookup would be required by windows to check its trust status?

Would installing the code signing certificate on the build machine that calls the azuresigntool help (this was not necessary for the old signing certificate)?

Our azure signing application that grants access to our key vault uses a shared secret, the current secret is valid until the end of the year, given that I have added a new certificate to the vault would we need to update the shared secret? I would have assumed the azsuresigntool process would have failed if this was the issue.

The version of azuresigntool is a little old, do you know of any issues with this version that could be causing issues with the new code sign certificate? - from the build logs the process appears to behave in exactly the same way for both old and new signing certificates.

Any help/suggestions would be very welcome.

Many thanks!

Answer 1

It seems the Program Requirements - Microsoft Trusted Root Program confirms the claim that EV code signing will no longer instantly remove SmartScreen warnings (i.e. no longer immediately have sufficient reputation to remove such warnings). Section 3, subsection D, part 3 states:

"Beginning in August 2024, all EV Code Signing OIDs will be removed from existing roots in the Microsoft Trusted Root Program, and all Code Signing certificates will be treated equally."

However, I heard from a 3rd party CA (support chat) that this hasn't actually been implemented yet and the actual effective date remains unknown. For this reason, EV certificates are still being sold.

Question: Does anyone have further insight on this matter? Ex. if / when this will actually take effect.

Note: this thread also addresses this matter (however note that the link in that thread is broken).