• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

Authenticode fails for GPU-Z 2.63.0

rtfmoz

New Member
Joined
Feb 24, 2025
Messages
16 (0.21/day)
Issue: Microsoft Authenticode fails for GPU-Z.2.63.0.exe

Testing:
Note: OpenSSL reports certificates are fine however Authenticode fails

1. Download the installer for the Windows SDK from Windows SDK - Windows app development | Microsoft Developer.
2. Run the setup and only choose the signing tools during installation as that's all you need.
3. Create a txt file with the name "verify" and add the following two lines (the second line is the name of the installer)
verify
GPU-Z.2.63.0.exe
3. Run signtool @verify to validate your installer
4. To list all the certificates being checked update the file
verify /debug
GPU-Z.2.63.0.exe

Results
Code:
C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64>signtool @verifygpuz
File: GPU-Z.2.63.0.exe
Index  Algorithm  Timestamp
========================================
SignTool Error: A certificate chain processed, but terminated in a root
        certificate which is not trusted by the trust provider.

Number of errors: 1

C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64>

This is required to open the software on Windows 11 24H2 or later

Windows Defender's Smart App protection blocks you from opening the file. There is no exclusion list and you cannot turn off the feature without disabling it permanently (system reinstall).

Further diagnosis lists the root certificates in the chain. The Digicert Trusted Root G4 signature does not match the one on the Microsoft Root Certificates list for Windows. Please resign your software with updated certificates so its Authenticode compliant.

Results (debug)

Code:
C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64>signtool @verifygpuz

Verifying: GPU-Z.2.63.0.exe

Signature Index: 0 (Primary Signature)
Hash of file (sha1): 4F8EC31F2D328163DCAC4E5E9DA54B6D21D0441D
Signing Certificate Chain:
    Issued to: SSL.com EV Root Certification Authority RSA R2
    Issued by: SSL.com EV Root Certification Authority RSA R2
    Expires:   Sat May 31 05:14:37 2042
    SHA1 hash: 743AF0529BD032A0F44A83CDD4BAA97B7C2EC49A

        Issued to: SSL.com EV Code Signing Intermediate CA RSA R3
        Issued by: SSL.com EV Root Certification Authority RSA R2
        Expires:   Thu Mar 23 04:44:23 2034
        SHA1 hash: D2953DBA95086FEB5805BEFC41283CA64C397DF5

            Issued to: TechPowerUp LLC
            Issued by: SSL.com EV Code Signing Intermediate CA RSA R3
            Expires:   Tue Apr 15 07:06:58 2025
            SHA1 hash: 8DAAE716F69B30A0DDC8C8A3F8EAC6C5B328CFD2

The signature is timestamped: Fri Feb 21 23:04:27 2025
Timestamp Verified by:
    Issued to: DigiCert Assured ID Root CA
    Issued by: DigiCert Assured ID Root CA
    Expires:   Mon Nov 10 11:00:00 2031
    SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43

        Issued to: DigiCert Trusted Root G4
        Issued by: DigiCert Assured ID Root CA
        Expires:   Mon Nov 10 10:59:59 2031
        SHA1 hash: A99D5B79E9F1CDA59CDAB6373169D5353F5874C6 <<< THIS IS THE ISSUE >>>

            Issued to: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
            Issued by: DigiCert Trusted Root G4
            Expires:   Mon Mar 23 10:59:59 2037
            SHA1 hash: B6C8AF834D4E53B673C76872AA8C950C7C54DF5F

                Issued to: DigiCert Timestamp 2024
                Issued by: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
                Expires:   Mon Nov 26 10:59:59 2035
                SHA1 hash: DBD385EE62DBD23E7BE4F67148508724D5865B45

SignTool Error: A certificate chain processed, but terminated in a root
certificate which is not trusted by the trust provider.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1
 
Last edited:
Last edited:
Like I said above the certificates validate fine, Authenticode does not. Under App & Browser control in Windows Security you will find Smart App control.

