SignTool Error: No Certificates Were Found That Met All the Given Criteria
This error means SignTool launched but its certificate-selection path ended with no usable signing identity. Do not reinstall SignTool first. Preserve the same signing source—certificate store, explicit PFX/P12, or Artifact Signing integration—then rerun with /debug where applicable and follow the first selection/filter boundary that eliminates the intended candidate. Do not mix store-selection fixes into an explicit-PFX or Artifact Signing failure.
Repeat your existing signing command with /debug immediately after sign. Keep the same certificate source and selectors so the diagnostic matches the failing command.
signtool sign /debug /v <your existing certificate options> /fd SHA256 "app.exe"Read the selection evidence, not just the final error. For store-based selection, the first filter that takes the intended candidate set to zero is the strongest lead. With an explicit /f PFX or Artifact Signing integration, keep that source model intact and diagnose its file/provider/integration path instead of switching blindly to certificate-store fixes. If signtool itself is not recognized, use the command-resolution guide first.
Using Microsoft Artifact Signing? Check this branch first
If this exact error appears while you are using Microsoft Artifact Signing, do not begin by changing the local certificate store, EKU, or private-key permissions. Microsoft documents a different meaning for this workflow: SignTool can fall back to looking for certificates on the local computer instead of using Artifact Signing certificates.
Verify: rerun the Artifact Signing command after correcting the integration values. If it reaches the Artifact Signing service instead of local certificate filtering, stop here; the local-store fixes below are not the right branch.
Diagnostic flow — follow the first filter that reaches zero
If the command itself is missing or unrecognized, solve tool discovery first.
Keep the same certificate source and selectors so the filter counts describe the real failure.
Use that stage—not the final generic error—to choose the next fix below.
What “all the given criteria” actually means
SignTool does not simply ask whether a certificate exists. It filters available candidates according to signing suitability and the options in your command. Depending on how you invoke it, that can include enhanced key usage, validity, private-key availability, subject or thumbprint selection, certificate store/context, and an explicitly supplied certificate file. The same final message can therefore represent several different failures.
Fix #1 — 0 certificates left after the EKU filter
For code signing, the certificate must be suitable for that purpose. A TLS/server-authentication certificate is not interchangeable with a code-signing certificate. Inspect the certificate’s Enhanced Key Usage / Intended Purposes and confirm it includes Code Signing.
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey, EnhancedKeyUsageListVerify: rerun the same SignTool command with /debug. At least one intended certificate should survive the EKU filter. If EKU still leaves zero, do not try to repair PATH or loosen unrelated certificate settings.
Fix #2 — 0 certificates left after the expiry filter
Check the candidate’s NotBefore and NotAfter dates and the machine clock. An expired certificate cannot be made current by changing the SignTool selector. Obtain/renew the appropriate signing certificate when the validity period is the cause.
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, Thumbprint, NotBefore, NotAfterVerify: the intended certificate should now survive both EKU and expiry filtering in /debug output.
Fix #3 — 0 certificates left after the Private Key filter
A public certificate alone is not enough to sign. In PowerShell, HasPrivateKey = True is useful inventory evidence, but it does not prove the failing identity can successfully use that key through its actual key provider. If you moved the certificate between machines, make sure you imported a PFX/P12 that contains the private key rather than only a CER/CRT public certificate. For service/CI failures, distinguish key presence from provider/key-container access under that exact identity.
Get-ChildItem Cert:\CurrentUser\My | Where-Object HasPrivateKey | Select-Object Subject, Thumbprint, HasPrivateKeyIf the private key exists but the failure occurs only under a service/build identity, test under that exact identity. Private-key access is security-sensitive: grant only the account that needs signing access rather than broadening permissions globally.
Verify: under the same identity that performs the build/sign, rerun the same signing attempt. The intended certificate must survive private-key selection and the process must actually progress beyond certificate selection. If the error changes to key-provider access, PIN/HSM, digest, timestamp or signing failure, stop diagnosing “no certificates found” and follow that new boundary.
Fix #4 — check Current User vs Local Machine certificate store
SignTool can search a certificate store, but the account and store context matter. A certificate installed for your interactive user may be invisible to a build service. Conversely, a certificate placed in the Local Machine store requires the command to search the machine context when appropriate.
Get-ChildItem Cert:\CurrentUser\My
Get-ChildItem Cert:\LocalMachine\My/sm option selects the machine store instead of the default user-store context. Do not add it blindly if your certificate is actually under Current User.Verify: run the diagnostic under the same user/service identity as the failing build and confirm the expected certificate appears in the considered candidates.
Fix #5 — remove or correct an over-specific store selector
If you are selecting from a certificate store and use /n (subject name), /sha1 (thumbprint), or another store-selection option, a stale or mismatched value can filter out an otherwise valid certificate. Do not copy a thumbprint from a different machine or renewed certificate without checking it.
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, ThumbprintCompare the exact subject/thumbprint against the selector in your build configuration. For diagnosis, remove only the suspect selector when doing so does not create ambiguity, or replace it with the verified value.
Verify: the expected certificate should appear and survive the corresponding selection stage in /debug.
Fix #6 — if you use /f, validate the PFX rather than the certificate store
With an explicit /f PFX/P12, treat the file as the certificate source rather than debugging CurrentUser/LocalMachine store discovery first. Confirm the file is the intended signing identity, opens with the expected secret mechanism, contains the certificate plus its private key, and is appropriate for code signing. Do not paste PFX passwords into source code, public CI logs, screenshots, or support posts.
Verify: rerun the same /f-based command with /debug; the PFX certificate should survive EKU, validity, and private-key selection.
Works manually but fails in CI, MSBuild, or a Windows service?
This strongly points to execution context. Determine which Windows account actually runs the signing process, then inspect the certificate store and private-key accessibility from that account’s context. A certificate visible to your desktop login is not automatically available to a service account or hosted runner.
whoami
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, Thumbprint, HasPrivateKeyVerify: inside the failing job/service context, print the non-secret certificate identity (for example subject/thumbprint), confirm private-key availability without exposing key material, then run the SignTool diagnostic.
What not to do
Still seeing the error?
/debug filter countscertificate Subject, Thumbprint, EKU, NotAfter and HasPrivateKeyCurrent User vs Local Machine store and store namethe Windows identity shown by whoami in the failing contextwhether the failure is local, Visual Studio/MSBuild, service, or CI-onlywhich certificate source model is active: store, explicit /f PFX/P12, or Artifact Signingwhether HasPrivateKey is merely present or the exact signing identity can actually use the key/providerthe first different error after certificate selection succeedsIf SignTool cannot be launched at all, go back to ‘signtool’ Is Not Recognized. If the executable itself is missing, use SignTool.exe Not Found. If a certificate is successfully selected and the next error concerns trust, timestamping, digest algorithms, or verification, treat that new message as a separate stage.
Official references
Still stuck? Ask the community
Share the redacted command, the first /debug filter that reaches zero, certificate metadata, and whether the failure is local or CI-only.
Loading community discussion…
Comments could not load here. Open ErrorHarbor Discussions on GitHub →