How JAR signing works
A signed JAR stores a digest of every entry in META-INF/MANIFEST.MF. Each signer adds a signature file (NAME.SF) holding digests of the whole manifest, its main attributes and each manifest section, plus a PKCS#7 block (NAME.RSA, .DSA or .EC) that signs the .SF bytes. Verification walks the chain in reverse. This auditor recomputes every digest from the exact bytes, verifies RSA and ECDSA signatures with Web Crypto, and reports where the chain breaks.
Unsigned, tampered and injected entries
An entry is signed only when its manifest digest matches its contents and the signer’s .SF covers its manifest section. A changed class breaks the first link; a class added after signing has no manifest digest at all. Both make the JAR partially signed, which is why jarsigner warns about unsigned entries and why mixed trust can be dangerous.
Manifest pitfalls and sealing
Manifest lines are limited to 72 bytes with single-space continuation lines, and Java silently drops a last line that lacks a newline—a common reason a Main-Class or Class-Path is ignored. A sealed package (Sealed: true in the main section or a Name: com/example/pkg/ section) must load all its classes from one JAR; the auditor shows the effective sealing per package and flags non-directory names, invalid values and sealed packages with no classes.
Structure versus trust
A valid signature proves integrity, not trustworthiness. This tool does not build or validate certificate chains, check revocation or trust stores, validate RFC 3161 timestamp tokens, apply your JDK’s disabled-algorithm policy, open nested JARs, or execute anything. Use jarsigner -verify -verbose -certs with your JDK and trust store for the authoritative decision.
Frequently asked questions
What does jarsigner check when it verifies a JAR?
That the signature block signs the .SF file, that the .SF digests match the manifest (whole or per section), and that each entry matches its manifest digest. Entries missing from that chain are unsigned.
Does a valid signature mean the JAR is trustworthy?
No. It proves the signed entries have not changed since they were signed with the embedded certificate. Trust requires validating the certificate chain, revocation and timestamp against a trust store.
Why is a SHA-1 signed JAR reported as weak?
Current JDKs treat JARs signed with SHA-1 as unsigned unless they carry a timestamp from before 2019. Re-sign with SHA-256 or stronger.
Is my JAR uploaded?
No. The archive is read, hashed and verified in a Web Worker in your browser, and no code is executed.
Authoritative references
Oracle’s JAR File Specification defines the manifest, signature files, signed JAR verification and package sealing; the jarsigner reference documents signing and verification behaviour.
Browse developer tools · Audit a Python wheel · Audit APK signing continuity