1740393448726.png
1740393558525.png
1740393600044.png


You need to be the latest version of Windows 11 24H2. Smart App control, part of Windows Defender Endpoint software is free to Office 365 subscribers. Lookup Defender for Individuals to install.
 
Last edited:
Please resign your software with updated certificates so it passes Windows Authenticode compliance as shown by Windows verification tool signtool.

The following certificate needs to be updated or removed from the certificate chains. It does not exist on the Microsoft Root Certificates list for Windows.
The one that does exit for this common name has a different SHA1 hash.

Issued to: DigiCert Trusted Root G4
Issued by: DigiCert Assured ID Root CA
Expires: Mon Nov 10 10:59:59 2031
SHA1 hash: A99D5B79E9F1CDA59CDAB6373169D5353F5874C6
 
Hmm the problem seems to be the timestamp, not the actual signature itself

Wow, very user-friendly

edit: Nope .. can't get it to work .. used a differnt timestamp server, same problem. File is attached


Edit: seems they fixed it on their side. My test VM is suddenly able to open the exe without problems after having it connected to the internet for a while

 

Attachments

Last edited:
Hmm the problem seems to be the timestamp, not the actual signature itself

Edit: seems they fixed it on their side. My test VM is suddenly able to open the exe without problems after having it connected to the internet for a while
Brilliant! Let me check this now.

Edit: Woohoo its fixed! Maybe my post on Linked-In was noticed. At least its working now, I can finally validate the ROPs on my new 5070Ti
 
Last edited:
It's happening again now for 2.64.0 as well. Are you able to find out where the timestamp certificate chain is coming from?
 
Could this just be a case of them manually whitelisting releases after x amount of complaints? Because thats what it feels like.
 
It's happening again now for 2.64.0 as well. Are you able to find out where the timestamp certificate chain is coming from?

GPU-Z 2.64.0 opens and runs on Windows 10 22H2 for me. I noticed the certificate's expiry date is approaching and will lapse in 45 days, though any cert related issues technically shouldn't manifest until then? Do you have any stricter rules regarding expiry dates set, if that's a thing? It's been so long I did anything related to signing I don't remember anymore.

1740717609741.png
 
and will lapse in 45 days
This date is relevant only for the process of signing, i.e. after that date you can't sign new binaries, but existing ones remain signed

It's happening again now for 2.64.0 as well. Are you able to find out where the timestamp certificate chain is coming from?
As mentioned before, I tried signing with Globalsign's timestamp server and it still wouldn't accept the file. I don't think the timestamp server is the problem
 
I tested it using the same authenticode validation process as before.

Code:
C:\Users\jarvi\Downloads>signtool.exe verify /debug GPU-Z.2.64.0.exe

Verifying: GPU-Z.2.64.0.exe

Signature Index: 0 (Primary Signature)
Hash of file (sha1): 69B15211066A332B38F02AA668EDB8358A41A478

Signing Certificate Chain:
    Issued to: SSL.com EV Root Certification Authority RSA R2
    Issued by: SSL.com EV Root Certification Authority RSA R2
    Expires:   Sat May 31 05:14:37 2042
    SHA1 hash: 743AF0529BD032A0F44A83CDD4BAA97B7C2EC49A

        Issued to: SSL.com EV Code Signing Intermediate CA RSA R3
        Issued by: SSL.com EV Root Certification Authority RSA R2
        Expires:   Thu Mar 23 04:44:23 2034
        SHA1 hash: D2953DBA95086FEB5805BEFC41283CA64C397DF5

            Issued to: TechPowerUp LLC
            Issued by: SSL.com EV Code Signing Intermediate CA RSA R3
            Expires:   Tue Apr 15 07:06:58 2025
            SHA1 hash: 8DAAE716F69B30A0DDC8C8A3F8EAC6C5B328CFD2

