HTTPS

What is HTTPS?

HTTPS is HTTP over TLS (Transport Layer Security). When your browser sends a request, data passes down through layers - TLS sits between HTTP and TCP, encrypting the HTTP message before TCP ever sees it:

HTTP  →  your request ("GET /page")
TLS   →  encrypts it into ciphertext
TCP   →  breaks it into packets, handles delivery
IP    →  routes packets across the network

The server unwraps in reverse: TCP reassembles, TLS decrypts, your application sees plain HTTP. TCP has no idea what it's carrying - it just delivers bytes.

TLS provides three things:

• Confidentiality - traffic is encrypted; a network observer sees only ciphertext.
• Integrity - tampering is detectable.
• Authentication - the server proves it holds the private key for a certificate signed by a trusted Certificate Authority, so the client knows who it's talking to.

HTTP without TLS sends everything in plaintext - cookies, session tokens, passwords. Any party on the network path (ISP, router, attacker on the same Wi-Fi) can read or modify it. This is not a theoretical risk; tools like Wireshark make it trivial.

How TLS works

TLS works via a handshake - a brief negotiation that happens before any application data is sent. At a high level, enough to understand what certificates and Certificate Authorities are actually doing:

1. Client sends supported cipher suites and a random nonce (a one-time random value that gets baked into the session keys, so a recorded handshake can't be replayed later).
2. Server responds with its certificate and chosen cipher suite.
3. Client verifies the certificate chain up to a trusted root Certificate Authority in the OS/browser trust store (a built-in list of CAs your system already trusts).
4. Key exchange (in TLS 1.3, always ephemeral Diffie-Hellman) produces a shared secret neither side ever sent over the wire.
5. Both sides derive symmetric session keys from that shared secret and start encrypting.

TLS 1.3 (2018) removed weak cipher suites, made forward secrecy mandatory, and cut the handshake to one round-trip. TLS 1.0 and 1.1 are deprecated; 1.2 is acceptable; 1.3 is the target.

What is a Certificate Authority?

A Certificate Authority (CA) is an organisation whose job is to verify that a domain is owned by whoever is claiming to own it, and then issue a certificate saying so. Think of them as a notary - they check your claim, stamp it as verified, and their stamp is what everyone else trusts.

Your browser and operating system ship with a list of CAs they already consider trustworthy - DigiCert, Sectigo, Let's Encrypt, and around 50–100 others. When a browser sees a certificate, it checks whether it was issued by one of these trusted CAs. If yes, it trusts the cert. If no - including self-signed certs you generate yourself - it shows a warning.

To get a certificate, you prove to a CA that you control the domain. The most common method: the CA gives you a random token and asks you to either place it at a specific URL on your site (/.well-known/acme-challenge/...) or add it as a DNS TXT record. If you can do that, you control the domain. The CA issues the cert.

In practice, most developers never touch any of this directly. Platforms like Vercel, Netlify, and Railway handle the entire certificate lifecycle for you - point your domain at them and a trusted cert appears, renewing itself automatically every 90 days. On AWS you'd use ACM (Certificate Manager), which does the same thing within the AWS ecosystem. Where you would interact with this yourself is on a bare VPS - a raw DigitalOcean droplet or EC2 instance running your own nginx. There, you'd install Certbot, run it once, and it handles the domain challenge, cert installation, and sets up auto-renewal. But if you're on any managed platform, it's already been done for you.

CAs are heavily audited and held accountable. If one issues a certificate it shouldn't have - or is compromised - browsers remove it from their trusted list, which invalidates every certificate that CA ever issued. This has happened. It's a strong incentive to operate carefully.

Why root CA private keys are kept in literal vaults

Remember: a root CA's power comes entirely from its private key. Whoever holds that key can sign intermediate CAs, who can sign certificates, for any domain in the world - and every browser will trust them without question. The key is the CA. So root CAs treat their private keys accordingly.

The private key is generated inside a hardware security module (HSM)- a tamper-resistant physical device specifically designed to hold cryptographic keys and never let them leave in plaintext. The HSM lives inside a physically secured room: biometric access controls, mantrap doors (two locked doors you pass through one at a time so you can't tailgate anyone), floor-to-ceiling cameras, and auditors in attendance. An actual vault, in other words - not a metaphor.

To bring the root key online at all - for the rare occasions when a new intermediate CA needs to be signed - a key ceremony is required. The key itself is split into up to 21 parts and distributed across 21 different people. A separate set of 21 people hold the numerical codes for each part. All relevant keyholders must be physically present in the room simultaneously before the key can be reconstructed. A lawyer logs every person, every action, every timestamp in a notarised logbook. Everything is recorded on video. When the ceremony is done, the key goes back offline.

This is not theatre. It's a rational response to the stakes. To see what happens when a CA is compromised, look at DigiNotar, a Dutch Certificate Authority, in 2011.

An attacker - later claimed to be a 21-year-old Iranian hacker - gained complete control of all eight of DigiNotar's certificate-issuing servers. He issued 531 fraudulent certificates: for Google, Mozilla, the CIA, Mossad, Microsoft, Skype, and others. The certificates were real, CA-signed, browser-trusted - indistinguishable from legitimate ones.

The attack was used to intercept the internet traffic of Iranian citizens. When someone in Iran visited Google, they were silently redirected through an attacker-controlled server that presented the fraudulent Google certificate. The browser saw a valid, trusted certificate and showed a padlock. The user had no idea. Over 298,000 unique IP addresses were affected - 95% of them in Iran. The goal was surveillance.

The breach was only discovered weeks later when a user in Iran noticed Chrome flagging the certificate as suspicious (Chrome at the time had special-cased Google's own domains). He posted about it on a forum. Within days, Google, Mozilla, Microsoft, and Apple all pushed emergency browser updates removing DigiNotar from their trust stores. Every certificate DigiNotar had ever legitimately issued - for real companies, for real websites - was instantly untrusted.

The Dutch government had been using DigiNotar certificates for citizen-facing government services. They had to scramble to replace them. DigiNotar itself was declared bankrupt within weeks. An organisation that had existed for years was destroyed in a matter of days, and the collateral damage extended across the entire Dutch internet. That's what a compromised CA looks like. The vault theatrics are completely justified.

What is a certificate?

A certificate (formally an X.509 certificate) is a document that binds a public key to a domain name. It contains:

• The domain name it's valid for (the Common Name / Subject Alternative Names)
• The server's public key
• The issuing CA's name
• Validity period (not before / not after)
• The CA's digital signature over all of the above

That CA signature is the critical part. It means: "we, a CA your browser trusts, have verified that whoever controls this domain has the private key corresponding to this public key." The browser verifies the signature using the CA's own public key (which it already has in its trust store). If the signature checks out, the cert is genuine.

The server's private key never appears in the certificate and never leaves the server. During the TLS handshake the server uses it to prove it possesses the key that matches the public key in the cert - without ever revealing it.

Self-signed certs - where you generate a certificate yourself rather than having a CA sign it - are valid for local development but useless in production. Browsers will block them with a hard interstitial for real users, because there's no CA in the chain for the browser to verify against.

Developer perspective

What HTTPS actually gives you as a developer: proof that the server is who it claims to be, encrypted traffic between client and server, and tamper detection - any modification in transit is detectable and causes the connection to fail.

Why it exists: without it, anyone on the network path can read or modify traffic. The classic threat model is a man-in-the-middle attack- an attacker positions themselves between the client and server, reads everything, and can silently alter responses. On public Wi-Fi this is trivial. Without the authentication side of HTTPS, a server could also impersonate another one entirely - you'd have no way to know you're not talking to an attacker.

What HTTPS doesn't protect against: a typosquat domain like gooogle.comcan get a perfectly valid certificate - the CA only verifies you control the domain, not that the domain isn't deceptively similar to another. A padlock means "this connection is encrypted and authenticated to this domain." It does not mean "this website is trustworthy."

When to use it: any internet-facing service, without exception - websites, external APIs, webhooks, anything a client reaches over the public internet. Browsers now flag plain HTTP as "Not Secure" and some features (service workers, geolocation, camera access) are blocked entirely on HTTP origins. There is no legitimate reason to serve anything over plain HTTP in production.

Internal / VPC traffic: service-to-service communication within a private network (e.g. within an AWS VPC) is commonly left unencrypted, on the basis that you trust the network boundary and AWS controls the underlying infrastructure. This is a reasonable default for most applications. The tradeoff: if the network boundary is ever breached, all internal traffic is readable. In high-compliance environments (PCI-DSS, HIPAA) you'll often see mTLS (mutual TLS - both sides present certificates) even between internal services. If you're calling an external API from within your VPC, HTTPS still applies regardless.