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:
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
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. 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.
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:
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
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.
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.
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.