Digital Signatures, Certificates & PKI¶

How do you trust that a public key really belongs to who it claims? Enter PKI — Public Key Infrastructure.

Digital Signatures¶

A digital signature provides authentication, integrity, and non-repudiation.

Sign: signature = encrypt(hash(message), PRIVATE key) Verify: hash(message) == decrypt(signature, PUBLIC key)

• Only the holder of the private key could have produced the signature.
• Any change to the message breaks verification.
• The signer cannot later deny signing (non-repudiation).

Certificates¶

A digital certificate (X.509) binds a public key to an identity (e.g., a domain name) and is signed by a trusted Certificate Authority (CA).

A certificate contains:

• Subject (who it's for, e.g., example.com)
• Public key
• Issuer (the CA)
• Validity period
• The CA's digital signature

The Chain of Trust¶

Root CA (self-signed, in your OS/browser trust store) │ signs Intermediate CA │ signs Server certificate (example.com)

Your browser trusts the root CA out of the box. Because trust flows down the chain, it can verify example.com without ever having seen it before. If any link fails verification, you get a certificate warning.

Certificate Lifecycle¶

Let's Encrypt + tools like certbot make TLS certificates free and automatable. There's no excuse for plain HTTP today.

Common Real-World Failures¶

1. 1.Expired certificates — causes outages; monitor expiry.
2. 2.Self-signed certs in production — users get trained to click through warnings (dangerous).
3. 3.Weak key storage — a leaked private key compromises everything it protects.
4. 4.Mixed content — HTTPS page loading HTTP resources breaks the security guarantee.

Mutual TLS (mTLS)¶

In high-security and zero-trust environments, both client and server present certificates — strong, mutual authentication used heavily between microservices.