The signature is timestamped: Wed Feb 26 23:05:34 2025
Timestamp Verified by:
    Issued to: DigiCert Assured ID Root CA
    Issued by: DigiCert Assured ID Root CA
    Expires:   Mon Nov 10 11:00:00 2031
    SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43

        Issued to: DigiCert Trusted Root G4
        Issued by: DigiCert Assured ID Root CA
        Expires:   Mon Nov 10 10:59:59 2031
        SHA1 hash: A99D5B79E9F1CDA59CDAB6373169D5353F5874C6

            Issued to: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
            Issued by: DigiCert Trusted Root G4
            Expires:   Mon Mar 23 10:59:59 2037
            SHA1 hash: B6C8AF834D4E53B673C76872AA8C950C7C54DF5F

                Issued to: DigiCert Timestamp 2024
                Issued by: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
                Expires:   Mon Nov 26 10:59:59 2035
                SHA1 hash: DBD385EE62DBD23E7BE4F67148508724D5865B45

SignTool Error: A certificate chain processed, but terminated in a root
        certificate which is not trusted by the trust provider.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1

Like before the DigiCert Trusted Root G4 signature does not match the one for that server on the Microsoft Approved Roots List.

Issued to: DigiCert Trusted Root G4
Issued by: DigiCert Assured ID Root CA
Expires: Mon Nov 10 10:59:59 2031
SHA1 hash: A99D5B79E9F1CDA59CDAB6373169D5353F5874C6

GPU-Z 2.64.0 opens and runs on Windows 10 22H2 for me. I noticed the certificate's expiry date is approaching and will lapse in 45 days, though any cert related issues technically shouldn't manifest until then? Do you have any stricter rules regarding expiry dates set, if that's a thing? It's been so long I did anything related to signing I don't remember anymore.

View attachment 387106
This has no bearing on the Authenticode issue. The cert has to be valid but so do all root signatures involved in that validation and that is where the problem lies. I don't know what your signing process is but signtool command will sign them for you if that is of any help. See the instructions from SSL.com https://www.ssl.com/how-to/using-your-code-signing-certificate/

Well aren't I a flippin genius... SSL.COM says you should use /pa on the signtool verify and I was not. If I use /pa it passes!

/pa means Use the "Default Authenticode" Verification Policy.

Code:
C:\Users\jarvi\Downloads>signtool.exe verify /pa GPU-Z.2.64.0.exe
File: GPU-Z.2.64.0.exe
Index  Algorithm  Timestamp
========================================
0      sha1       Authenticode

Successfully verified: GPU-Z.2.64.0.exe

This however does not work with Microsoft SmartApp Control. Either they missed a setting or the security posture is stronger under SmartApp.
I will raise a new ticket with MS to find out what the status of this issue is.
 
Last edited:
Just turn smart app control off there ya go problem solved it's never worked right for apps not from the MS App store I've had it choke on a chode quite a few times with apps I've downloaded from trusted sites like TPU or Guru3D so I just turned it off problem solved
 
A few years ago I would have agreed with you but it is there for good reason. Its app security and in these days it is very effective at protecting endpoints. Authenticode is mature and signing certificates are available from every SSL provider. You cannot turn it off and on. If you turn it off you have to re-install windows to turn it back on. This is so it has a known operating system security state to begin with.


It is only available on new installs of Windows 11. It won't appear on any upgraded version. It locks down application execution to those signed by Authenticode. This means the code has known owner that is registered through the Microsoft Authenticode Framework. It's peace of mind for many people as unsigned code will not run on the system. It is just another line of defence using public key cryptography and proof of ownership.

I will raise a new ticket with MS to find out what the status of this issue is.

This has been done, lets see what the outcome is.

Edit: 11.34pm

Ok its fixed! 2.64.0 is now opening under Windows 11. Hooray! I was in the middle of submitting it over at hhttps://www.microsoft.com/en-us/wdsi/filesubmission and went back to check to find some details and now it opens under Windows 11 Pro.

1740745699872.png


