Code signing errors fall into predictable categories: the tool can’t find the certificate, the certificate chain can’t be verified, a network resource is unreachable, the file format isn’t supported, or something modified the file after signing. Knowing which category an error belongs to cuts troubleshooting time significantly.
This reference covers the most common code signing errors across Windows Authenticode, macOS Gatekeeper, Android, and Java, grouped by category. Each entry links to the detailed guide for that specific error.
Windows Authenticode and signtool Errors
signtool.exe is the primary signing tool for Windows. These errors appear during the signing operation itself, during post-signing verification, or at execution time on Windows endpoints.
1. SignTool Error: No certificates were found that met all the given criteria
What it means: signtool couldn’t find a code signing certificate to use. The certificate may not be installed, the private key is inaccessible (token not connected), or the certificate lacks the Code Signing EKU.
Most common cause: Hardware token not connected; middleware not installed; certificate in wrong store; running in a CI context with no access to the user certificate store.
Fix: Connect the USB token and enter the PIN; verify Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert returns results; use /sha1 with the thumbprint to specify the certificate explicitly. See: SignTool Error: No Certificates Found guide.
2. The system cannot find the file specified (signtool not found)
What it means: signtool.exe is not installed or not on the system PATH.
Most common cause: signtool is part of the Windows SDK, not Windows itself. It is not present on machines that only have Windows installed.
Fix: Install the Windows SDK (standalone installer or via Visual Studio), or use winget install Microsoft.WindowsSDK. Add the SDK’s bin directory to PATH. See: signtool.exe Not Found guide.
3. SignTool Error: The specified timestamp server either could not be reached or returned an invalid response
What it means: signtool contacted the RFC 3161 timestamp server at the URL in the /tr flag and received no response or an error.
Most common cause: Firewall blocking outbound HTTP to the timestamp server; corporate proxy not passing timestamp requests; timestamp server temporarily unavailable; CI runner without internet access.
Fix: Test connectivity with Invoke-WebRequest; try an alternative timestamp server (timestamp.sectigo.com, timestamp.globalsign.com); configure WinHTTP proxy with netsh winhttp set proxy. See: Unable to Contact the Code Signing Server guide.
4. SignTool Error: The file format is not recognized or is not supported
What it means: signtool only signs PE (Portable Executable) format files. The file presented for signing is not a PE binary, or has a PE extension but contains different content.
Most common cause: Trying to sign a .jar, .apk, .py, .sh, or other non-PE file with signtool; a renamed ZIP or text file with a .exe extension; the build didn’t complete before signing ran.
Fix: Use the correct tool for the format (jarsigner for JAR, apksigner for APK, Set-AuthenticodeSignature for .ps1); verify the file starts with the MZ PE header; ensure signing runs after the build completes. See: Unrecognized File Format guide.
5. SignTool Error: The digital signature of the object did not verify
What it means: The file’s current content no longer matches the hash that was signed. The file was modified after signing.
Most common cause: A post-sign build step modifying the binary; antivirus injecting monitoring code; file corruption; the file was re-signed with a different certificate.
Fix: Audit the build pipeline and ensure signing is the absolute last step; verify the file hash matches the pre-signing hash; re-sign the final artifact after all modifications complete. See: Code Tampered or Repackaged guide.
6. A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider
What it means: The certificate chain walks up to a root CA that is not in the machine’s Trusted Root Certification Authorities store.
Most common cause: Machine’s Windows root store is outdated; the signing certificate’s intermediate CA was not embedded in the signature; self-signed or internal CA certificate not deployed to the target machine.
Fix: Run Windows Update to refresh the root store; use certutil -syncWithWU for air-gapped machines; ensure the intermediate CA is in Cert:\CurrentUser\CA before signing; deploy internal CA roots via Group Policy. See: Root Certificate Not Trusted guide.
Certificate Trust and Validity Errors
These errors indicate a problem with the certificate itself: expiry, revocation, or trust chain issues that prevent Windows from verifying the publisher identity.
7. Certificate has expired or is not yet valid
What it means: The code signing certificate’s validity period has passed, or the system clock is outside the certificate’s NotBefore/NotAfter range.
Most common cause: Certificate expired without being renewed; system clock incorrect; signing with the /tr timestamp flag missing, causing signatures to expire with the certificate.
Fix: Renew the certificate (maximum 460 days under 2026 CA/B Forum rules); always include /tr timestamp server in signtool commands so signatures outlive the certificate; verify the system clock is correct. See: What Happens When a Code Signing Certificate Expires guide.
8. The certificate is revoked
What it means: The Certificate Authority has revoked this certificate before its expiry date, and the revocation is published on the CA’s CRL or OCSP endpoint.
Most common cause: Private key compromise; certificate obtained fraudulently; publisher requested revocation; CA-initiated revocation due to policy violation.
Fix: Obtain a new certificate and re-sign all software; inform users via your website, update channel, and support channels; the revoked certificate cannot be unrevoked. Check the CA portal for the reason and next steps.
9. Unknown Publisher in UAC dialog (no publisher name shown, yellow/orange shield)
What it means: Windows cannot verify the publisher identity. The software is either unsigned or the certificate chain cannot be verified to a trusted root.
Most common cause: Software is not signed at all; certificate’s root not in the Windows trust store; chain incomplete due to missing intermediate.
Fix: Sign the software with a publicly trusted OV or EV code signing certificate; verify the chain with signtool verify /pa; ensure the intermediate CA certificate is included in the signature. See: Easy Steps to Get a Code Signing Certificate guide.
10. Code signing policy violation / AuthorizationManager check failed
What it means: A policy layer (PowerShell execution policy, WDAC, or Group Policy) refused to allow the software because the signing certificate or publisher is not in the policy’s allowlist.
Most common cause: PowerShell AllSigned: signing certificate not in Trusted Publishers store; WDAC enforcement: publisher not in the enterprise policy; MSIX: Publisher in manifest doesn’t match certificate Subject.
Fix: Add signing certificate to Cert:\LocalMachine\TrustedPublisher (PowerShell); work with enterprise IT to add publisher rule to WDAC policy; for MSIX ensure Publisher attribute exactly matches the certificate Subject. See: Code Signing Policy Violation guide.
macOS Gatekeeper and Code Signature Errors
macOS enforces its own code signing and notarization requirements. These errors appear at app launch, during codesign verification, or in the Finder when users try to open downloaded software.
11. cannot be opened because it is from an unidentified developer
What it means: The app is either unsigned, or signed with a certificate that is not an Apple Developer ID Application certificate.
Most common cause: App built without code signing; signed with a third-party CA certificate instead of an Apple Developer ID; Developer ID certificate expired.
Fix: Obtain an Apple Developer ID Application certificate (requires Apple Developer Program membership, $99/year); re-sign with codesign –sign ‘Developer ID Application: Your Name (TEAMID)’ –options runtime –timestamp. See: macOS Code Signing guide.
12. cannot be opened because Apple cannot check it for malicious software
What it means: The app is signed with a Developer ID certificate but has not been notarized by Apple’s notarization service.
Most common cause: Developer signed the app with codesign but skipped the xcrun notarytool submit step; app was distributed before notarization completed; stapling was skipped.
Fix: Submit to Apple notarization with xcrun notarytool submit –wait; staple the resulting ticket with xcrun stapler staple; verify with spctl –assess –type exec –verbose YourApp.app. See: macOS Code Signing guide.
13. macOS: code or signature modified (codesign -v returns failure)
What it means: A component of the app bundle was modified after the bundle was signed, breaking the signature.
Most common cause: Packaging tool modified the bundle after codesign ran; nested framework or helper tool not signed before the outer bundle; electron-builder post-processing ran after signing.
Fix: Sign all nested components first (inside-out order), then sign the outer bundle; ensure all packaging and post-processing steps complete before the signing step; re-sign the entire bundle after any modification. See: Code Tampered or Repackaged guide.
Android APK Signing Errors
Android signing uses its own scheme (v1 through v4) and verification path, independent of Windows or macOS. These errors appear in Google Play Console, during APK install, or in Google Play Protect warnings.
14. INSTALL_PARSE_FAILED_NO_CERTIFICATES / APK not signed
What it means: The APK was not signed or the signature is missing from the APK package.
Most common cause: Release APK built without signing configuration; wrong build variant used (debug instead of release); Gradle signingConfig not applied to the release buildType.
Fix: Configure signingConfig in the release buildType in build.gradle; build a properly signed release APK; verify with apksigner verify app-release.apk before uploading. See: Code Signing for Mobile Apps guide.
15. INSTALL_FAILED_UPDATE_INCOMPATIBLE / Signatures do not match
What it means: The APK being installed uses a different signing key than the version already installed on the device.
Most common cause: Attempting to update an app that was previously installed from a different source with a different signing key; lost the original keystore and re-signed with a new one; enroling in Play App Signing and upgrading key.
Fix: Android does not allow updating an app with a different key without uninstalling first. If the keystore is lost and not enrolled in Play App Signing, the package name and all installs must be abandoned. Always back up the keystore. See: Code Signing for Mobile Apps guide.
16. Google Play Protect: This app may have been tampered with
What it means: Google Play Protect detected that the installed APK’s signing certificate doesn’t match the certificate on record from the Play Store for that package name.
Most common cause: User installed an APK from an unofficial source that was re-signed (and likely modified) by a third party.
Fix: This is not a developer-side error to fix. The legitimate app is unaffected. Advise users to install only from the official Google Play Store. File DMCA or abuse reports against unofficial distribution sites. See: Code Tampered or Repackaged guide.
Java JAR Signing Errors
Java’s JAR signing uses jarsigner, a separate tool from Windows Authenticode. These errors appear in Java runtime environments and Java Web Start applications.
17. jarsigner: java.lang.SecurityException: invalid SHA digest for [filename]
What it means: The digest stored in the JAR’s signature manifest doesn’t match the current content of the named file. The file was modified after jarsigner ran.
Most common cause: Bytecode manipulation tool (ProGuard, R8) ran after signing; MANIFEST.MF modified after signing; post-processing script modified class files.
Fix: Apply all bytecode transformations and manifest changes before jarsigner runs; sign the final JAR as the last build step; verify with jarsigner -verify -verbose app.jar. See: Unrecognized File Format guide.
Cloud Signing and Network Errors
These errors appear when using cloud HSM signing services (eSigner, DigiCert KeyLocker, Microsoft Trusted Signing) or when the timestamp server is unreachable.
18. Unable to contact the code signing server / signing service unreachable
What it means: The cloud signing client cannot reach the signing API. The private key operation cannot be performed without network access to the cloud HSM.
Most common cause: Firewall blocking outbound HTTPS to the signing service API; expired API credentials or TOTP secret; VPN routing blocking cloud service access; signing service outage.
Fix: Check service status page first; verify credentials haven’t expired in the provider portal; test API connectivity with curl or Invoke-WebRequest; configure firewall to allow outbound HTTPS to the signing service hostnames. See: Unable to Contact Code Signing Server guide.
19. The timestamp server could not be reached (timestamp operation failed)
What it means: signtool or another signing tool failed to obtain an RFC 3161 timestamp from the specified server.
Most common cause: Firewall blocking outbound HTTP to timestamp server; corporate proxy not configured for signtool’s WinHTTP layer; CI runner without internet access; rate limiting from many rapid timestamp requests.
Fix: Try an alternative timestamp server (timestamp.sectigo.com, timestamp.globalsign.com); configure proxy with netsh winhttp set proxy; for CI runners, allow outbound HTTPS to timestamp server hostnames. See: Unable to Contact Code Signing Server guide.
Build Pipeline and Configuration Errors
These errors are not certificate problems; they are build process problems that result in signing failures. They are increasingly common as signing moves into CI/CD pipelines.
20. Signature verification fails immediately after signing in CI/CD
What it means: The signature was valid at signing time but a subsequent pipeline step modified the signed artifact, breaking the hash.
Most common cause: Post-sign build step (version stamper, resource patcher, packager) modifying the signed binary; signing running in parallel with a build step instead of after it.
Fix: Move the signing step to the absolute end of the pipeline, after all other transformations; nothing should touch the signed artifact between signing and distribution. See: Code Tampered or Repackaged guide and Code Signing for DevOps guide.
21. PFX file not found or cannot be imported (CI/CD pipeline)
What it means: A pipeline script attempting to import a PFX certificate file for signing cannot find or parse the file.
Most common cause: Since June 2023, OV and EV code signing certificates cannot be delivered as PFX files. Pipelines built before this change break when attempting PFX-based signing.
Fix: Migrate to a cloud HSM signing service (eSigner, DigiCert KeyLocker, Microsoft Trusted Signing). Cloud services are the current supported approach for pipeline signing. See: Easy Steps to Get a Code Signing Certificate guide.
2026 Context: Errors That Became More Common After Recent Changes
Two CA/B Forum policy changes increased the frequency of specific code signing errors in 2024, 2025, and 2026:
The June 2023 hardware storage mandate eliminated PFX file delivery for commercially issued OV and EV code signing certificates. Any pipeline that previously imported a PFX certificate now fails at that step. This is the single largest source of new CI/CD signing breakage across the industry, and error #21 above is the direct result.
The March 2026 reduction in maximum certificate validity to approximately 460 days means certificates now expire roughly twice as fast as the previous 39-month maximum. Errors #7 and #9 above will appear more frequently for teams that haven’t updated their certificate renewal and calendar reminder processes to the shorter cycle. A certificate that was purchased on a 3-year term before March 2026 may issue certificates under the new 460-day cap on reissuance; check with your CA.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.