Code Signing Error

Hi,
Using 2025.1, I have a problem signing the exe, GsignCode.exe just flickers and disappears immediately.
Works on a second computer, can you indicate why code sign might fail? Worked on the computer that now fails for months. Tried removing and reinstalling padlock many times, added app to Firewall, still no success.
Thank you
 
Here is what the log says ([...]=edited):
[10/15/2025 8:46:29 PM] Signing [...].exe
[10/15/2025 8:46:29 PM] SIGNING ERROR:
[10/15/2025 8:46:29 PM] An error occurred while attempting to load the certificate. Invalid provider type specified.
[10/15/2025 8:46:29 PM]
[10/15/2025 8:46:29 PM] Warning: code signing failed, an error occurred.
[10/15/2025 8:46:29 PM] Retrying code signing in some seconds.
[10/15/2025 8:46:32 PM] GSignCode 3.1 -- simple code signing utility
[10/15/2025 8:46:32 PM] Copyright G.D.G. Software 2011-2025. All rights reserved.
[10/15/2025 8:46:32 PM]
[10/15/2025 8:46:32 PM] Certificate Subject Name: CN=[...], O=[...], S=[...], C=[...], OID.2.5.4.15=Private Organization, OID.1.3.6.1.4.1.311.60.2.1.2=[...], OID.1.3.6.1.4.1.311.60.2.1.3=[...], SERIALNUMBER=[...]
[10/15/2025 8:46:32 PM] Issuer: CN=Sectigo Public Code Signing CA EV R36, O=Sectigo Limited, C=GB
[10/15/2025 8:46:32 PM] Serial Number: [...]
[10/15/2025 8:46:32 PM]
[10/15/2025 8:46:32 PM] Signing [...].exe
[10/15/2025 8:46:32 PM] SIGNING ERROR:
[10/15/2025 8:46:32 PM] An error occurred while attempting to load the certificate. Invalid provider type specified.
[10/15/2025 8:46:32 PM]
[10/15/2025 8:46:32 PM] Warning: code signing failed, an error occurred.
 
I don't see anything relevant for me at least in the logs. Probably it is more relevant to you, can you find a reason why it does not sign properly?
We always used Certificate Thumbprint option
 
That error usually means the certificate’s private key provider doesn’t match what the signing tool expects. In Windows there are two families:
  • CSP (legacy “CryptoAPI” providers) like “Microsoft Enhanced RSA and AES Cryptographic Provider” or vendor CSPs (e.g., eToken Base Cryptographic Provider).
  • KSP/CNG (newer providers) like “Microsoft Software Key Storage Provider” or “SafeNet Key Storage Provider”.
Please check what provider your cert uses
Open an elevated Command Prompt and run:
certutil -store my
(or certutil -user -store my if it’s in Current User). Look at “Provider”:
If it says Microsoft Software Key Storage Provider → it’s KSP/CNG.
If it says Microsoft Enhanced RSA and AES Cryptographic Provider (Type 24) or a vendor CSP name → it’s CSP.
(That’s the key clue for this error.)
Waiting for your result.
 
That means the certificates are installed without their private keys — so GSignCode (or any signing tool) can’t access a key provider.
Moreover, certificate 8 isn't your own certificate, it's the one of Sectigo: so you only have the public cert chain (intermediates/roots), not your actual code-signing certificate with private key.
Please contact your Certificate provider for correct installation instructions.
 
The certificate is on a token, it is properly installed on my computer.
I uninstalled 2025.2 and installed 2025.1, was able to sign again with the same token and same xplp template.
Something seems wrong in 2025.2, we have to skip this version unfortunately.
Thank you
 
That's strange — nothing changed between versions 2025.1 and 2025.2 regarding code signing. Could this issue be related to something else introduced during the new version's installation?
 
We did a lot of installation/dezinstallations, 2025.2 was installed 2-3 times, but only with earlier versions was able to sign as usual.
It is strange indeed. From our side, there was no significant change in the file content, we just use the same xplp template on all padlock versions.
 
And in 2025.1, we still see the same strange web update process: when we open an exe, we see the update notification, we click on get update. Then, the OLD version still continues to open up... We close it, then when we reopen the same exe, ONLY THEN we see the successfully updated message (custom message) and the NEW version opens. Was not able to test this process in 2025.2 because of the code signing error, but my guess is that will work the same.

In my opinion, once you click on Get Update, the old version should no longer open up, it is confusing. On Get Update button, after downloading the new version, users should just see a success message like : " Successfully updated, the application will now close. Please open it again to start using the new version."
 
In version 2025.2, the web update process has been significantly revised to prevent such scenarios from occurring, especially with Universal EXE. If you manage to restore code signing (you can now also switch to the standard Microsoft SignTool in XLS Padlock as a workaround), upgrading would be the recommended option.
 
Back
Top