Digital Signatures and PKI

A digital signature proves that a specific private key signed a specific message, giving integrity, authenticity, and non-repudiation at once: the recipient knows the content is unaltered and who produced it, and the signer cannot credibly deny it. But a signature only helps if you know the public key really belongs to who you think — and that trust problem is what PKI, certificates and certificate authorities, exists to solve.

This topic connects signing to the certificate chains that make HTTPS trustworthy, so that when your browser shows a padlock for app.meridian.example, you understand exactly what chain of signatures produced that trust.

How Signing Works

The signer combines a hash of the message with their private key to produce the signature; anyone verifies it with the public key, no private key needed. RSA does this by encrypting the hash under the private key and decrypting to verify, which is why the "sign = encrypt with the private key" shorthand is common — but ECDSA and Ed25519 use elliptic-curve math instead of any encrypt/decrypt step, so treat that shorthand as RSA-specific, not the general mechanism. Any change to the message, or a wrong key, makes verification fail. Because only the private-key holder could have produced the signature, the result carries a property a shared-secret MAC cannot: non-repudiation, the signer cannot later disclaim it.

The Trust Problem and Certificates

A public key on its own does not prove identity — anyone can generate a key pair and claim to be Meridian. A certificate solves this by bundling a public key with identity information and a signature from a certificate authority that the relying party already trusts. The certificate is, in effect, a trusted third party vouching: "this public key really belongs to app.meridian.example."

The Chain of Trust

Your browser ships trusting a small set of root CAs. A site's certificate chains up through one or more intermediate certificates to one of those roots, and each link is a signature verifying the next. The browser walks the chain to a trusted root and validates the hostname; break or forge any link and the chain fails. This is exactly what a man-in-the-middle exploits when a client is misconfigured to skip verification.

# fetch and read the certificate app.meridian.example serves
openssl s_client -connect app.meridian.example:443 -servername app.meridian.example </dev/null \
  | openssl x509 -noout -subject -issuer -dates

# subject = who the cert is for, issuer = which CA signed it,
# dates = validity window (an expired cert breaks every client at once)

The command shows the certificate's subject (who it is for), its issuer (the CA that signed it), and its validity dates. Reading these is how you confirm a site presents a genuine certificate chaining to a trusted root — and how you catch the two most common self-inflicted failures: an expired certificate, and a chain that does not reach a root the client trusts.

Revocation and Expiry

Keys get compromised, so certificates expire and can be revoked before expiry through CRLs, OCSP, or simply issuing short-lived certificates. A signature valid yesterday must stop being trusted the moment its certificate is revoked — but that only works if someone actually checks revocation, which is a real operational gap. Automating issuance and renewal, and stapling OCSP, is what keeps revocation from existing on paper only.