What you'll learn

  1. Quick answer
  2. The Core Trick: Sign With Private, Verify With Public
  3. Hashing First: Why Not Sign the Raw Message?
  4. Proving It With Real Code
  5. What a Certificate Actually Contains
  6. The Chain of Trust, Root to Leaf
  7. What This Does and Does Not Prove
  8. FAQ

Quick Answer

A digital signature is created by hashing a message and encrypting that hash with a private key that only the signer holds; anyone with the matching public key can decrypt the hash and compare it to their own hash of the message to verify both that the signer produced it and that not one bit of it has changed. A certificate applies that same mechanism to identity: a Certificate Authority signs a statement that a given public key belongs to a given subject, and that signature is trusted only because the verifier trusts the CA's own key, forming a chain that ends at a small set of root keys.

The Core Trick: Sign With Private, Verify With Public

Asymmetric cryptography gives you a mathematically linked pair of keys — a private key, kept secret, and a public key, shared freely — where operations done with one can be checked or undone only with the other. Encryption for confidentiality uses this one way: encrypt with the recipient's public key, and only their private key can decrypt it. Digital signatures use the exact same key pair in the other direction: the signer uses their own private key to produce a signature, and anyone can use the signer's public key to check it.

That direction matters. Only the person holding that specific private key could have produced a signature that checks out against the matching public key, which is what makes a valid signature proof of authorship. It's important to be precise about what that proves, though: a signature proves the message came from whoever controls that private key, and that the message hasn't changed since it was signed. It does not, on its own, prove who that someone actually is in the real world — that identity question is a separate problem, and it's what certificates exist to solve, covered further down.

A signature also doesn't hide anything. Anyone can read the signed message in plain text; the signature is extra data attached alongside it, not a replacement for it.

Hashing First: Why Not Sign the Raw Message?

The actual math behind RSA signing (modular exponentiation using the private key) only operates efficiently on numbers up to roughly the key size — a few hundred bytes for a 2048-bit key — while real messages can be arbitrarily large. So in practice, the signer doesn't run the signing operation over the whole message; they first hash it down to a small, fixed-size fingerprint (SHA-256 produces 32 bytes, regardless of whether the input was one character or one gigabyte), and it's that hash which actually gets signed.

Verification mirrors this exactly: the verifier independently recomputes the hash of whatever message they actually received, then checks the signature against that freshly-computed hash. A cryptographic hash function's defining property, the avalanche effect, means changing even a single bit of the input produces a completely different, unrelated-looking hash — so if the message was altered by even one byte since signing, the verifier's recomputed hash won't match what the signature was actually made for, and verification fails outright.

One more detail worth naming honestly: real systems don't sign the raw hash with textbook RSA either, because naive RSA signatures have known mathematical weaknesses that matter for security proofs. The demo below uses RSA-PSS (Probabilistic Signature Scheme), the padding scheme modern libraries default to specifically because it avoids those weaknesses.

Proving It With Real Code

Using Python's cryptography library — no shortcuts, no simulated output:

private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
public_key = private_key.public_key()

message = b"Transfer INR 5000 to account 1234567890 on 2026-09-30"
signature = private_key.sign(
    message,
    padding.PSS(mgf=padding.MGF1(hashes.SHA256()), salt_length=padding.PSS.MAX_LENGTH),
    hashes.SHA256(),
)

public_key.verify(signature, message, ...)   # succeeds

Actual output from running this: a real 2048-bit key pair generated; a 256-byte signature (2048 bits / 8); verification of the unmodified message against that signature: SUCCESS.

Then the tamper test — flipping a single byte of the message (index 9, changing 'I' to 'H,' so 'Transfer INR 5000...' becomes 'Transfer HNR 5000...') and re-running verification against the original signature: FAILED, with the library raising InvalidSignature exactly as expected. A signature made by a completely different, unrelated private key over the same original message also fails verification against the real public key. Both failures are the actual, observed behavior of the library, not a description of what should happen.

What a Certificate Actually Contains

A certificate is the exact same signing mechanism applied to a specific kind of message: a structured statement about identity, rather than free text. A standard X.509 certificate bundles together a subject (who or what the certificate is about, typically a domain name), an issuer (which Certificate Authority is vouching for it), the subject's public key, a validity period (a not-before and not-after date), a serial number, and, crucially, a signature computed by the issuer's private key over all of those other fields together.

