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.

SignTool · Code Signing · CertificatesWindows SDK · PFX · CI/CDLast reviewed Sep 27, 2026
🎯 You’re likely in the right place if:
SignTool launches, but signing ends with No certificates were found that met all the given criteria.You are selecting from a Windows certificate store or supplying a PFX/P12 file.The failure may occur locally, in Visual Studio/MSBuild, or only under a CI/service account.
Choose the branch shown by /debug
0 left after EKU filterThe certificate is not eligible for code signing; inspect Enhanced Key Usage.
0 left after expiry filterThe candidate is outside its validity period; replace/renew it rather than bypassing validity.
0 left after Private Key filterThe signing identity cannot access a usable private key, or the imported certificate lacks one.
No expected certificate is consideredCheck user vs machine store, store name, selector, PFX path, and the account running SignTool.
Difficulty: ModerateRisk: Certificate-sensitive
🔎 Quick Check — make SignTool show why every candidate was rejected

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.

ADSENSE · reserved slot after the first useful step

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.

Check the Artifact Signing integration first: verify the dlib path, dlib version, dlib name, filename, and SignTool version. If those are correct and the failure still behaves like local certificate selection, continue with the diagnostic flow below.

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

1
Prove SignTool runs.
If the command itself is missing or unrecognized, solve tool discovery first.
2
Rerun the same signing attempt with /debug.
Keep the same certificate source and selectors so the filter counts describe the real failure.
3
Find the first filter that leaves zero candidates.
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.

Do not guess from the final line. A certificate visible in Certificate Manager is not proof that the current SignTool process can select it and use its private key.

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, EnhancedKeyUsageList

Verify: 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, NotAfter

Verify: 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, HasPrivateKey

If 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
About /sm: when your intended certificate is in the machine store, SignTool’s /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, Thumbprint

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

Safer CI pattern: inject the certificate and secret through your CI platform’s protected secret/secure-file mechanism, then remove temporary material according to your pipeline’s security model. Never commit the PFX or its password to the repository.

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, HasPrivateKey

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

Do not disable code signing merely to silence a production signing failure.Do not export, post, or commit private keys/PFX passwords while troubleshooting.Do not grant broad private-key permissions such as Everyone/Full Control.Do not use a TLS/server certificate just because it appears in the Personal store.Do not change PATH or reinstall the Windows SDK when SignTool already runs and reaches certificate filtering.Do not treat HasPrivateKey=True as proof that a service/CI identity can use the key provider or key container.Do not mix certificate-store selectors and /sm troubleshooting into an explicit /f PFX failure unless the command actually uses the store.Do not switch an Artifact Signing failure to local-store troubleshooting until you have proved the Artifact Signing integration is not the active source.Do not keep diagnosing “no certificates found” after certificate selection succeeds and a more specific provider, PIN/HSM, digest, timestamp, trust or signing error appears.

Still seeing the error?

Capture these without exposing secrets:the exact SignTool command with passwords/tokens redactedthe /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 succeeds

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

Keep it safe: never post PFX files, private keys, passwords, tokens, certificate secrets, recovery codes, private URLs or confidential build logs.
Powered by GitHub DiscussionsSign in with GitHub to comment. Reading comments does not require sign-in.

Loading community discussion…