TLS and SSL, explained: how your browser knows it’s really your bank

Encryption stops anyone in between from reading what you send. Integrity means that if anyone changes a single bit in transit, your browser notices and drops the connection. Authentication proves the server you reached is really the one you asked for.

The third promise is the one people forget, and it matters most. Encryption with the wrong party is worthless: if an attacker can pose as HDFC, you’ll happily set up a perfectly encrypted connection with them and type in your password. Most of TLS’s complexity, including certificates and the companies that issue them, exists to keep that promise.

Netscape built SSL (Secure Sockets Layer) in the mid-1990s so people could shop online. When the Internet Engineering Task Force took over the standard in 1999, it renamed it TLS (Transport Layer Security). TLS 1.0 was essentially SSL 3.1 with a new name.

No browser has spoken SSL for years, yet everyone still says “SSL certificate”. It’s a habit, not a technical choice. The certificate isn’t tied to a protocol version anyway: the same certificate works with TLS 1.2 and 1.3. In this guide, “TLS” means the protocol and “certificate” means the thing hosting companies sell as an “SSL certificate”.

Symmetric keys: one key locks and unlocks

Think of a locker with one key. Whoever has a copy can open it. In TLS this is AES or ChaCha20, and it’s fast enough that most modern processors have instructions built specifically for AES. It encrypts everything you actually send: pages, images, form data.

Its weakness: both sides need the same key, and you can’t just send it over the network, because the network is exactly who you don’t trust.

Asymmetric keys: a pair that work together

Here each side has a key pair. The public key can be shown to anyone. The private key never leaves its owner. They’re mathematically linked, but you can’t work out the private key from the public one. TLS uses key pairs for two jobs:

• Agreeing on a shared secret over a network someone is watching. Both sides end up with the same symmetric key, and the watcher can’t compute it.
• Signing. Only the private key can make a signature, and anyone with the public key can check it. This is how a server proves who it is.

Its weakness: it’s slow. That’s why TLS uses key pairs only at the start, to agree on a symmetric key and prove identity, then switches to the fast symmetric key for the actual data.

How two strangers agree on a secret in public

The usual way to picture the key exchange (called Diffie-Hellman) is mixing paint:

1. Your browser and the server agree, in public, on a base colour: yellow.
2. Each picks a secret colour and never shares it. Browser: red. Server: blue.
3. Each mixes its secret into the yellow and sends the result. Anyone watching sees yellow, orange and green go past.
4. Each adds its own secret to the mix it received. Both end up with the same muddy brown: yellow + red + blue.

The watcher has every public piece but can’t un-mix paint to get red or blue. In real TLS the colours are points on an elliptic curve and “mixing” is multiplication, which is easy forwards and believed to be impossible backwards. HDFC’s server uses X25519, a curve designed for exactly this.

Key exchange alone doesn’t tell you who you’re talking to. An attacker can run a key exchange too. So the server also sends a certificate: a small file that binds a public key to a domain name, signed by a company your device already trusts.

It works like a passport. The passport carries your photo and name; the government’s stamp is what makes anyone believe it. In a certificate, the public key is the photo, the domain is the name, and a Certificate Authority’s signature is the stamp.

See one for yourself

Any public certificate can be downloaded by anyone. This command asks HDFC’s server for its certificate and prints the fields that matter. It works on macOS and Linux, and on Windows through WSL.

echo | openssl s_client -connect www.hdfcbank.com:443 -servername www.hdfcbank.com 2>/dev/null \  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

subject=C = IN, ST = Maharashtra, L = Mumbai, O = Hdfc Bank Limited, CN = www.hdfc.bank.inissuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust TLS RSA CA G1notBefore=Jul  1 00:00:00 2026 GMTnotAfter=Jan 15 23:59:59 2027 GMTX509v3 Subject Alternative Name:    DNS:www.hdfc.bank.in, DNS:hdfc.bank.in, DNS:hdfcbank.com, DNS:www.hdfcbank.com

How a Certificate Authority checks you

A Certificate Authority (CA) won’t sign a certificate for a domain until you prove you control it. For most websites that check is automated and takes seconds. You either put a file with a random token at a set address on your site, or add a DNS record with that token. Only whoever controls the domain can do either.

Your browser has never seen HDFC’s certificate before, so how does it decide to trust it? It follows the signatures upward until it reaches one it already knows.