That last field is doing exactly the same job as the signature in the code above, just over a certificate's structured fields instead of a plain-text message: it proves that the specific CA identified as the issuer actually vouched for exactly this subject-to-public-key binding, at exactly this content, and that none of it has been altered since the CA signed it.

The Chain of Trust, Root to Leaf

If every website's certificate had to be signed directly by a root CA's key, that root key would be in constant, everyday use — and everyday use is exactly what you don't want for the single most valuable key in the entire system, since anyone who ever steals it can forge a trusted certificate for anything. So CAs use intermediates instead: a root signs an intermediate CA's public key, creating an intermediate certificate, and that intermediate does the day-to-day signing of actual websites' ('leaf') certificates, letting the root key stay offline in a vault almost all the time.

A minimal version of exactly this, built and actually run: a root key pair, an intermediate key pair, and a leaf key pair. The root signs the intermediate's public key bytes; the intermediate signs the leaf's public key bytes. A verifier that only trusts the root's public key walks the chain two steps: does the root's signature check out over the intermediate's public key? Does the intermediate's signature check out over the leaf's public key? Real output: both steps verified True — the chain is trusted end-to-end from root to leaf.

Then the attack test: substitute an attacker's own public key in place of the real leaf's key, and re-check the intermediate's signature against it. Real result: False. The intermediate's signature was mathematically computed over the exact bytes of the original leaf public key — it isn't a generic stamp of approval, it's bound to that specific data — so an attacker cannot produce a signature that validates over a substituted key without also having the intermediate's private key, which they don't have.

This is exactly why a browser or operating system only needs to ship a small, carefully curated list of root public keys (the 'root store'). Trusting a handful of roots extends transitively to every certificate chain that can be walked back to one of them, which is a vastly smaller trust problem than trying to individually vet every website's certificate directly.

What This Does and Does Not Prove

A valid chain of signatures proves something precise: that a specific CA vouched for a specific public-key-to-subject binding, and that neither the certificate nor the chain has been tampered with since it was signed. It proves exactly what the CA's own issuance process actually checked, nothing more, and CAs check very different amounts.

A domain-validated (DV) certificate, the overwhelming majority issued today, many for free, only requires proving control of the domain via a DNS record or an HTTP challenge, a process that can complete in minutes and checks nothing about who is actually behind the domain. An extended-validation (EV) certificate requires substantially more paperwork verifying the legal entity involved. Both are cryptographically identical in terms of the math this article just demonstrated — the difference is entirely in what was checked before the CA's private key touched the signature.

That's precisely why a certificate can be perfectly valid and fully verifiable and still be held by a phishing site: the cryptography is airtight, exactly as shown above, but it only proves what was actually checked at issuance, not the intent of whoever requested it. Airtight math and trustworthy intent are two different questions, and only one of them is what a signature chain can actually answer.

Frequently Asked Questions

Can a digital signature be forged without the private key? Not with correctly-implemented current algorithms at recommended key sizes, such as RSA-2048 or equivalent ECDSA. Forging one would require either a fundamental mathematical break, the kind large-scale quantum computers running Shor's algorithm could eventually pose against RSA and ECC, which is why post-quantum signature schemes are being standardized now, or the private key itself leaking.
What's the actual difference between encrypting a message and signing one? Encryption keeps a message secret from everyone except the intended recipient: encrypt with their public key, only their private key decrypts. Signing proves authorship and integrity to anyone: sign with your own private key, anyone with your public key can verify. They use the same kind of key pair for two genuinely different, and often combined, purposes.
Why do certificates expire instead of lasting forever? Expiration limits the damage window if a private key is ever later compromised or if a CA's original vetting turns out to have been wrong, and it forces periodic re-verification instead of trusting a years-old check indefinitely.
What would happen if a root CA's private key were ever stolen? It would be catastrophic: every certificate chain under that root would become forgeable by whoever holds the stolen key. Browser and OS vendors would need to remove that root from their trust stores entirely, which is exactly why root keys are kept offline in hardware security modules rather than on internet-connected servers.
Is a self-signed certificate cryptographically different from a CA-issued one? No, the signing and verification math is identical either way. The difference is entirely about trust: nobody's root store lists a random self-signed key as a trusted root, so nothing outside systems that manually install that specific certificate will trust the chain.
Can two different messages ever produce a signature that verifies as valid for both? Practically no, given the collision resistance of SHA-256, since finding two different inputs with the same hash is computationally infeasible with current technology, and RSA-PSS's randomized salting further hardens against certain structural attacks that older, non-randomized signature schemes were vulnerable to.