JAR & Java Signature Errors: Troubleshooting Guide
Diagnose Java JAR signing and verification failures by tracing the file from its contents and manifest through entry digests, signature files, signer certificate, certificate chain, timestamp, and Java trust.
What a JAR signature error actually means
A JAR signature error means that something in the Java signing or verification path did not meet the expected conditions. The failure can occur while creating the signature, while validating JAR contents, while checking the signer certificate and chain, or while applying Java security and trust rules.
The useful diagnostic model is JAR contents → manifest → entry digests → signature files → certificate → certificate chain → timestamp → Java verification. The certificate and trust stages depend on the certificate chain, while timestamp checks establish signing-time evidence. This separates a damaged or modified JAR from a certificate problem and from a Java runtime trust or algorithm-policy problem.
Identify the failure stage before changing the JAR
Signing
Failures occur while creating the JAR signature.
jarsignercannot find the key- Keystore problems
- Alias problems
- Private-key access
- Certificate problems
JAR integrity
The signature exists, but the JAR no longer matches the signed evidence.
- JAR modified after signing
- Manifest mismatch
- Entry digest mismatch
- Missing signature information
Certificate and trust
The signer can be identified, but certificate validation or trust is failing.
- Certificate expired
- Certificate revoked
- Chain not trusted
- Missing intermediate certificate
Timestamp and Java verification
The signature may be valid while timestamp or runtime security evaluation introduces another failure.
- Timestamp server unavailable
- Timestamp verification failure
jarsigner -verifyerrors- Java security or runtime warnings
How Java verifies a signed JAR
A signed JAR is not validated by checking only the certificate. Java evaluates the relationship between the archive contents, the manifest, the signature metadata, and the signer certificate. Trust is a separate question from whether the cryptographic evidence is internally consistent.
JAR entries
Java reads the archive contents and the metadata associated with the signed entries.
Manifest and entry digests
The manifest records digest information used to detect changes to signed entries.
.SF signature file
The signature file contains signature-related digest information associated with the manifest and signed entries.
Signature block
The signature block contains the cryptographic signature and signer certificate information.
Certificate and chain
Java can inspect the signer certificate and its path toward a trusted certificate authority.
Trust and validity
The Java environment determines whether the signer and certificate path satisfy its trust and security rules.
Key distinction: a JAR can contain a cryptographically valid signature while the signer is still not trusted by a particular Java environment.
“jarsigner: unable to sign jar”
When jarsigner cannot create a signature, begin with the keystore and key entry rather than the JAR contents. The signing operation needs access to a usable private-key entry and the certificate chain associated with that key.
Alias and key
The alias may not exist, may point to a certificate-only entry, or may not identify the intended private key.
Keystore
The keystore may be missing, inaccessible, opened with the wrong password, or interpreted with the wrong keystore type.
Certificate
The key entry may have a certificate mismatch or an incomplete certificate chain needed for signing.
“Alias does not exist”
An alias is the name used to select an entry inside the keystore. A common mistake is checking one keystore while jarsigner is operating against another, or confusing a trusted certificate entry with a private-key entry.
List what is actually there
- Confirm the keystore path.
- Confirm the keystore type.
- Check the exact alias spelling.
- Inspect the entry type.
Private-key entry vs certificate-only entry
A certificate-only trusted entry can be useful for trust, but it cannot provide the private key required to create a JAR signature. Confirm that the intended alias represents a private-key entry.
Also check whether the CI/CD environment is using the same keystore and alias as the local environment.
When the keystore opens locally but signing still fails
Path and password
Check the keystore path, store password, key password, and the account running the command.
JKS vs PKCS#12
Confirm that the command uses the keystore type expected by the file. Do not assume every .jks or .p12 filename tells the whole story.
Private key association
Importing a certificate without its corresponding private key does not create a signing key. Confirm the key and certificate are associated with the intended entry.
Key generation, keystores, keytool, jarsigner, CI/CD, and protected signing keys are covered in the dedicated.
“jarsigner: Certificate chain not found”
This error means the signing operation cannot establish the certificate chain expected for the key entry. The signer certificate can exist in the keystore while the chain remains incomplete.
What to inspect
- Signer certificate issuer
- Available intermediate certificates
- Root certificate
- Certificate entry type
- Certificate path in the active keystore
Why this happens
A certificate may have been imported without the intermediate certificates needed to establish its chain. The local machine may have worked because another environment supplied trust information that the signing environment does not have.
“jar verified” does not always mean “signer trusted everywhere”
Verification results need to be read carefully. A successful cryptographic verification establishes that the signature evidence is consistent with the signed JAR. Certificate validity and trust are additional questions.
Cryptographic verification
- Signature exists
- Signed content matches expected digests
- Signature can be verified
Trust evaluation
- Certificate is valid
- Chain is complete
- Java environment trusts the signer path
Do not collapse these layers. A JAR can pass the cryptographic part of verification while a particular Java runtime still does not trust the signer.
“jar is unsigned”
If Java reports an unsigned JAR, confirm the artifact before troubleshooting certificates. Build systems can generate multiple JARs, packaging can create a replacement artifact, and signature metadata can be removed from an archive.
Common causes
- JAR was never signed.
- Signature files were removed.
- The wrong JAR was verified.
- A build step generated a different artifact.
- Packaging stripped signature metadata.
First inspection
Inspect META-INF in the exact JAR being verified. Look for the manifest and signature-related files, then confirm the verification command targets that same release artifact.
“JAR is signed, but certificate is not trusted”
A signed JAR can fail trust evaluation because the Java environment does not have the required trust anchor, cannot build the certificate chain, or uses a different trust configuration from the environment where the JAR was created. The is to support software integrity and signer identification; it does not make every Java truststore trust the signer automatically.
Trust anchor
Check whether the expected root CA is trusted by the Java environment.
Intermediate
Check whether the chain can be completed through the required intermediate certificate.
Runtime environment
Compare Java truststore configuration, JDK/JRE version, and local or enterprise trust settings.
“Signature is invalid”
An invalid signature often points to a JAR integrity problem rather than a certificate problem. The central question is whether the signed archive still matches the content represented by its digest and signature metadata.
JAR changed
An entry was modified, added, or removed after signing.
Metadata changed
The manifest or signature-related metadata no longer matches the signed evidence.
Packaging changed
A build or packaging tool altered the archive after the signing step.
Core rule: modify and finalize the JAR first. Sign it only after packaging and transformations are complete.
“invalid SHA-256 signature file digest”
A digest error is useful because it points toward a specific layer of the JAR signing structure. The important relationship is JAR entry → manifest digest → .SF metadata → signature block. If the underlying content changes, the expected digest relationship can break.
Before signing
Compile, package, shade, obfuscate, update resources, finalize the manifest, and complete other transformations that are part of producing the final JAR.
After signing
Timestamp, verify, and distribute. Avoid transformations that rewrite the signed archive after the signature is created.
When the digest fails: identify the affected entry or metadata layer first. Re-signing without removing the underlying post-signing modification can simply reproduce the same failure later in the pipeline.
“invalid entry CRC” is not automatically a certificate problem
CRC errors point toward the ZIP/JAR archive layer. They can result from archive corruption, entry modification, packaging problems, or a damaged transfer. Treat this separately from certificate validation until the archive itself has been shown to be intact.
Archive causes
- JAR corruption
- Entry modification
- Broken packaging process
Transfer causes
- Damaged download
- Incomplete file transfer
- Artifact replacement during deployment
Find out which digest layer failed
Entry digest
Points toward a changed or corrupted JAR entry.
Manifest digest
Points toward a mismatch involving manifest content or the data represented by it.
Signature-file digest
Points toward a mismatch between the signature metadata and the manifest evidence it covers.
The goal is to identify the exact layer reported by the verification output. A generic “digest error” does not justify replacing a signing certificate without first checking the archive and signing workflow.
Separate cryptographic, certificate, and trust failures
Cryptographic failure
- Modified JAR
- Wrong signature
- Corrupted signature block
Certificate failure
- Invalid certificate
- Expired certificate
- Revoked certificate
Trust failure
- Untrusted chain
- Missing CA certificate
- Different Java trust configuration
Why this matters: each layer has a different fix. Rebuilding a JAR will not repair a missing trust anchor, and replacing a certificate will not repair a JAR entry modified after signing.
Why JARs fail after a build step changes them
The final JAR must be the artifact that gets signed. Any transformation that changes signed content after the signing operation can break the digest and signature relationships used during verification.
When a signed JAR contains unsigned entries
A signed JAR does not necessarily mean every archive entry was covered in exactly the same way. Build-generated metadata and files introduced during packaging can complicate the result. When jarsigner reports unsigned entries, identify which entries are affected and when they entered the archive.
What to inspect
- Which entries are unsigned?
- Were they generated before or after signing?
- Did a build plugin add them?
- Are they expected metadata or application files?
Why it matters
Files added after signing can change the release artifact and create verification or security-policy issues. The safest workflow is to finalize the entire release JAR before signing and then verify the result.
Multiple signers, signature files, and re-signing
Third-party, legacy, or re-signed JARs can contain more than one signature-related set of metadata. Troubleshooting requires identifying which signer and signature files are present rather than assuming the archive has one signing history.
Multiple signature blocks
Inspect each signer and its associated signature block when several signatures are present.
Multiple .SF files
Each signature file represents a signing identity's metadata. Match it with the corresponding signature block.
Re-signing
Determine whether a previous signature was retained, replaced, or affected by the later signing process.
When results conflict, capture the complete verification output and inspect each certificate, timestamp, and signature-related file before changing the archive.
When JAR signing succeeds but timestamping fails
Timestamping is a distinct operation in the signing workflow. A JAR can receive a cryptographic signature while the timestamp request fails or produces evidence that Java cannot validate. A valid provides evidence of when signing occurred.
Common failures
- TSA unavailable
- TSA URL problem
- Invalid timestamp response
- Timestamp certificate problem
- Timestamp chain problem
- Timestamp algorithm or policy issue
Diagnostic sequence
Can the TSA be reached?
Is the request valid?
Is the response valid?
Can the timestamp certificate be trusted?
Is the timestamp signature valid?
Why timestamping matters: it provides evidence about signing time, which can matter when the signing certificate later reaches the end of its validity period.
Expired JAR signing certificate
Expired before signing
A new signature created with an expired signing certificate is a certificate-validity problem. Use an appropriate active certificate before signing a new release.
Expired after signing
A previously signed JAR can have different historical verification evidence when a valid timestamp establishes when the signature was created. Inspect the timestamp and complete verification result.
Do not use the current certificate expiration date as the only test. Inspect signing time evidence and the Java verification context.
Revoked certificate errors
Revocation means the certificate authority has indicated that the certificate should no longer be trusted for its intended purpose. It is different from ordinary expiration and can be associated with events such as private-key compromise. The also affects how existing signatures should be assessed.
New signing
Do not use a revoked signing certificate for new releases. Investigate the revocation and move to an appropriate replacement certificate.
Existing signed JARs
Review certificate status, timestamp evidence, Java trust configuration, and the complete verification result. Historical signatures require more context than a simple current-status check.
When a signed JAR works on one Java version but not another
Java security behavior can change between releases. A signature that worked in an older JDK/JRE environment may encounter stricter algorithm, key-size, certificate, or security-policy rules in a newer environment. Treat this as a runtime compatibility investigation rather than assuming the JAR itself changed.
Algorithm restrictions
Older or weak algorithms may be restricted or disabled as Java security policies evolve.
Key-size restrictions
Security policy can impose requirements that affect legacy signing keys or certificates.
Runtime differences
JDK/JRE versions, security configuration, and truststores can change verification behavior.
Maintenance note: avoid publishing a permanent list of algorithms as universally accepted. Java security policies evolve, so verify the behavior against the JDK/JRE versions you actually support.
Why JAR signing works locally but fails in CI/CD
A CI runner is a different Java environment, even when it builds the same project. Compare the runtime, keystore, account, secrets, file paths, certificate chain, and timestamp connectivity rather than assuming the signing command itself is wrong. Keep signing credentials isolated and control access to the private key used for signing.
Runtime
- JDK version
JAVA_HOME- Security configuration
Signing inputs
- Keystore path
- Alias
- Password/secret handling
- Keystore type
Environment access
- File permissions
- Certificate chain
- Timestamp connectivity
- Service-account context
Standardize the JDK and signing configuration in CI/CD, keep signing credentials protected, and verify the final JAR in the same controlled workflow that produces the release artifact.
Use jarsigner -verify as an investigation tool
The goal of verification is not simply to obtain a “verified” or “not verified” result. Use verbose output and certificate information to determine which layer failed and what evidence Java is evaluating.
Is the cryptographic evidence consistent?
Start with the verification result and identify any entry or signature failure reported.
Which entry or layer failed?
Use detailed output to locate unsigned entries, digest problems, or other verification evidence.
Who signed it and what is the chain?
Inspect signer certificate information and the certificate path associated with the signature.
Inspect META-INF before guessing at the error
What these files tell you
MANIFEST.MF contains metadata including digest information for signed entries.
SIGNER.SF is the signature file associated with the signer and contains signature-related digest information.
SIGNER.RSA represents a signature block containing the cryptographic signature and certificate information. The extension can differ with the signature block format.
If these files are missing, mismatched, or inconsistent with the JAR contents, investigate the archive and signing process before changing certificate trust settings.
Trace a JAR error from the archive to Java policy
Does the JAR contain signature metadata?
No: confirm the correct artifact and signing step. Yes: continue.
Does jarsigner -verify succeed?
No: inspect the detailed output and identify the first failing layer.
Is an entry digest invalid?
If yes, investigate JAR modification, packaging, or archive corruption.
Is the signature cryptographically valid?
If no, investigate the signature block and archive integrity.
Is the signer certificate valid?
Investigate expiration, revocation, certificate purpose, and signing history.
Is the certificate chain complete?
Check signer, intermediate, root, and the active Java keystore or trust configuration.
Is the chain trusted by this Java environment?
Compare truststores, JDK/JRE versions, and security configuration.
Is timestamp verification valid?
Inspect timestamp evidence and its certificate path.
Are Java security or algorithm restrictions involved?
If the archive is intact and the certificate path is sound, compare the Java versions and security policies involved.
Quick reference for common JAR signature symptoms
| Symptom | Likely layer | First check |
|---|---|---|
| Unable to sign JAR | Keystore / key | Alias, private key, keystore path, password, and entry type. |
| Alias does not exist | Keystore | Available aliases in the active keystore. |
| Keystore password error | Keystore | Password, path, and keystore type. |
| Certificate chain not found | Certificate chain | Signer certificate and required intermediate certificates. |
| JAR is unsigned | Signature | META-INF and the exact artifact being verified. |
| Invalid signature | Integrity | Whether the JAR changed after signing. |
| Invalid entry digest | Manifest / JAR | The affected entry and post-signing build steps. |
| Digest error | Integrity | Manifest and signature metadata relationships. |
| Certificate not trusted | Trust | Java truststore, root, and intermediate certificates. |
| Timestamp failed | TSA | Timestamp configuration, connectivity, and certificate. |
| Verification failed | Multiple layers | Verbose jarsigner -verify output. |
| Works locally, fails in CI | Environment | JDK, keystore, secrets, configuration, and timestamp access. |
Signed JAR, but jarsigner -verify reports an invalid digest
Assume a JAR was signed successfully during the build. The release verification step now reports an invalid digest.
The first question is not whether the signing certificate should be replaced. The first question is whether the JAR being verified is exactly the artifact that was signed.
- Confirm the JAR being verified is the signed artifact.
- Inspect verbose verification output.
- Identify the affected entry or metadata layer.
- Review the build and packaging steps.
- Check for post-signing modification.
- Rebuild the final artifact.
- Sign only after packaging is complete.
- Timestamp the production signature.
- Verify the resulting JAR again.
Prevent common JAR signing failures before release
Artifact discipline
- Use the final JAR for signing.
- Do not modify the JAR after signing.
- Keep build transformations before signing.
- Verify the final artifact.
Signing discipline
- Protect the signing key.
- Maintain the certificate chain.
- Use appropriate algorithms.
- Timestamp production signatures.
Environment discipline
- Standardize JDK versions in CI/CD.
- Secure keystore secrets.
- Verify certificate and trust configuration.
- Maintain a secure signing-key recovery process.
Frequently asked JAR signature questions
Why does jarsigner say the JAR is not verified?
Inspect the detailed verification output. The problem may be an invalid digest, modified entry, broken signature, certificate issue, chain problem, timestamp issue, or Java security restriction.
Why is my JAR signature invalid?
First check whether the JAR changed after signing. Repackaging, adding or removing entries, manifest changes, shading, obfuscation, or other post-signing processing can invalidate the signed evidence.
Why does jarsigner report an invalid SHA-256 digest?
Identify the affected digest layer and entry. A changed entry or modified manifest/signature metadata can create a digest mismatch. Sign only after the final JAR has been produced.
Why does my signed JAR work on one Java version but not another?
Compare JDK/JRE versions, security configuration, truststores, algorithm restrictions, key-size requirements, and the certificate chain. Java security policies can evolve between releases.
Why is my JAR certificate not trusted?
Check the Java trust configuration, root certificate, intermediate certificates, and the exact JDK/JRE environment performing verification.
Why does jarsigner say the certificate chain is not found?
The signer certificate may exist without the intermediate certificates needed to build its chain. Inspect the key entry and certificate path in the active keystore.
Can I modify a JAR after signing it?
Do not modify the final signed JAR as part of the normal release process. Changes to signed content can invalidate the digest and signature relationships.
Why did timestamping fail?
Check TSA connectivity, the timestamp request and response, timestamp certificate validation, chain trust, and any Java security or algorithm restrictions involved.
What happens when a JAR signing certificate expires?
Separate a certificate that was already expired when signing from one that expired after signing. A valid timestamp can provide signing-time evidence, so inspect the timestamp and complete Java verification result.
How do I verify a JAR signature?
Use jarsigner -verify, preferably with detailed output such as -verbose -certs, to inspect the signature, affected entries, signer certificate, and certificate information.
Why does JAR signing work locally but fail in CI/CD?
Compare the JDK version, JAVA_HOME, keystore path and type, alias, secrets, permissions, certificate chain, security configuration, and timestamp connectivity.
Continue with the right Java signing guide
Keep these topics separate so each page addresses a distinct search intent instead of repeating the same JAR signing explanation.
Find the failing layer before rebuilding the JAR
JAR signature troubleshooting is faster when archive integrity, signature evidence, certificate validation, trust, timestamping, and Java security policy are investigated as separate layers.
Explore Java Code Signing Certificates