How SSL actually works

Type your password into a page served over plain http://, and every device between you and that server can read it. Not decode it, not crack it. Read it, the way you are reading this sentence. The same is true of the session cookie that comes back, which is the thing an attacker actually wants, because it lets them be you without ever knowing your password.

That is the hole https:// closes. Everything else in this article is about how it closes it, and why the answer needs so many moving parts.

Why any of this exists

Start with two machines and nothing else, and add one piece at a time.

you  -------------------->  server
           plain text

you  ====================>  server
         unreadable in transit

you  ====================>  server
                            + cert
                       "I own example.com"

you  ====================>  server
                            + cert
                              |
                       signed by CA
                    (already trusted
                     by your device)

Encrypting to an attacker sitting between you and your bank achieves nothing except making the eavesdropping tidier. Identity is also where the day-to-day trouble is: almost every TLS problem you hit in production is a certificate problem, not a cryptography problem.

A note on the name

SSL stands for Secure Sockets Layer, built by Netscape in the mid-1990s. Every version of it is broken: SSL 2.0 was prohibited by RFC 6176, and SSL 3.0 followed after the POODLE attack. The replacement is TLS, Transport Layer Security, whose 1.0 and 1.1 versions were themselves deprecated by RFC 8996 in 2021. You are almost certainly running TLS 1.2 or TLS 1.3.

The old word survives because it is welded into config keys (ssl_certificate in nginx), library names (OpenSSL) and a decade of marketing. When someone says “SSL cert” they mean a TLS certificate, and you do not need to correct them. This article uses the two words for the same thing, and names a version where it matters.

The handshake, step by step

Before any HTTP request is sent, the two sides run a handshake. This is what happens on a modern TLS 1.3 connection.

TLS 1.2 needed two round trips here, which is a large part of why 1.3 exists. TLS 1.3 also cut the cipher suite list to five (RFC 8446, appendix B.4) and removed every mode that had turned out to be a foot-gun, including static RSA key exchange and renegotiation.

The key that encrypts your traffic is generated fresh for this connection and thrown away afterwards, so recording the traffic today and stealing the server’s private key next year does not decrypt it. That property is called forward secrecy. The certificate’s key only ever signs. It never touches your data.

What is actually inside a certificate

A certificate is a small, boring, structured file. Click through the parts that matter, taken from the certificate Wikipedia was actually serving when this article was written:

Nothing in there says whether the operator is honest, solvent or competent. A public certificate is issued once the applicant proves they control the domain, usually by serving a specific file or publishing a specific DNS record. That is the whole test.

The chain of trust, and why your laptop believes anyone

Your device ships with a root store. That list is the foundation of the whole system, and you did not choose it.

Roots do not sign your certificate directly. Their private keys live offline in hardware, brought out rarely. Instead a root signs an intermediate, the intermediate signs your certificate, and your server presents the resulting chain. Press the button and watch the client walk it:

The client walks upwards, checking each signature, until it lands on something in its root store. If it lands there, the chain is trusted. If it runs out of links first, it is not.

Your server must send the intermediates. It must not send the root. The root is already on the client, and sending it wastes bytes on every handshake. This one sentence is the source of an enormous share of TLS support tickets.

The traps

Wildcards cover one level, the way a key opens one floor rather than the building. A certificate for *.example.com matches api.example.com and www.example.com. It does not match a.b.example.com, and it does not match example.com itself unless that name is listed separately. Most issuers add the bare domain for you, which is why this only bites when you generate certificates yourself.

Expiry is an outage, not a warning. An expired certificate is a passport at a border, not a library card: there is no talking your way past the date. At the not-after timestamp every client starts refusing the connection, with no grace period. The window is shrinking fast:

Manual renewal has stopped being a viable strategy.

The hostname you connect to is what gets checked, not the IP. Modern servers host many sites on one address, so the client announces which one it wants via SNI. Connect by IP address and you will get whichever certificate is the default, and validation will fail. That is why openssl s_client has a separate -servername flag.

TLS usually stops at your edge. In most deployments the load balancer or CDN terminates TLS and opens a second connection to your application. Whether that second hop is encrypted is a decision somebody made, possibly by accident. The padlock in the user’s browser says nothing about it.

Mixed content quietly downgrades your page. An HTTPS page that pulls a script over plain HTTP is as compromised as if the whole page were HTTP, because an attacker who can rewrite that script owns the page. Browsers block this outright for scripts and stylesheets now, so the usual symptom is a feature that silently does not work.

What TLS will not do for you

It does not make your application secure. TLS protects data while it is moving between two points. SQL injection, a leaky API, a public S3 bucket and a weak password policy are all completely untouched by it.

It does not hide who you are talking to. Your DNS lookup, the destination IP, and the SNI hostname in the ClientHello are all visible to anyone on the path. What is hidden is the URL path, the headers, the cookies and the body. Encrypted Client Hello (RFC 9849, published March 2026) fixes the SNI leak and is supported by several large CDNs, but it needs matching DNS records and client support, so cleartext SNI is still the norm.

It does not verify the client. By default only the server proves anything. Mutual TLS, where the client presents a certificate too, exists and works well, but it is a deliberate extra step and it brings its own certificate lifecycle to manage.

It is not free. You pay a round trip on every new connection, some CPU on every handshake, and a permanent operational cost in renewals and expiry monitoring. Worth paying almost every time, but pretending it is free is how the renewal job ends up nobody’s job.

Checking it yourself

One command shows you the whole picture:

echo | openssl s_client -connect wikipedia.org:443 -servername wikipedia.org

The -servername flag sets SNI, and without it you may get the wrong certificate entirely. The parts that matter:

Certificate chain
 0 s:CN = *.wikipedia.org
   i:C = US, O = Let's Encrypt, CN = YE2
   v:NotBefore: Aug  5 19:15:41 2026 GMT; NotAfter: Nov  3 19:15:40 2026 GMT
 1 s:C = US, O = Let's Encrypt, CN = YE2
   i:C = US, O = ISRG, CN = Root YE
...
Verification: OK
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Verify return code: 0 (ok)

Read it upwards. s: is the subject, i: is the issuer, and each entry’s issuer is the next entry’s subject. That is the chain. Verification: OK means it reached a trusted root; anything else names the specific link that failed. The NotAfter date on entry 0 is your renewal deadline, and here it is 90 days after issuance, which is the Let’s Encrypt default.

echo | openssl s_client -connect wikipedia.org:443 -servername wikipedia.org \
  2>/dev/null \
  | openssl x509 -noout -text \
  | grep -A3 "Subject Alternative Name"

curl -sSI https://expired.badssl.com/

Where to go next

Three directions, depending on what you are trying to do.

If you run servers: learn ACME properly, so certificate renewal becomes something you configure once. Then read up on HSTS, the header that tells browsers never to try plain HTTP for your domain again.

If you are debugging: get comfortable with openssl s_client, then look at Certificate Transparency logs (searchable at crt.sh), which record every public certificate ever issued for a domain. They are how you find out that somebody issued a certificate for your domain without telling you.

If you want the mechanism underneath: read about Diffie-Hellman key exchange, which is the trick that lets two strangers agree on a secret over a wire everyone can read. It is the one piece of mathematics in this article that genuinely feels like magic, and it is more approachable than its reputation suggests.