🚀 Deployment & Ops · Chapter 2

HTTPS and certificates — what actually gets verified

A certificate does not prove a site is safe. It proves the server you reached controls the name you typed — and it is strict about which names.

Study this lesson free in the app →

The basics

HTTPS is HTTP sent inside an encrypted TLS connection, and the certificate is how your browser checks it's talking to the real owner of the name you typed.

The problem it solves: on café wifi or a shared office network, anyone between you and the server could read or change your traffic, or pretend to be the site. Encryption stops the reading; the certificate stops the pretending.

The mental model: an ID card the server shows at the door. It lists the names it is valid for, who issued it, and when it expires. Your browser checks that a trusted authority signed it, that it hasn't expired, and — the check that catches people — that the name you typed is on its list. Not the IP you reached; the name. www.ai-teacher.in and ai-teacher.in are two different names.

A certificate proves control of a name. It says nothing about whether the site is honest — phishing sites get padlocks too.

Explained

The DNS was right. The server was right. https://www.ai-teacher.in loaded perfectly.

https://ai-teacher.in — no www — refused to connect at all.

One certificate, two names, and only one of them on it.

When you connect over HTTPS, the server hands you a certificate. Think of it as an ID card with three things on it:

1. Which names it is valid for — ai-teacher.in, www.ai-teacher.in
2. Who issued it — Let's Encrypt, in our case
3. When it expires

Your browser checks all three, plus one more thing people forget: does the name on the card match the name you typed? Not the IP you connected to — the name.

Here is the real failure, exactly as it appeared:

$ curl -v https://ai-teacher.in
* Connected to ai-teacher.in (76.76.21.21) port 443
* Server certificate:
*  subject: CN=www.ai-teacher.in
*  subjectAltName does not match host name ai-teacher.in
* SSL: no alternative certificate subject name matches
* Closing connection

Read the third and fourth lines together. The connection succeeded — the right server answered on the right IP. Then the browser looked at the ID card, saw it said www.ai-teacher.in, compared it against what was typed — ai-teacher.in — and refused.

www.ai-teacher.in and ai-teacher.in are different names. A certificate for one does not cover the other. Not a wildcard issue, not a DNS issue. Just a missing name on a list.

The certificate was reissued covering both names:

vercel certs issue ai-teacher.in www.ai-teacher.in

Afterwards:

subject: CN=ai-teacher.in
subjectAltName: host "ai-teacher.in" matched cert's "ai-teacher.in"
issuer: C=US; O=Let's Encrypt; CN=YR2

Most hosts do this automatically when you add a domain. This one issued for www first and left the apex uncovered — which is worth knowing, because "the host handles certificates" is true right up until it is not.

CN, SAN and wildcards

CN (Common Name) — the legacy single-name field. Browsers have ignored it for matching since about 2017.

SAN (Subject Alternative Name) — the actual list of names the certificate covers. This is what gets checked. A certificate can carry a hundred names.

Wildcard — *.ai-teacher.in covers www, api, docs. It covers exactly one level: not a.b.ai-teacher.in, and — the one that catches people — not the apex ai-teacher.in itself.

So the belt-and-braces certificate for a domain is two entries: ai-teacher.in and *.ai-teacher.in.

How the certificate gets issued

Let's Encrypt uses ACME, which is a challenge: prove you control this name.

HTTP-01 — put a specific file at http://yourdomain/.well-known/acme-challenge/<token>. Requires port 80 to be reachable, and cannot issue wildcards.

DNS-01 — put a specific TXT record on _acme-challenge.yourdomain. Works for wildcards, and works for a server that is not public yet.

Either way, the name has to resolve to you before a certificate can be issued. That is the ordering people get wrong: DNS first, then certificate. Point the record, wait, then expect HTTPS.

Adding www and forgetting the apex. Or the reverse. Both are names; both need covering.

Expecting a wildcard to cover the root. *.example.com does not match example.com.

Requesting the certificate before DNS resolves. The challenge fails, and some issuers then back off for a while before retrying.

Hitting the rate limit while debugging. Let's Encrypt allows 5 duplicate certificates per week. Use --dry-run or a staging endpoint when experimenting.

Assuming HTTPS means trustworthy. A phishing site gets a valid certificate in thirty seconds. It proves name control, nothing more.

The certificate is checked against the name you typed, not the server you reached.

www.example.com and example.com are two names. Cover both, every time.

And the ordering never changes: DNS first, certificate second.

Words to know

In two minutes

• HTTPS = HTTP inside TLS; the certificate proves the server controls the hostname you typed.
• The browser checks three things: a chain to a trusted root, not expired, and the hostname in the SAN list.
• www.example.com and example.com are different names; cover both.
• A wildcard covers exactly one level and never the apex — so issue for example.com plus *.example.com.
• ACME issues certificates after a challenge: HTTP-01 (a file on port 80) or DNS-01 (a TXT record; needed for wildcards).
• DNS must point at you before a certificate can be issued — DNS first, certificate second.
• A padlock proves name control and encryption, not trustworthiness.

Test yourself

There are 8 questions, 3 puzzles and 5 recall cards for this lesson in the app — the recall cards come back on later days, just before you would forget.