Those known certificates are root certificates. Your operating system and browser ship with a curated list of them, owned by a few dozen organisations. Mozilla, Apple, Microsoft and Google each run a programme that audits every CA before adding its roots, and can remove them at any time. That list is called the trust store, or root store.

A root’s private key is the most valuable secret a CA owns. It sits offline in a hardware security module and is used rarely. The day-to-day signing is done by intermediate certificates, which the root signs. If an intermediate is compromised, it can be revoked without replacing the root on billions of devices.

What your browser checks, every time

1. The domain in your address bar appears in the certificate’s Subject Alternative Name list.
2. Today’s date is inside the validity window.
3. Each signature in the chain verifies with the public key of the certificate above it.
4. The chain ends at a root in the trust store.
5. None of the certificates has been revoked.
6. The server proved it holds the private key, by signing the handshake.

Fail any one and you get the full-page warning. Notice what this means: any CA in the trust store can sign a certificate for any domain. A chain is only as strong as the weakest CA your device trusts. Hold on to that; it’s the whole eMudhra story.

Before a single byte of the page is sent, your browser and the server run a handshake: they agree on a cipher, exchange key halves, and the server proves its identity. Here’s the TLS 1.3 version, the one HDFC’s server used.

Watch it happen

curl prints each handshake message as it happens. This filters its output down to just those lines.

curl -sv -o /dev/null https://www.hdfcbank.com 2>&1 | grep -E "TLS handshake|SSL connection"

* TLSv1.3 (OUT), TLS handshake, Client hello (1):* TLSv1.3 (IN), TLS handshake, Server hello (2):* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):* TLSv1.3 (IN), TLS handshake, Certificate (11):* TLSv1.3 (IN), TLS handshake, CERT verify (15):* TLSv1.3 (IN), TLS handshake, Finished (20):* TLSv1.3 (OUT), TLS handshake, Finished (20):* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

Your output may look different: the Mac’s built-in curl, for one, formats these lines its own way. Two new session tickets usually follow; the server sends them so a repeat visit can skip some of this work.

Reading the cipher name

TLS_AES_256_GCM_SHA384 looks like noise, but every part means something:

The certificate expired

The most common failure by far, and it isn’t an attack. On 3 February 2020, Microsoft Teams went down for hours because a certificate behind its sign-in had expired. Expiry is a feature: it caps how long a stolen key or a mis-issued certificate stays useful. That’s also why lifetimes keep shrinking.

That schedule is the CA/Browser Forum’s ballot SC-081, which every public CA follows. At 47 days, renewing by hand stops being realistic. Let’s Encrypt already issues 90-day certificates; this site’s current one runs from 22 September to 21 December, and renews itself.

The name doesn’t match

A certificate for www.example.com doesn’t cover example.com unless both are in the Subject Alternative Name list. It’s the second most common warning, usually after someone adds a new subdomain and forgets the certificate.

Nobody trusted vouches for it

A self-signed certificate is one that signs itself, like a passport you printed at home. Fine on your laptop for local development, rejected everywhere else. A related case: many company networks and some antivirus tools install their own root on your machine so they can decrypt and inspect your traffic. Your browser shows a padlock, because your device was told to trust that root.

A trusted CA signs something it shouldn’t

This is the dangerous one, because every check passes. In 2011, attackers broke into a Dutch CA called DigiNotar and issued themselves more than 500 certificates, including one for google.com. They were used to intercept Gmail users in Iran. Every major browser removed DigiNotar’s roots, and the company was bankrupt within weeks.

Two systems now limit the damage:

• Certificate Transparency. Public CAs must record every certificate they issue in public, append-only logs, and Chrome and Safari reject most certificates that aren’t logged. Any certificate issued for your domain, by anyone, shows up there. You can search them at crt.sh.
• Browser blocklists. Revocation through the CA itself is slow and unreliable, so browsers push their own lists of blocked certificates to every user: CRLSets in Chrome, OneCRL in Firefox. That’s how a bad certificate can be killed worldwide in hours.

eMudhra is an Indian Certificate Authority whose roots were in the trust stores of every major browser. On 30 April 2025 it generated 24 new intermediate certificates. Eight of them had private keys that were tiny numbers. On 17 October 2026 a researcher reported it to the browser makers.

Why a small key is no key at all

