Authenticode Errors: Troubleshooting Guide
Diagnose Authenticode signature failures and Windows publisher warnings by tracing the failure from file integrity and signature validation through certificate, chain, timestamp, and Windows trust.
What an Authenticode error is really telling you
An Authenticode error means that something in the Windows signing or verification path did not meet the expected conditions. The failure may happen while creating the signature, while Windows validates the signed file, or while Windows evaluates the signer certificate and its trust information.
The fastest way to troubleshoot is to avoid treating every warning as a certificate problem. Work through the layers in order: file integrity → signature → certificate → chain → timestamp → Windows trust. A SmartScreen warning may sit outside that validation path because reputation and security signals are not the same thing as Authenticode signature validation.
Start by identifying the stage where the failure occurs
Signing
These failures happen before a usable signature reaches the released artifact.
- SignTool errors
- Certificate selection
- Private-key access
- File-format or signing problems
Verification
These appear when Windows or a verification tool examines the signed file.
- Invalid signature
- Modified file
- Certificate problems
- Chain or trust problems
Windows and user experience
A publisher message can have several causes and should not automatically be interpreted as a broken signature.
- Publisher could not be verified
- Unknown publisher
- Certificate not trusted
- SmartScreen warnings
Lifecycle
Signing-time evidence and certificate status can affect how older and newer signatures are evaluated.
- Expired certificate
- Revoked certificate
- Timestamp problems
Use one sequence for nearly every Authenticode investigation
Do not jump directly from a Windows warning to a certificate replacement. First establish what Windows can actually see in the artifact.
Is the file signed?
If no signature is present, verify that you inspected the intended artifact and that signing was not stripped during packaging.
Is the signature cryptographically valid?
An invalid signature commonly points to a changed file, corrupted signature data, or an incorrect signing process.
Is the signing certificate valid?
Check certificate validity, intended use, signer identity, and status rather than assuming every certificate problem is a chain problem.
Can Windows build a trusted chain?
Inspect the signer certificate, intermediate CA, and root CA in the environment where the failure occurs.
Is the certificate revoked?
Separate revocation from ordinary expiration. Status checking can affect the result seen by a particular Windows environment.
Is there a valid timestamp?
Timestamping provides evidence about when the signature was created and can matter when the signing certificate later expires.
Is the remaining warning actually SmartScreen or reputation-related?
If the signature and certificate path validate but a warning remains, investigate reputation and Windows security signals separately.
“The digital signature is not valid”
A failed Authenticode signature means Windows could not establish the expected cryptographic relationship between the signed content and the signature. The file may have changed after signing, the signature may be damaged, or the signing process may have produced an invalid structure.
File changed
Rebuilding, changing resources, repackaging, or applying post-signing processing can alter signed content and invalidate the signature.
Signature damaged
Corruption or an invalid signature structure can prevent Windows from validating the Authenticode data.
Signing process
An incorrect signing workflow can leave the artifact without a usable signature even when a signing command was executed.
Diagnostic rule: inspect the actual released file, not the build output you signed earlier. If the release pipeline produces a different artifact, the signature on the original file does not prove anything about the final file.
Why a signed file becomes invalid after modification
Authenticode verification relies on the signed file content remaining consistent with the content represented by the signature. If a build or packaging step changes signed content after signing, Windows can calculate a different result during verification and the signature can fail.
Correct release order
- Build
- Package and finalize
- Sign
- Timestamp
- Verify
- Release
Common failure pattern
- Build
- Sign
- Modify resources
- Compress or repackage
- Release
“No signature was present”
A missing signature does not necessarily mean the signing system failed. First confirm that the file you inspected is the same artifact that the signing command targeted. Build systems often produce several similarly named outputs, and packaging can create a new artifact after the signing step.
Check the artifact
- Was this the exact file passed to the signing tool?
- Was another EXE or DLL produced later?
- Did packaging create a replacement file?
- Was the signature stripped or lost during processing?
Confirm the signing result
Inspect the target file with Windows File Explorer, PowerShell, or SignTool. A successful command against one artifact does not establish that every file in the release package is signed.
“Publisher could not be verified”
This message should be treated as a diagnostic symptom, not as a single root cause. Windows may be unable to establish publisher information because the file is unsigned, the signature is invalid, the signer certificate is not trusted, the chain cannot be built, certificate status cannot be established, or the environment does not recognize the publisher identity as expected.
Signature
Confirm that a signature exists and is cryptographically valid.
Certificate
Inspect the signer certificate, subject, organization identity, validity, and intended use.
Trust
Check the intermediate and root chain, local trust stores, and certificate status.
Do not equate this with SmartScreen. Authenticode establishes signature and signer information. SmartScreen can apply additional reputation and security signals even when an application has a valid signature.
Why Windows may show an unexpected publisher
Publisher information comes from the signing identity represented by the certificate. If Windows cannot establish the signer cleanly, the publisher can appear unknown or unexpected. The investigation should therefore move from the signature to the signer certificate and then through its trust chain.
Inspect the signer
Check the certificate subject and organization identity shown for the signing certificate. Confirm that the certificate is the one your release process intended to use.
Inspect trust
A correct identity in the certificate does not by itself establish that Windows trusts the certificate chain on the affected machine.
“Certificate is not trusted”
When the signer certificate is valid but the certificate path is not trusted, inspect the complete chain rather than focusing only on the leaf certificate. The expected path is signer certificate → intermediate CA → root CA.
Intermediate missing
The affected machine may not have what it needs to build the expected path to the trusted root.
Root not trusted
A private or internal CA may not be present in the relevant trust store, or the expected public trust anchor may not be available.
Environment differs
Enterprise policy, local trust-store configuration, network access, and system configuration can produce different results between machines.
“Certificate has expired”
Separate two situations that can look similar during troubleshooting: the certificate expired before the file was signed, or it expired after the file was signed. These are not equivalent cases.
Expired before signing
A newly created signature using an expired signing certificate is a certificate-validity problem. The certificate needs to be replaced before producing a new release.
Expired after signing
A previously signed file can have different verification evidence when it contains a valid timestamp. Timestamping records signing-time evidence that can matter after the certificate's validity period ends.
Practical check: inspect both the certificate validity period and the timestamp attached to the signature. Do not decide the outcome from the current certificate expiration date alone.
“Certificate has been revoked”
Revocation means the issuing authority has indicated that the certificate should no longer be trusted for its intended purpose. It is different from ordinary expiration and can indicate a more serious event, including suspected private-key compromise.
During new signing
Do not continue using a revoked signing certificate for new releases. Investigate the reason for revocation and move to an appropriate replacement certificate.
For existing software
Review the signature, timestamp, certificate status, and Windows verification context. A timestamped historical signature requires a more careful analysis than simply checking whether the certificate is currently active.
If compromise is suspected: treat the event as a key-security incident, not merely as a certificate renewal task. Protect or disable the affected signing key according to the certificate authority and your incident-response process.
When signing succeeds but timestamping fails
Timestamping is a separate part of the signing workflow. A signing operation can create a signature successfully and still fail to obtain or validate the timestamp evidence. Diagnose the signing operation and timestamp operation separately.
Common timestamp failures
- Timestamp server unavailable
- Invalid timestamp response
- Timestamp verification failure
- Incorrect timestamp configuration
- Timestamp certificate or chain problem
What to verify
- Did the signing command return a timestamp error?
- Does the signature show timestamp information?
- Can the timestamp certificate chain be validated?
- Does the final artifact contain the expected timestamp?
Why it matters: timestamping provides evidence about when the signature was created. That evidence can become important when the signing certificate later expires.
Use SignTool errors as evidence, not as the diagnosis
SignTool is useful for signing and verification, but an error message is most useful when tied to the layer that failed. For each failure, capture the exact message, identify the likely layer, inspect the artifact and certificate, apply the smallest relevant fix, and verify the result again.
| Failure | Meaning | First diagnostic step | Typical direction |
|---|---|---|---|
| Certificate not found | No suitable certificate was selected or available to the signing operation. | Inspect the certificate store and selection criteria. | Correct store, subject, thumbprint, or certificate selection. |
| Private key unavailable | The certificate is present but the signing operation cannot access its private key. | Check certificate-to-key association and key access. | Permissions, provider, KSP/CSP, HSM, or service-account access. |
| Access denied | The process cannot access the file or signing key as required. | Identify whether the blocked resource is the artifact or key. | File permissions, key permissions, account context. |
| Signing failed | The signing operation did not produce a usable result. | Check the exact command, target artifact, certificate, and key. | Correct parameters or signing environment. |
| Timestamp failed | The signature step may have completed but timestamp acquisition or validation did not. | Inspect timestamp configuration and response. | Timestamp service, configuration, or chain. |
| Verification failed | Windows or SignTool could not validate the resulting signature. | Verify the exact released artifact. | File integrity, signature, certificate, chain, or status. |
| Incorrect parameters | The command does not match the intended signing or verification operation. | Review target, digest, timestamp, and verification options. | Correct the command, then verify. |
When SignTool selects the wrong certificate
Multiple certificates in a Windows environment can make certificate selection a troubleshooting problem of its own. An expired certificate, a certificate with the wrong purpose, or a certificate in an unexpected store can produce confusing signing results even when a correct certificate is installed somewhere on the machine.
Check the selection inputs
- Certificate store
- Subject name
- Thumbprint
- Validity period
- Intended certificate purpose
Check the actual signer
After signing, inspect the certificate embedded in the artifact. Do not assume the certificate you intended to select is the certificate that Windows ultimately sees on the file.
Certificate present, private key unavailable
A code signing certificate and its private key serve different roles. The certificate can be visible in a certificate store while the private key is unavailable, inaccessible to the current account, or managed by a provider such as an HSM-backed key system.
No private key
Confirm that the installed certificate is associated with the private key required for signing.
Access problem
Check permissions and the account under which the signing process runs. A developer account and CI service account may not have identical access.
Provider problem
CSP/KSP configuration, HSM connectivity, provider permissions, or service-account access can block a hardware-protected key.
Diagnosing Authenticode chain errors
Windows validates more than the leaf signing certificate. It needs to establish a trusted certificate path. A certificate can look valid when opened by itself while the complete chain still fails to build or trust on the affected machine.
Choose a certificate for your signing environment
Once you have identified the failure, compare certificate options suited to your software, signing workflow, and publisher requirements.
Explore Microsoft Authenticode CertificatesWhy Authenticode works on one computer but fails on another
When the same artifact verifies differently on two Windows systems, compare the environments before changing the certificate or rebuilding the application. Trust stores, certificate status access, operating-system configuration, enterprise policy, and even the exact artifact can differ.
Compare the environment
- Windows version and configuration
- Root and intermediate trust
- Certificate status access
- Network or revocation access
- Enterprise security policies
Compare the artifact
- Exact file hash or release artifact
- Signer certificate
- Signature status
- Timestamp information
- Verification output
Best practice: save verification output from both machines and compare the signer, chain, status, timestamp, and file being inspected. This is usually more useful than comparing only the visible Windows warning.
A valid signature does not guarantee that SmartScreen will be silent
Authenticode validation ≠ SmartScreen reputation. A valid Authenticode signature can establish the integrity and signer information represented by the certificate and signature. SmartScreen can still apply separate reputation and security signals to the application or publisher.
Valid signature
The file passes the relevant signature and certificate validation checks.
Publisher identity
The signer certificate provides publisher identity when Windows can establish it successfully.
Reputation
Software reputation and Microsoft security signals can produce a warning even when the signature itself is valid.
When a file contains more than one Authenticode signature
A file can contain multiple signatures in scenarios where signing identities or signature evidence need to coexist. Troubleshooting such files requires identifying which signature is being inspected and how the verification tool presents each signer.
Inspect each signature
Check the signer certificate, validity, chain, timestamp, and verification result for each signature rather than assuming all signatures have identical status.
Watch for conflicting results
Certificate expiration or revocation can affect historical signatures differently depending on their timestamp and verification context. Capture complete verification output before removing or replacing signatures.
Authenticode troubleshooting by artifact
| Artifact | Primary troubleshooting focus | Special consideration |
|---|---|---|
| EXE | PE signature, certificate, chain, timestamp | Confirm the exact executable released to users. |
| DLL | PE signature, certificate, chain, timestamp | Check whether later packaging or deployment altered the component. |
| MSI | Package and signature verification | Separate the MSI signature from signatures on files contained inside the package. |
| PowerShell | Authenticode plus PowerShell execution behavior | Execution policy introduces additional rules beyond signature validity. |
| SYS | Signature plus Windows driver-signing requirements | Driver enforcement and platform policy add requirements beyond a generic application signature. |
For PowerShell and driver-specific behavior, use dedicated platform guidance rather than duplicating every execution-policy or driver-signing rule on this page.
Choose the tool based on the question you need answered
Detailed signing and verification
Use SignTool when you need explicit signing or verification operations and detailed command-line output. It is particularly useful in build and CI/CD diagnostics.
Quick Windows inspection
The Digital Signatures tab provides a convenient first look at whether the file is signed and which signer information Windows presents.
Scriptable inspection
Get-AuthenticodeSignature is useful for checking Authenticode status in repeatable PowerShell workflows.
Certificate and chain details
Use the certificate viewer to inspect subject identity, validity, issuer, chain, and other certificate properties after locating the signer.
Build a more reliable signing workflow
For teams signing Windows software, certificate selection, key protection, and release verification should work together. Review options designed for software publishing teams.
Explore Code Signing for Software CompaniesFrom the first warning to the actual root cause
Error appears
Record the exact Windows or SignTool message and the exact artifact involved.
Inspect signature
Determine whether the file contains an Authenticode signature and identify the signer.
Signature present?
No means verify the artifact and signing step. Yes means continue into signature validation.
Signature valid?
No means investigate file integrity or signature structure. Yes means continue.
Certificate valid?
No means investigate expiration, revocation, or certificate purpose. Yes means continue.
Chain trusted?
No means investigate the signer-to-intermediate-to-root path and Windows trust environment.
Timestamp valid?
No means investigate timestamp configuration and timestamp certificate validation.
SmartScreen or reputation?
If the signature path validates, treat a remaining application warning as a separate Windows security or reputation question.
Quick reference for common symptoms
| Symptom | Likely layer | First thing to check |
|---|---|---|
| Digital signature invalid | File / signature | Whether the file changed after signing. |
| No signature | Signing | Whether the correct artifact was signed and released. |
| Publisher unknown | Certificate / trust | Signer certificate and its trust path. |
| Certificate not trusted | Chain | Root and intermediate certificates. |
| Certificate expired | Lifecycle | Certificate validity and timestamp. |
| Certificate revoked | Status | Revocation information and signing history. |
| Timestamp invalid | Timestamp | TSA response and timestamp certificate. |
| SignTool cannot find certificate | Certificate | Certificate store and selection criteria. |
| Private key unavailable | Key | Key association, access, provider, or HSM. |
| SmartScreen warning | Reputation / security | Whether Authenticode itself already validates. |
Signed EXE, but another Windows computer cannot verify the publisher
Assume MyApp.exe is successfully signed on the build machine. A second Windows computer reports that the publisher cannot be verified.
The right response is not immediately to issue a new certificate. Compare the verification layers in sequence.
- Confirm the signature exists.
- Verify signature integrity.
- Inspect the signer certificate.
- Inspect the certificate chain.
- Check certificate status.
- Check timestamp evidence.
- Compare the trust environment.
- Determine whether the remaining warning is SmartScreen or reputation-related.
Prevent the common Authenticode failures before release
Build discipline
- Sign the final build artifact.
- Do not modify files after signing.
- Keep packaging before signing.
- Verify the exact release artifact.
Certificate discipline
- Use the correct certificate.
- Protect the private key.
- Include timestamping.
- Monitor expiration and revocation.
Operational discipline
- Verify immediately after signing.
- Test on a clean Windows system.
- Secure CI/CD signing credentials.
- Keep signing out of ordinary developer workflows where practical.
Frequently asked Authenticode troubleshooting questions
Why is my Authenticode signature invalid?
First check whether the released file changed after signing. Rebuilding, modifying resources, repackaging, or post-signing processing can invalidate the signature. Then inspect the signature structure and verification output.
Why does Windows say the publisher cannot be verified?
Possible causes include a missing signature, invalid signature, untrusted signer certificate, broken chain, certificate status problem, or platform trust issue. Check the signature and certificate path before treating it as a SmartScreen problem.
Why does my signed EXE show an unknown publisher?
Inspect the signer certificate and the trust chain. Windows obtains publisher identity from the signing certificate, but the identity may not be established cleanly if the signature, certificate, or chain cannot be validated.
Why is my code signing certificate not trusted?
Check the signer-to-intermediate-to-root path. A missing intermediate, untrusted root, local trust-store difference, private CA, or enterprise policy can prevent Windows from building a trusted chain.
Why does Authenticode work on one computer but not another?
Compare the exact artifact, certificate chain, trust stores, certificate status access, Windows configuration, network conditions, and enterprise policies on both systems.
Why does my signature become invalid after rebuilding?
The rebuilt file is a different artifact. Sign the final build output after all compilation and packaging changes are complete, then verify that exact artifact before release.
Why did timestamping fail?
Separate the signing result from the timestamp result. Check the timestamp service, command configuration, response, and timestamp certificate or chain.
Can an expired certificate still validate an Authenticode signature?
A timestamp can provide evidence about when a signature was created, so an older signed file can have a different verification outcome from a newly signed file using an expired certificate. Inspect the signature timestamp and full verification result.
Why does SmartScreen warn about a signed application?
Authenticode validation and SmartScreen reputation are different checks. A valid signature does not guarantee that reputation or other Windows security signals will produce no warning.
How do I check an Authenticode signature?
Use Windows File Explorer for a quick inspection, PowerShell with Get-AuthenticodeSignature for scriptable status, or SignTool for detailed command-line verification.
Continue with the right troubleshooting guide
These topics should remain separate so each page answers a distinct search intent instead of repeating the same Windows signing explanation.
Trace the failure before changing the certificate
Identify the failing validation layer, verify the released artifact, and then choose the certificate and signing workflow that fit your application.
Explore Windows Code Signing Certificates