How Certificates Work — Trust on the Internet

When your browser connects to https://8vast.io, TLS encrypts the connection. But encryption alone doesn't prove you're talking to the real server. Without identity verification, an attacker could intercept the connection, present their own encryption keys, and decrypt everything in between. This is a man-in-the-middle attack.

Certificates solve this. A certificate is a digitally signed document that binds a domain name to a public key. When the server presents its certificate during the TLS handshake, your browser verifies the signature and checks whether it trusts the signer. If the chain of trust holds, the connection proceeds. If not, you see a warning.

What Is in a Certificate?

A certificate is a structured file (X.509 format, defined in RFC 5280) containing:

• Subject — who the certificate is for (CN=8vast.io or a list of Subject Alternative Names).
• Public key — the server's public key, used by the client during the TLS handshake.
• Issuer — who signed the certificate (the Certificate Authority).
• Validity period — not-before and not-after dates. Certificates expire.
• Serial number — unique identifier from the CA.
• Signature — the CA's digital signature over all the above fields.

The signature is the critical part. It proves that a trusted authority verified the subject's identity and vouched for the binding between the domain name and the public key.

How Does the Chain of Trust Work?

Your browser doesn't trust individual server certificates directly. It trusts a small set of root certificates — about 150 of them, pre-installed by your operating system or browser vendor. These root certificates belong to Certificate Authorities (CAs) like DigiCert, Sectigo, and the Internet Security Research Group (ISRG, which operates Let's Encrypt).

In practice, root CAs don't sign server certificates directly. They sign intermediate certificates, which sign the server certificate. This creates a chain:

When your browser receives the server's certificate during the TLS handshake:

1. Read the server certificate — 8vast.io, signed by R3.
2. Find the intermediate — the server sends its intermediate certificate along with its own. R3, signed by ISRG Root X1.
3. Check the root — is ISRG Root X1 in the browser's trust store? Yes.
4. Verify signatures — walk the chain, verifying each signature. Root signed intermediate, intermediate signed server.
5. Check validity — is the certificate expired? Is the domain correct? Is it revoked?

If all checks pass, the browser trusts the connection. If any check fails — wrong domain, expired certificate, unknown CA, broken chain — the browser shows a warning and may block the connection entirely.

How Do You Get a Certificate?

Before Let's Encrypt, getting a certificate meant paying a CA ($50-300/year), going through a manual verification process, and installing the certificate on your server. This friction meant most websites ran on plain HTTP.

Let's Encrypt changed everything. Founded in 2013 by the Internet Security Research Group and launched in 2015, Let's Encrypt issues free certificates using the automated ACME protocol (RFC 8555):

1. Your server requests a certificate for 8vast.io.
2. Let's Encrypt challenges you to prove you control the domain — typically by placing a specific file at http://8vast.io/.well-known/acme-challenge/TOKEN or creating a DNS TXT record.
3. Your server responds to the challenge automatically.
4. Let's Encrypt verifies the challenge and issues a certificate, valid for 90 days.
5. Your server renews automatically before expiry.

As of 2026, Let's Encrypt has issued certificates for over 300 million domains. HTTPS went from 40% of web traffic in 2016 to over 95% in 2026, largely because of free, automated certificates.

What Is Certificate Transparency?

How do you know a CA hasn't issued a fraudulent certificate for your domain? Certificate Transparency (CT) solves this with public, append-only logs.

Every CA is required to submit every certificate it issues to multiple CT logs before the certificate is valid. These logs are publicly searchable. If a rogue CA issues a certificate for google.com to an attacker, the fraudulent certificate appears in the logs and can be detected.

Browsers enforce CT: Chrome requires certificates to be logged in at least two independent CT logs. A certificate without CT proof is treated as untrusted.

You can search CT logs yourself at crt.sh — enter any domain and see every certificate ever issued for it, who issued it, and when.

What Happens When Certificates Go Wrong?

Expired certificate — the most common error. Certificates have a validity period (90 days for Let's Encrypt, up to 398 days for paid CAs). If renewal fails silently, users see a scary warning. Automated renewal via ACME prevents this, but many organizations still manage certificates manually.

Wrong domain — the certificate is for www.example.com but the user connected to example.com. Wildcard certificates (*.example.com) and Subject Alternative Names (SANs) help, but misconfiguration is common.

Revoked certificate — the private key was compromised, or the certificate was issued fraudulently. CAs publish Certificate Revocation Lists (CRLs) and support the Online Certificate Status Protocol (OCSP) for real-time revocation checks. In practice, revocation checking is imperfect — CRL downloads are slow, and OCSP adds latency. OCSP stapling (the server includes the OCSP response in the TLS handshake) is the best current solution.

Compromised CA — if a root CA's private key is compromised, every certificate it ever signed is suspect. This has happened: DigiNotar (2011) was removed from all trust stores after attackers obtained fraudulent certificates for Google, Yahoo, and other domains. The entire CA was shut down.

How Is Certificate Pinning Different?

Certificate pinning adds an extra layer: the application remembers which certificate or public key the server used previously and rejects connections with a different one, even if the new certificate has a valid chain of trust.

This defends against compromised CAs — if an attacker obtains a valid certificate from a different CA, pinning catches it. But pinning is dangerous: if you lose your pinned key or need to rotate certificates, your own users get locked out. Most organizations have moved away from pinning in favor of Certificate Transparency and short-lived certificates.

How Does This Relate to the Rest of the Stack?

Certificates sit at the intersection of TLS and identity:

• During the TLS handshake, the server presents its certificate to prove its identity.
• HTTPS depends on certificates — without a valid certificate, there's no HTTPS.
• DNS connects to certificates through DNS-based validation (proving domain ownership during ACME challenges).
• Post-quantum cryptography will eventually require new certificate formats with larger keys.

Next Steps

You've now covered the full networking stack — from transport (TCP, UDP) to name resolution (DNS) to encryption (TLS) to application protocol (HTTP) to performance (congestion control) to identity (certificates) to kernel optimization (eBPF) to the future of networking.

• How TLS Works — revisit TLS with a deeper understanding of certificate verification.
• How eBPF Works — how the kernel processes network traffic.
• The Future of Networking — post-quantum cryptography, DPUs, and zero trust.