How to Sign Java JAR Files
Follow a practical JAR signing process from the final archive through keystore preparation, keytool, jarsigner, timestamping, verification, inspection, Java runtime testing, and release.
Core workflow: Build JAR → test JAR → prepare keystore → inspect alias → sign → timestamp → verify → inspect → test → distribute.
JAR Signing Requirements at a Glance
Start with the actual signing inputs. You need the final .jar, a Java JDK, a signing key and certificate in a keystore, the key alias, the certificate chain, and access to keytool and jarsigner. Add a timestamp service when your release process requires timestamped signatures.
.jar filekeytool and jarsignerThe private key performs the signature. The certificate identifies the signer. A certificate-only entry cannot replace the private-key entry required for signing.
Check the JAR Before Signing
Build the final JAR, run its tests, confirm the expected classes and resources are present, and make sure no process will modify the archive after signing. JAR signing belongs after packaging, not before it.
A JAR is an archive, so changing a class, adding a resource, removing an entry, changing manifest-related content, or repackaging the archive after signing can cause verification failures.
Choose the Java Keystore and Signing Key
The signing key is normally held in a Java keystore. Common formats include JKS and PKCS#12. The selected alias must identify the private-key entry used for signing and its certificate chain.
Do not confuse a private-key entry with a trusted-certificate entry. The certificate identifies the signer, while the private key performs the cryptographic signing operation.
Create or Import the Signing Key
If you already have a signing key and certificate, make sure they are correctly associated with the keystore alias. If you need a new identity, the high-level process is: generate keypair → create CSR → certificate issuance → import certificate and chain → sign the JAR.
The certificate-issuance process is separate from signing the JAR. Before associating the issued certificate chain with the private-key alias, confirm that the certificate is appropriate for the intended publisher and distribution model.
Inspect the Keystore Before Signing
Use keytool to confirm the alias, entry type, certificate subject, issuer, validity, and certificate chain before using jarsigner. This catches the common mistake of selecting an alias that does not contain the expected private signing key.
Use the verbose keystore listing to inspect the actual entry rather than assuming that an alias name alone proves the correct signing key is available.
Sign the JAR With jarsigner
jarsigner is the Java tool used to sign a JAR. Specify the keystore, keystore type when needed, final JAR, and signing alias. Passwords should be supplied through the approved credential mechanism in automated environments.
The signing operation creates signature metadata inside the archive. The JAR being signed should be the final artifact that will be distributed.
Understand What jarsigner Adds to the JAR
JAR signing creates signature-related files under META-INF/. The manifest contains entry digest information, a signature file such as .SF records signing metadata, and a signature block such as .RSA, .DSA, or .EC contains the cryptographic signature and signer certificate information.
Inspecting META-INF is useful when troubleshooting a JAR that appears signed but fails verification or contains unexpected unsigned entries.
Add a Trusted Timestamp
Timestamp the production JAR when your release process requires trusted signing-time evidence. The timestamp records signing-time evidence separately from the signer certificate’s validity period; the broader mechanics are covered by the code signing timestamping process. jarsigner supports timestamping through a timestamp authority URL.
Use your approved timestamp service in place of TIMESTAMP_URL. If timestamping is mandatory and the service fails, treat that according to the release policy rather than silently publishing an artifact without the required evidence.
Verify the Signed JAR
Use jarsigner -verify as the primary verification workflow. Check that the signed entries have not changed and inspect the signer certificate, chain, timestamp information, warnings, and unsigned entries.
A successful cryptographic verification is not the same as universal Java trust. The consuming runtime can have its own truststore, provider configuration, security properties, and algorithm restrictions.
Read the Verification Output
Read the verification output instead of looking only for a success message. Pay attention to certificate-chain warnings, disabled or weak algorithms, timestamp information, unsigned entries, and verification failures.
The goal is to understand what jarsigner is telling you about the archive and its signing environment, not simply to confirm that the command executed.
Inspect a Signed JAR
Inspect the archive and its META-INF contents when auditing or troubleshooting a release. Confirm MANIFEST.MF, the signature files, signature block, signer certificate, signed entries, unsigned entries, and timestamp information.
Use jar tf to inspect the archive and jarsigner -verify -verbose -certs to inspect signing information.
Do Not Modify a Signed JAR
Make every JAR change before signing. Replacing a class, adding a resource, removing an entry, changing manifest-related content, or running a packaging step that rewrites the archive can invalidate the signature.
Practical rule: build → test → package final JAR → sign → timestamp → verify → publish. If the archive changes after signing, sign the resulting final archive again.
Understand Signed and Unsigned Entries
A JAR can contain entries that are not covered by a signer. Therefore, the existence of signature files under META-INF does not by itself prove that every entry is signed.
Use verbose verification to identify unsigned entries and decide whether the consuming application and release policy permit them.
Handle Multiple Signers in One JAR
A JAR can contain signature artifacts from more than one signer. Multiple identities should only be used when the release process defines why each signer is present and how the consuming environment should interpret them.
During verification, identify the expected signer identities rather than treating any additional signature as automatically acceptable.
Separate JAR Signature From Java Trust
Keep three questions separate: is the JAR signature valid, which certificate identifies the signer, and does the Java environment trust the relevant certificate chain?
A signed JAR is not automatically trusted by every Java installation. Truststores, security properties, providers, certificate chains, and disabled algorithms can differ between environments.
Sign JARs Built With Maven or Gradle
For Maven or Gradle releases, signing belongs after compilation, testing, and creation of the final JAR. Do not sign intermediate artifacts that the build lifecycle will later rewrite.
Keep signing credentials outside source control. The release sequence is compile → test → package → sign → timestamp → verify → publish.
Sign JARs in CI/CD
Automated signing should be a controlled release step. The build creates the final artifact, a protected signing environment performs the private-key operation, and verification acts as a release gate.
Protect keystores and signing credentials, restrict signing-agent access, use HSM or approved remote signing where required, record signing results, and publish only the artifact that passed verification.
Sign a JAR With an HSM
An HSM changes where the private key is stored and how the cryptographic operation is performed. The JAR remains the artifact being signed, while the private key remains protected by the HSM access controls.
The exact Java integration depends on the cryptographic provider and HSM configuration. Do not turn a protected production key into an ordinary downloadable file merely to simplify automation.
Sign a JAR With a PKCS#11 Token or Provider
Java can access token-backed keys through a PKCS#11 provider. The implementation requires the provider configuration, access to the token or HSM, key discovery, and the Java runtime configuration needed by the provider.
Keep the private key in the token or protected device when non-exportability is part of the security design.
Choose a Signing Certificate for Java Releases
For distributed Java software, choose a signing identity that matches your publisher and release requirements. Confirm the certificate, private-key custody, and Java signing workflow before signing production archives.
JAR Signing Commands and Options
These commands form the practical sequence. Replace the example filenames, alias, keystore, and timestamp URL with the values from your release environment.
keytool -list -v -keystore signing.p12 -storetype PKCS12
jarsigner -keystore signing.p12 -storetype PKCS12 "my-application.jar" jar-signing
jarsigner -keystore signing.p12 -storetype PKCS12 -tsa "TIMESTAMP_URL" "my-application.jar" jar-signing
jarsigner -verify -verbose -certs "my-application.jar"
jar tf "my-application.jar" | grep META-INF
Release gate: verify the exact JAR that will be published. Do not sign one archive and distribute a different rebuilt or repackaged copy.
Common JAR Signing Errors and First Checks
| Problem | First area to investigate |
|---|---|
| Alias does not exist | Wrong alias or wrong keystore. |
| Private key entry not found | Alias points to a certificate-only/trusted-certificate entry. |
| Keystore password error | Credentials or selected keystore. |
| Cannot recover key | Key password, provider, or key-entry configuration. |
| Unable to sign | Private-key access or cryptographic-provider problem. |
| Certificate chain not found | Certificate/intermediate chain import. |
| JAR verification failed | Archive changed after signing or signature artifacts no longer match. |
| Invalid signature | Signed content or signature artifacts are inconsistent. |
| Unsigned entries | Some archive entries are not covered by the signer. |
| Timestamp failed | Timestamp service, network, or configuration. |
| Certificate not trusted | Java truststore and certificate-chain configuration. |
Why Does jarsigner -verify Say the JAR Is Invalid?
Start with the archive itself. A verification failure does not automatically mean the original signing command was wrong. The JAR may have changed after signing or its signature artifacts may no longer match its content.
Look for replaced classes, added resources, repackaging, manifest changes, missing signature artifacts, certificate-chain problems, disabled algorithms, or timestamping issues.
Why Does the JAR Verify on One Java Installation but Not Another?
Compare the Java environments before changing the JAR. Java installations can differ in security properties, truststores, providers, algorithm restrictions, and runtime versions.
| Check | Java A | Java B |
|---|---|---|
| Java version | ||
| Security properties | ||
| Disabled algorithms | ||
| Truststore | ||
| Root/intermediate certificates | ||
| Provider configuration | ||
| Keystore format | ||
| Signature algorithms |
Protect Signing Keys Used in Automated Builds
When JAR signing runs in CI/CD, keep signing credentials outside source control and restrict who can request signatures. Teams with hardware-backed key requirements can evaluate an HSM-based signing setup for production releases.
End to End JAR Signing Example
Use my-application.jar as the final release artifact. Follow this sequence without modifying the archive after signing.
jarsigner -keystore signing.p12 -storetype PKCS12 -tsa "TIMESTAMP_URL" "my-application.jar" jar-signing
jarsigner -verify -verbose -certs "my-application.jar"
jar tf "my-application.jar" | grep META-INF
Final JAR Release Checklist
jarsigner -verify passesRelated Java Signing Workflows
This page is the hands-on JAR signing recipe. Use related resources for broader Java signing concepts and dedicated troubleshooting.
JAR Signing Questions Answered
What tools do I need to sign a Java JAR?
You need a JDK with keytool and jarsigner, the final JAR, a signing key and certificate in a usable keystore, the correct alias, and a timestamp service when required.
How do I inspect a Java keystore before signing?
Use keytool -list -v and inspect the alias, entry type, certificate subject, issuer, validity, and certificate chain.
What does jarsigner add to a JAR?
It creates signature-related artifacts under META-INF/, including manifest digest information, a signature file such as .SF, and a signature block such as .RSA, .DSA, or .EC.
How do I verify a signed JAR?
Use jarsigner -verify -verbose -certs and inspect the result, signer certificate, chain, unsigned entries, warnings, and timestamp information.
Can I modify a JAR after signing?
Treat the signed JAR as final. Changing or repackaging signed content can cause verification failures. Make all changes first and sign the final archive again.
Does a signed JAR automatically work in every Java environment?
No. Java trust configuration, security properties, providers, runtime versions, and disabled algorithms can differ between installations.
Can a JAR have multiple signers?
Yes. Multiple signature artifacts can exist, but the release process should define which signer identities are expected and why they are present.
Sign the Final JAR, Then Verify the Exact Artifact
The practical lifecycle is to finalize and test the JAR, inspect the keystore and alias, sign with jarsigner, timestamp when required, verify with jarsigner -verify, inspect the signer and archive, test in the target Java environment, and publish the exact JAR that passed those checks.