1740745796012.png


Good news! Fantastic.
 
Last edited:
Ok its fixed! 2.64.0 is now opening under Windows 11. Hooray!
But WTF, are they manually approving each version after someone raises a ticket? I don't think such a mechanism is sustainable?
 
This i think is the problem i had initially, still doing it to me only works when turning off real time protection.

before:
1740749656862.png


after:
1740749584206.png
 
"driver marked for deletion" just needs a reboot, it has nothing to do with what's happening in this thread

gpu-z tries to share a single instance of its driver, but when you open and close them at different times, the driver will be marked as "for deletion" and won't accept new connections. when you reboot, the driver is stopped and uninstalled, like it should after gpuz shutdown and everything wil lwork normally
 
So just to wrap up, your software passes authenticode checks as per the instructions over at ssl.com. Shown below.

Code:
C:\Users\jarvi\Downloads>signtool.exe verify /pa GPU-Z.2.64.0.exe
File: GPU-Z.2.64.0.exe
Index  Algorithm  Timestamp
========================================
0      sha1       Authenticode

Successfully verified: GPU-Z.2.64.0.exe

It appears however that Microsoft's Smart App Control is rejecting it. I mistakenly attributed this to their endpoint software when it is actually a built-in feature of Windows 11 and available to newly installed machines. I am unable to determine why it is rejecting at this point in time. Heuristic cloud learning perhaps? You would have to ask Microsoft why this is happening. They may even roll out a fix for this as the problematic SSL certificate we identitifed cannot be only affecting just your software, assuming authenticode validation is the actual issue. It may well be something entirely different, it is Windows after all so without more information, we can only speculate.

If it happens again you can feedback to Microsoft using the feedback hub (requires Windows) or attempt to have your file is whitelisted.

Subject: Authenticode passes by Smart App does not

Details: GPU-Z from TechPowerUP is fully signed executable. Testing with Microsoft SDK signtool verify /pa it passes using the instructions from ssl.com. However it appears SmartApp does not accept this. It appears that it will only accept the binary as valid if signtool verify passes. The /pa option means use the "Default Authenticode" verification policy. The security posture under SmartApp Control is either rejecting the authenticode or something else is happening. Without the /pa option the authenticode fails because there is an invalid root in the timestamp server SSL chain.

Category: Security & Privacy > Smart App Control

Describe: Important Functionality Not Working

Good Luck!
 
Last edited:
You would have to ask Microsoft why this is happening.
Like I said MS couldn't give a hoot about it if it's not downloaded from the MS app store just turn that stupid MS App control off you don't need it and all it does is cause more problems than it solves
 
Like I said MS couldn't give a hoot about it if it's not downloaded from the MS app store just turn that stupid MS App control off you don't need it and all it does is cause more problems than it solves
This is simply not true. If their software is ineffective then it affects a lot of people and not just a few. I already stated the case for using the software.
 
Hi,

I was able to repro with theses steps, can someone validate this on their side?

1. From a Vanilla Windows 11 24H2 installation
2. Using Microsoft Edge, download the exe
3. Wait for the exe to be downloaded and click "open" from the browser notification
4. Notice that the exe is showing "Verify Publisher" UAC dialog
5. Select "no" to the dialog
6. Open a terminal and execute the following command.
certutil.exe --urlcache * delete
7. The output of the command, should finish with and error ERROR_NO_MORE_ITEMS, this is normal
8. Go where you downloaded the exe, and execute the program
9. Notice that the exe is now showing "Publisher: Unknown" UAC dialog
10. Try downloading the file again and the result will be "Publisher: Unknown"

This wasn't happening on 22H2 or 22H3.
 
certutil.exe --urlcache * delete
I would assume that Windows downloads the publisher info dynamically as needed, deleting the cache will result in the publisher being unknown, so I'd say this isn't unexpected? Or actually, shouldn't the expectation be that Windows tries to redownload the publisher info?
 
Back
Top