Why would you sign a JAR, and what security property does a signature actually give you?
answer
- integrity + authenticity, NOT secrecy
- private key signs, public cert verifies
- self-signed = consistency only; CA = vetted identity
- per-entry digests → detects tampering
- trust is a separate policy decision
basics
~10 sSigning a JAR attaches a digital signature so you can prove who published it and that nobody changed its files afterward. It gives integrity and authenticity — not secrecy.
solid answer
~50 sSigning a JAR proves two things: integrity (the contents were not modified after signing) and provenance/authenticity (it was published by the holder of a specific private key, identified by a certificate). The signer hashes every entry, stores those digests in a signature file, and signs that file with their private key; the public certificate travels in the JAR so a verifier can check it. Crucially, signing does NOT encrypt anything — anyone can still read the classes; it only detects tampering and identifies the publisher. It establishes trust only as far as you trust the certificate: a self-signed cert proves the same key signed everything but says nothing about real-world identity, whereas a CA-issued cert (or one you have pinned) ties the key to a vetted publisher. Signing underpins features like trusting code from a known vendor and detecting supply-chain tampering of dependencies.
go deeper
Knows signing proves who made the JAR and that it wasn't changed, and that it does not hide/encrypt the code.
Explains integrity vs authenticity, that a private key signs and a public certificate verifies, and that signing is not encryption.
Articulates the trust model (self-signed vs CA vs pinning), per-entry verification, and signing's role in supply-chain integrity and its limits.
Designs an artifact-trust / supply-chain policy: which CAs/pins to trust, key custody, rotation, and how signing fits with reproducible builds and provenance attestation.
## The problem signing solves When you receive a JAR — a dependency, a plugin, a downloaded app — two questions matter: **Has it been altered since it was published? (integrity)** and **Who really published it? (authenticity / provenance)**. A plain JAR answers neither; anyone can edit a ZIP and re-host it. **JAR signing** attaches a verifiable digital signature that answers both. ## The cryptography in plain terms Signing uses **asymmetric (public-key) cryptography**. The publisher holds a **private key** (kept secret) and a matching **public key** wrapped in a **certificate** (a document binding the public key to an identity, e.g. “CN=Acme Corp”). The math property: data the private key signs can be verified by anyone using the public key, but only the private-key holder could have produced that signature. A **cryptographic hash** (e.g. SHA-256) is a one-way function turning any bytes into a short fixed-length **digest**; change one byte and the digest changes completely. This makes digests a fingerprint for detecting modification. ## What the signer does (conceptually) 1. Hash each file in the JAR — producing one digest per entry. 2. Record those digests in a signature-info file. 3. **Sign** that file with the private key, producing a signature block, and embed the public certificate. (The concrete files — `MANIFEST.MF`, a `.SF` file, and a `.RSA`/`.DSA`/`.EC` block under `META-INF/` — are the subject of a separate question.) ## What the verifier gets A verifier recomputes each entry's hash and compares to the signed digests (integrity: unmodified?), then checks the signature against the embedded certificate's public key (authenticity: signed by that key?). If both pass, the JAR is **unchanged since signing** and **signed by the holder of that certificate**. ## The hard part: trust Verification only proves *the same key signed it*. Whether you should *trust that key* is a policy decision: - A **self-signed certificate** (the signer issued their own) proves internal consistency but anyone can mint one claiming any name — it gives no third-party assurance of identity. - A **CA-issued certificate** is signed by a **Certificate Authority** your system already trusts (its root is in a truststore), chaining trust to a vetted identity. - **Pinning** — you record the expected certificate/key out of band and accept only that — works even with self-signed certs in a closed ecosystem. ## What signing does NOT do - It does **not encrypt** — the classes are still readable by anyone; signing is about tamper-detection and identity, not confidentiality. - It does **not** make the code safe or bug-free — it only tells you *who* signed it and that it is *unchanged*. - A valid signature on **part** of a JAR doesn't protect *added* unsigned files — verification is per-entry, so attackers adding new unsigned entries is a known subtlety (handle by treating partially-signed JARs as untrusted). ## Why it matters today Signing is foundational to **supply-chain security**: verifying that a dependency really came from its maintainer and wasn't swapped by a compromised mirror. Legacy applet/Web Start trust models leaned heavily on it; modern uses include signing release artifacts and distribution packages.
- Does signing a JAR make its contents confidential?No. Signing provides integrity and authenticity only. The classes remain fully readable and can be decompiled; if you need confidentiality you must encrypt separately. Signing's job is detecting tampering and identifying the publisher.
- What does a self-signed certificate prove versus a CA-issued one?A self-signed cert proves only that one consistent key signed everything — anyone can create one with any claimed name, so it gives no independent identity assurance. A CA-issued cert chains to a Certificate Authority your truststore already trusts, binding the key to a vetted real-world identity.
A signature is like a wax seal with the sender's crest on a letter: if the seal is intact the letter wasn't opened (integrity) and the crest tells you who sent it (authenticity) — but the letter itself is still in plain language for anyone to read (no secrecy).
saying these in an interview costs you the question
- Claiming signing encrypts or hides the bytecode — it does not; it is tamper-detection plus identity only.
- Treating a valid signature as proof the code is safe/trustworthy — it only proves who signed it and that it is unchanged.
- Assuming a self-signed certificate provides the same trust as a CA-issued one.
- Forgetting that unsigned entries added to an otherwise-signed JAR are not covered by the signature.