These were elliptic-curve keys on a curve called P-384. The private key is meant to be a random number up to 384 bits long, and the public key is that number multiplied by a fixed starting point on the curve. Multiplying is easy. Going back from the public key to the number is what’s believed to be impossible, but only because the number could be any one of about 10¹¹⁵ values.

eMudhra’s keys were all below 256. The public keys sit in the certificates, which anyone can download. So recovering a private key meant multiplying the starting point by 1, then 2, then 3, and stopping at the match. The security researcher Scott Helme recovered keys of 4, 56 and 115 this way in under a second. It takes a few lines of Python:

from cryptography import x509from cryptography.hazmat.primitives.asymmetric import ec cert = x509.load_pem_x509_certificate(open("intermediate.pem", "rb").read())target = cert.public_key().public_numbers()  # public, in the certificate for d in range(1, 256):  # every possible key below 256    guess = ec.derive_private_key(d, ec.SECP384R1())    if guess.public_key().public_numbers() == target:        print("Private key is", d)

What someone holding that key could do

Go back to the chain. An intermediate’s private key is what signs website certificates. With it, an attacker could create a certificate for hdfcbank.com, or any other domain, with a key pair of their own. Every browser check passes: the name matches, the dates are fine, the signature verifies, the chain reaches a trusted root. Combine that with control of a Wi-Fi network or a DNS server and they can pose as the bank, padlock and all.

Six of the eight intermediates were for TLS; the other two could sign software, so malware could have carried a valid publisher signature.

What happened next

Google has also announced that Chrome will stop trusting eMudhra’s root, and says it’s reviewing the company’s other certificates.

eMudhra says a faulty script in its key ceremony created a second set of weak keys with labels similar to the real ones, and the weak set was picked by mistake. It says its systems weren’t breached and none of the eight issued certificates to customers. Both may be true, and the browsers acted anyway, because nobody can prove what happened to keys that were guessable for seventeen months. A certificate signed by eMudhra and one signed by an attacker using the same recovered key are indistinguishable. Once trust in a signature is gone, there’s no partial version of it.

Let the platform handle certificates

Vercel, Netlify, Cloudflare, Render and most other hosts issue and renew certificates for your domain automatically, usually through Let’s Encrypt. On your own server, Caddy does the same out of the box, and certbot adds it to nginx. With validity heading to 47 days, anything that relies on someone remembering to renew will eventually fail.

Never switch off certificate checks

This is the mistake AI coding tools make most often. You hit an error like self-signed certificate in certificate chain or unable to get local issuer certificate, ask for a fix, and get one of these. The error disappears, and so does the authentication promise: your app will now talk to anyone who answers, attacker included.

// Node.jsprocess.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';new https.Agent({ rejectUnauthorized: false }); # Pythonrequests.get(url, verify=False) # Shellcurl -k https://api.example.com

The real fix is almost always one of three: the server isn’t sending its intermediate certificate, the clock on your machine is wrong, or you’re behind a corporate proxy whose root certificate needs adding to your trust store.

Encrypt the connections users never see

The padlock covers the browser and your server. The hop from your server to its database, cache or payment API needs its own TLS. A common trap with Postgres:

# Encrypts, but doesn't check who answeredpostgresql://app:password@db.example.com:5432/app?sslmode=require # Encrypts and checks the certificate and hostnamepostgresql://app:password@db.example.com:5432/app?sslmode=verify-full

verify-full needs your database provider’s CA certificate, which most providers let you download. On Postgres 16 or newer clients, sslrootcert=system uses your machine’s trust store instead.

Force HTTPS, and tell browsers to remember

Redirect every http:// request to https://. Then send this header, so browsers go straight to https:// on future visits and an attacker can’t catch that first unencrypted request:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Only add includeSubDomains once every subdomain you own serves HTTPS, or the ones that don’t will stop loading.

Guard your private keys

If you ever handle certificate files yourself, the .key or .pem file holding the private key is the one secret all of this rests on. Keep it out of git, out of screenshots and out of chat messages. If it leaks, revoke the certificate and issue a new one with a fresh key.

Test what you shipped

• SSL Labs’ server test grades your site’s TLS setup and explains every deduction.
• Search your domain on crt.sh. You should recognise every certificate listed. One you don’t is worth investigating.
• Run the openssl command from section 04 against your own domain and check the names and dates.