How Digital Certificates Work

Encryption alone doesn't protect you from a clever attacker. Even if your data is scrambled, how do you know you're talking to the real server and not an impersonator? This is the problem that digital certificates solve.

1. The Problem: The Man in the Middle

Without certificates, an attacker can intercept your connection and pretend to be the server:

Without certificates:
  You ──────────────────────────────────────────► Real Google?
         ↑
  Attacker inserts themselves:
  You ──► Attacker (poses as google.com) ──────► Real Google
              │
              Attacker reads all your messages, even encrypted ones
              because YOU encrypted to the ATTACKER's key, not Google's!

Certificates prevent this by binding a public key to a verified identity.

2. What Is a Digital Certificate?

A certificate is a digitally signed document that asserts:

┌──────────────────────────────────────────────────────────────┐
│  CERTIFICATE CONTENTS                                        │
├──────────────────────────────────────────────────────────────┤
│  Subject (who):    nandhoo.com                              │
│  Issuer (by whom): Let's Encrypt Authority X3                │
│  Valid from:       2025-01-01                                │
│  Valid until:      2025-04-01 (Let's Encrypt = 90 days)      │
│  Public key:       [2048-bit RSA key block...]               │
│  Subject Alt Names: nandhoo.com, www.nandhoo.com           │
│  Key Usage:        Digital Signature, Key Encipherment       │
├──────────────────────────────────────────────────────────────┤
│  SIGNATURE                                                   │
│  Signed by Let's Encrypt's private key                        │
│  → Anyone with Let's Encrypt's public key can verify this    │
└──────────────────────────────────────────────────────────────┘

The certificate is like a passport — issued by a trusted authority (CA), tied to a specific identity, with an expiry date, and signed so it cannot be forged.

3. The Chain of Trust

Browsers don't trust every certificate blindly. They trust a small set of Root Certificate Authorities whose root certificates are pre-installed in the operating system and browser.

Root CA (e.g. ISRG Root X1)
    │ Issues certificate to ↓
    ▼
Intermediate CA (e.g. Let's Encrypt E5)
    │ Issues certificate to ↓
    ▼
End-Entity Certificate (nandhoo.com)

Why not sign site certificates directly with the root?

Root CAs keep their private keys offline in hardware security modules (HSMs) in vaults
Intermediate CAs do the day-to-day signing and can be revoked if compromised
If an intermediate CA is compromised, only its issued certificates are at risk — the root is safe

Your browser checks the chain upward until it reaches a trusted root. If any link is broken, missing, or untrusted, you get a security warning.

4. Domain Validation — How Do CAs Verify You Own a Domain?

Before issuing a certificate, the CA must verify you actually control nandhoo.com. There are several verification methods:

DV — Domain Validation (most common)

The CA verifies you control the domain. No identity check on who you are.

Three ways to prove domain control:

HTTP challenge: Place a specific file at http://nandhoo.com/.well-known/acme-challenge/TOKEN
DNS challenge: Add a specific TXT record to your domain's DNS: _acme-challenge.nandhoo.com. TXT "TOKEN_VALUE"
Email challenge: Click a link sent to admin@nandhoo.com or webmaster@nandhoo.com

# Let's Encrypt HTTP challenge (certbot)
certbot certonly --webroot -w /var/www/html -d nandhoo.com

# Let's Encrypt DNS challenge (wildcard certs require DNS)
certbot certonly --dns-route53 -d '*.nandhoo.com'

OV — Organisation Validation

The CA verifies both domain control AND that the organisation is real (checks business registry records). Shown as the company name in the certificate.

EV — Extended Validation

The most thorough check — physical address, legal existence, phone number verified. Historically showed a green bar with the company name in browsers. Most browsers now show the same padlock as DV.

5. Certificate Revocation

What if a certificate is compromised before it expires? The CA can revoke it.

Browsers check revocation via:

CRL (Certificate Revocation List)

A periodically published list of revoked serial numbers. Browsers download it and check against it.

https://crl.letsencrypt.org/isrg-root-x1.crl

Downside: Lists grow large and are only updated periodically.

OCSP (Online Certificate Status Protocol)

Real-time query: "Is certificate #12345 still valid?"

Client → GET /check HTTP/1.1
         Host: ocsp.comodoca.com
         [certificate serial number]

Server → {"status":"good"}   or   {"status":"revoked"}

OCSP Stapling

The server pre-fetches its own OCSP status and attaches (staples) it to the TLS handshake, so the browser doesn't need to make a separate OCSP request.

Normal OCSP:
  Browser ─── TLS handshake ──────────────────────────► Server
  Browser ─── OCSP check ─────────────────────────────► CA's OCSP server
  (extra round-trip = slower)

OCSP Stapling:
  Server periodically ─── OCSP check ─────────────────► CA's OCSP server
                        └─ Attaches response to TLS handshake

  Browser ─── TLS handshake (includes OCSP response) ─► Server
  (no extra round-trip = faster, and more private)

6. Wildcard Certificates

A wildcard certificate covers a domain and all its direct subdomains:

*.nandhoo.com covers:
  www.nandhoo.com      ✅
  api.nandhoo.com      ✅
  cdn.nandhoo.com      ✅
  mail.nandhoo.com     ✅
  nandhoo.com          ❌ (wildcard doesn't cover the apex domain)
  a.b.nandhoo.com      ❌ (only one level of wildcard)

Wildcard certificates require DNS validation (HTTP challenge can only validate one specific domain).

7. The Public Key Infrastructure (PKI)

The entire ecosystem of certificates, CAs, standards, and browsers is called PKI:

┌──────────────────────────────────────────────────────────────────┐
│  PUBLIC KEY INFRASTRUCTURE (PKI)                                │
│                                                                  │
│  Root Store                                                      │
│  (Pre-installed in OS/browser)                                   │
│    DigiCert, Comodo, Let's Encrypt (ISRG), Amazon, Microsoft...  │
│                                          │                       │
│                            Signs ↓      │ Trusted ↑             │
│                                          │                       │
│  Intermediate CAs                        │                       │
│    Let's Encrypt E5, DigiCert TLS RSA... │                       │
│                                          │                       │
│                            Signs ↓      │                       │
│                                          │                       │
│  End-Entity Certificates (your site)                             │
│    nandhoo.com, api.nandhoo.com...                             │
└──────────────────────────────────────────────────────────────────┘

8. Reading a Real Certificate

In Chrome:

Click the padlock → Connection is secure → Certificate is valid
Inspect the Details tab

Key fields to understand:

Field	Meaning
Subject	Who the certificate is for (domain/org)
Issuer	Which CA signed this certificate
Valid to	Expiry date
Public Key	The public key (RSA or ECDSA) and bit length
Subject Alternative Names	All domains this cert covers
Signature Algorithm	How the CA sign this cert (e.g. sha256WithRSAEncryption)
Serial Number	Unique ID — used for revocation

9. Reading a Certificate from the Command Line

# View a site's certificate
openssl s_client -connect nandhoo.com:443 2>/dev/null | openssl x509 -text -noout

# Key output sections:
# Subject: CN=nandhoo.com
# Issuer: CN=Let's Encrypt E5
# Validity: Not Before / Not After
# Subject Alternative Names (SANs)
# Public Key Algorithm: id-ecPublicKey (ECDSA) or rsaEncryption (RSA)

# Check certificate expiry quickly
echo | openssl s_client -connect nandhoo.com:443 2>/dev/null \
     | openssl x509 -noout -dates
# notBefore=Jan  1 00:00:00 2025 GMT
# notAfter= Apr  1 00:00:00 2025 GMT

10. Certificate Pinning

Some high-security apps pin a specific certificate or public key — they refuse to connect unless the server presents exactly that certificate.

// Service workers can implement pinning
self.addEventListener('fetch', event => {
  event.respondWith(
    fetch(event.request).then(response => {
      // In a real implementation, check the certificate details
      // Usually done at the native app level (iOS, Android)
      return response;
    })
  );
});

Certificate pinning is common in mobile banking and high-security apps. The downside: if the certificate changes (e.g. on renewal), the app breaks until updated.

11. What Happens When Something Goes Wrong

Expired Certificate

Your connection is not private
Attackers might be trying to steal your information from nandhoo.com.

NET::ERR_CERT_DATE_INVALID

Self-Signed Certificate (Not Trusted by Any CA)

NET::ERR_CERT_AUTHORITY_INVALID

A certificate you generated yourself with openssl — fine for local development, never for production.

Domain Mismatch

NET::ERR_CERT_COMMON_NAME_INVALID

The certificate is for otherdomain.com, but you're visiting nandhoo.com.

Revoked Certificate

NET::ERR_CERT_REVOKED

The CA has explicitly revoked this certificate (compromise or policy violation).

12. Self-Signed Certs for Local Development

# Generate a self-signed cert for localhost
openssl req -x509 -nodes -newkey rsa:2048 -keyout localhost.key \
  -out localhost.crt -days 365 \
  -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

Then configure your local server to use it. Your browser will warn you — add a security exception for development only.

Better alternative: use mkcert which installs a local CA into your browser's trust store:

brew install mkcert nss
mkcert -install                      # Install local CA
mkcert localhost 127.0.0.1 ::1       # Issue cert trusted by your browser
# → localhost+2.pem, localhost+2-key.pem

13. Common Mistakes

Mistake	Problem	Fix
Using self-signed certs in production	Browser shows scary warning; users leave	Use Let's Encrypt (free)
Not monitoring certificate expiry	Site becomes unavailable after expiry	Set up auto-renewal and expiry alerts
Deploying only the leaf cert (no intermediates)	Some clients can't build the chain	Include the full chain (`fullchain.pem`)
Certificate for wrong domain	NET::ERR_CERT_COMMON_NAME_INVALID	List all domains in Subject Alternative Names
Using RSA 1024	Considered insecure since ~2012	Use RSA 2048/4096 or ECDSA P-256

14. Review Questions

What is a Certificate Authority (CA)?
What is the difference between DV, OV, and EV certificates?
What happens in the "chain of trust" — why are there intermediate CAs?
What does a wildcard certificate *.nandhoo.com cover?
What is OCSP Stapling and why does it improve performance?
What should you do if your server's private key is compromised?
How does a browser know a certificate is still valid (not revoked)?