# Signtool.exe verify error **URL:** \ **Category:** Discussions\ **Created:** [July 21, 2025, 6:07pm UTC](https://www.finalbuilder.com/forums/t/signtool-exe-verify-error/7680 "2025-07-21T18:07:51Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![danielk](https://www.finalbuilder.com/forums/letter_avatar_proxy/v4/letter/d/a88e57/32.png) [@danielk](https://www.finalbuilder.com/forums/u/danielk)\ **Post date:** [July 21, 2025, 6:07pm UTC](https://www.finalbuilder.com/forums/t/signtool-exe-verify-error/7680/1 "2025-07-21T18:07:51Z")
Using SignotaurTool to verify a SignotaurTool signed exe does verify successful When running signtool.exe verify (the microsoft signtool) I am getting the following error: ```plaintext 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 ``` We are using Signataur Server with a SafeNet token with a Sectigo certidicate. Looking for the error online does not provide something relevant for this context. Right click on the signed exe does indicate it is signed ---
**Author:** ![Sparky](https://www.finalbuilder.com/forums/user_avatar/www.finalbuilder.com/sparky/32/10_2.png) [@Sparky](https://www.finalbuilder.com/forums/u/Sparky)\ **Post date:** [July 21, 2025, 11:18pm UTC](https://www.finalbuilder.com/forums/t/signtool-exe-verify-error/7680/2 "2025-07-21T23:18:18Z")
Hi Daniel, The error you’re seeing from `signtool verify` (certificate chain processed, but terminated in a root certificate which is not trusted) typically means that the full certificate chain is missing from the certificate that you are using. This can happen if the certificate wasn’t added to the Signotaur server correctly - for example, if it was imported from a file or store rather than added via the [Hardware tab on the Add Certificate dialog](https://docs.finalbuilder.com/sn/1.0/server/admin/certificates/library.html). This ensures the full trust chain is obtained directly from the PKCS#11 token. Without the full chain, the root or intermediate certificates may be missing from the signed file, leading to trust issues. Which command line options did you use with SignotaurTool.exe? If you used the `--ignore-untrusted-root` option when verifying, then this bypasses trust checks on the root certificate. Can you share a command line session showing the command lines and output? Ensure that you use the `--verbose` option as it will output more information about the signing process and the certificate chain. ---
**Author:** ![danielk](https://www.finalbuilder.com/forums/letter_avatar_proxy/v4/letter/d/a88e57/32.png) [@danielk](https://www.finalbuilder.com/forums/u/danielk)\ **Post date:** [July 22, 2025, 7:21am UTC](https://www.finalbuilder.com/forums/t/signtool-exe-verify-error/7680/3 "2025-07-22T07:21:55Z")
The issue is not that Signotaur sign and verify are successful. But microsofts signtool fails. When starting the exe and on showing properties windows is happy with the signing. This is the command line for sign, verify and verify with signtool, I left it timestamping for the example as that is not the certificate it is complaining about: ```auto SignotaurTool sign -a " ***" -s "https://*** :8443" -t A...F --fd SHA256 --verbose TTXAdmin.exe +---------------------------------------------------------------------------------------------------------------------------------------------------------+ | SignotaurClient | | Version : 1.0.0.459 | | © 2025 VSoft Technologies Pty Ltd | | | +---------------------------------------------------------------------------------------------------------------------------------------------------------+ 09:14:25 Debug: Request timeout for 1 file set to 10 seconds. 09:14:25 Debug: Fetching public key 09:14:25 The following PKCS11 certificate was selected: Issued to: CN=TimeTell B.V., O=TimeTell B.V., S=Zuid-Holland, C=NL Issued by: CN=Sectigo Public Code Signing CA R36, O=Sectigo Limited, C=GB Expires: 07/04/2028 01:59:59 09:14:25 Debug: Full certificate details: [Subject] CN=TimeTell B.V., O=TimeTell B.V., S=Zuid-Holland, C=NL [Issuer] CN=Sectigo Public Code Signing CA R36, O=Sectigo Limited, C=GB [Serial Number] 5...5 [Not Before] 07/04/2025 02:00:00 [Not After] 07/04/2028 01:59:59 [Thumbprint] A...F 09:14:25 Debug: Certificate chain element : A...F 09:14:25 Debug: Certificate chain element : 0...A 09:14:25 Debug: Certificate chain element : 3...2 09:14:25 Debug: Certificate chain element : D...9 09:14:25 Signing 1 file. 09:14:25 Using a maximum of 4 parallel signing operations. 09:14:25 Sending sign request to server for file TTXAdmin.exe (size: 42.3 MB) ... 09:14:27 TTXAdmin.exe signed successfully. 09:14:27 Debug: Returning exit code: 0. 09:14:27 Debug: Exit code: 0 09:14:27 Execution time: 2s 314ms ``` ```auto SignotaurTool verify --verbose TTXAdmin.exe +---------------------------------------------------------------------------------------------------------------------------------------------------------+ | SignotaurClient | | Version : 1.0.0.459 | | © 2025 VSoft Technologies Pty Ltd | | | +---------------------------------------------------------------------------------------------------------------------------------------------------------+ 09:14:27 Verifying 1 file. 09:14:27 TTXAdmin.exe is signed and the signature was verified. 09:14:27 Debug: Returning exit code: 0. 09:14:27 Debug: Exit code: 0 09:14:27 Execution time: 152ms ``` ```auto signtool.exe verify /v /debug TTXAdmin.exe Verifying: TTXAdmin.exe Signature Index: 0 (Primary Signature) Hash of file (sha256): 7...B Signing Certificate Chain: Issued to: AAA Certificate Services Issued by: AAA Certificate Services Expires: Mon Jan 01 01:59:59 2029 SHA1 hash: D...9 Issued to: Sectigo Public Code Signing Root R46 Issued by: AAA Certificate Services Expires: Mon Jan 01 01:59:59 2029 SHA1 hash: 3...2 Issued to: Sectigo Public Code Signing CA R36 Issued by: Sectigo Public Code Signing Root R46 Expires: Sat Mar 22 01:59:59 2036 SHA1 hash: 0...A Issued to: TimeTell B.V. Issued by: Sectigo Public Code Signing CA R36 Expires: Tue Jul 04 01:59:59 2028 SHA1 hash: A...F File is not timestamped. 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 ``` ---
**Author:** ![Sparky](https://www.finalbuilder.com/forums/user_avatar/www.finalbuilder.com/sparky/32/10_2.png) [@Sparky](https://www.finalbuilder.com/forums/u/Sparky)\ **Post date:** [July 22, 2025, 11:40am UTC](https://www.finalbuilder.com/forums/t/signtool-exe-verify-error/7680/4 "2025-07-22T11:40:50Z")
Hi Daniel, SignotaurTool’s `verify` command checks that a signature exists and is well-formed. It doesn’t currently check if the root certificate is trusted. The error from `signtool.exe` is specifically a **trust** error, not a **signature** error. This means that the machine running `signtool` doesn’t trust the root certificate at the end of the chain (in this case: `AAA Certificate Services`). That certificate needs to be present in the “Trusted Root Certification Authorities” store for `signtool` to consider the signature fully trusted. To resolve the `signtool` error, make sure the root certificate (`AAA Certificate Services`) is trusted on the verifying machine. We are looking into the possibility of updating to SignotaurTool’s `verify` command to include an option to verify that the root certificate is trusted. ---
**Author:** ![danielk](https://www.finalbuilder.com/forums/letter_avatar_proxy/v4/letter/d/a88e57/32.png) [@danielk](https://www.finalbuilder.com/forums/u/danielk)\ **Post date:** [July 22, 2025, 8:58pm UTC](https://www.finalbuilder.com/forums/t/signtool-exe-verify-error/7680/5 "2025-07-22T20:58:49Z")
Ok thanks Dave, I actually did check if AAA Certificate Services was in the trust store and it is. But as I understand I am looking more at a signtool issue then something done wrong by Signotaur. If I change the command to singtool verify /pa exe it works fine. ---
**Author:** ![Sparky](https://www.finalbuilder.com/forums/user_avatar/www.finalbuilder.com/sparky/32/10_2.png) [@Sparky](https://www.finalbuilder.com/forums/u/Sparky)\ **Post date:** [July 22, 2025, 11:32pm UTC](https://www.finalbuilder.com/forums/t/signtool-exe-verify-error/7680/6 "2025-07-22T23:32:07Z")
Hi Daniel, When you run `signtool verify` without the `/pa` option, it uses the Windows Driver Verification Policy. This legacy policy is for kernel‑mode drivers. It only recognizes the classic SHA‑1 Authenticode format (SPC indirect‑data OID, PKCS#9 message‑digest) and chains to Microsoft’s driver‑signing roots. Because the SignotaurTool signature is SHA‑256 (and uses the modern PKCS#7 format), the default driver policy doesn’t see it and reports a trust failure - even though the root (“AAA Certificate Services”) is in your store. The `/pa` flag tells SignTool to use the modern Authenticode policy provider. This policy understands SHA‑2 signatures, the newer SPC indirect‑data format, and chains to a broader set of public and enterprise CAs (including your EV root). That’s why `signtool verify /pa TTXAdmin.exe` succeeds - the signature matches exactly what this policy expects.