HTTPS in practice: the certificate, renewal and the usual breakages

A TLS certificate goes to whoever proves they control the domain, by a file on the site (HTTP-01) or a DNS record (DNS-01). Let’s Encrypt does it over ACME.

What you have and what is missing

In the lesson on HTTPS and TLS you saw what TLS is: the handshake, the certificate and the certificate authority. Now for practice. For every site you need to answer four questions: how to get a certificate, how it will be renewed, what breaks if renewal doesn’t work, and whether everything on the page really goes over https. We’ll take them in order.

How to get a certificate

For an ordinary site the certificate is almost always free and automatic. You know three routes from the lesson on HTTPS and TLS; here is how they look in practice, and the first is the best for a beginner.

• The platform does it all. Static hosts (GitHub Pages, Cloudflare Pages, Netlify, Vercel) and most hosts with a control panel turn HTTPS on with one button, or from the start. You renew nothing.
• A program on your server. Certbot, or the Caddy web server (which can turn HTTPS on by itself), asks the authority, gets a certificate and renews it in the background.
• A paid certificate from a certificate authority: needed where an organization’s rules ask for it. For a small site it is usually unnecessary.

Free certificates are issued by Let’s Encrypt over the open protocol ACME (RFC 8555): a program and the authority “agree” with no people involved. That is exactly why terms can be shortened: a person will forget once a quarter, and automation won’t.

A note on the Russian market, as one comparison. Certificates for Russian sites are in flux (October 2026): foreign authorities may refuse organizations under sanctions, and the Russian state’s own authority issues certificates whose root the main browsers outside Russia don’t trust by default. The practical lesson is the same everywhere: before you build plans on one authority, find out how it could stop serving you.

How an authority checks that the domain is yours

Any authority issues a certificate only to someone who controls the domain. For that there are “challenges”. Two of them you need to know.

• HTTP-01: the authority asks you to put a file at http://your-domain/.well-known/acme-challenge/<string> and comes to fetch it. Port 80 must be open and the site must work. It’s simple and fits most cases.
• DNS-01: the authority asks you to add a TXT record named _acme-challenge.your-domain to the zone. No site is needed, and port 80 can be closed. This is the only way to get a wildcard (*.your-domain, which covers any first-level subdomain), but to automate it the program needs access to your DNS provider’s API.

There is a third, TLS-ALPN-01, which is rare. Play with it: switch on the wildcard and see what changes in the check. Then break the certificate in one of four ways and see what a visitor sees.

Domain I need a wildcard (*.example.com) for any subdomains

Check over HTTP (HTTP-01) Check through DNS (DNS-01)

1. You ask for a certificate for example.com and www.example.com (a program on the server: Certbot, Caddy or a button in the host’s panel).
2. The authority replies: “Put a file with this content at http://example.com/.well-known/acme-challenge/<a random string>.”
3. The program puts the file there. Port 80 has to be open for that: the HTTP check goes over exactly that port.
4. The authority comes to that address itself, finds the file and is satisfied that you control the site.
5. The authority signs the certificate. Long before the term ends, the program asks for a new one by itself.

What broke

All is wellExpiredName mismatchIncomplete chainA picture over http

The visitor sees. A padlock, and the page opens.

Why. The certificate is valid, the name matches, the chain is complete and the page has no resources over http.

What to do. Nothing to do. Watch the expiry date.

Check yourself: why does only the check through DNS suit a wildcard?

A wildcard covers all subdomains. A file on one site doesn’t prove that you own all the others. A record in the zone proves that you control the whole domain.

Names and what they cover

A certificate is issued for a list of names. This matters: a certificate for example.com doesn’t cover www.example.com, and a visitor who types www gets a warning. So the certificate includes every name the site opens under: the root, www and the subdomains you need. If there are many subdomains or they appear often, you take a wildcard (with the caveat about the DNS check above).

If the brief has a second language and you chose a folder such as /es/ (as in the lesson on DNS), no separate certificate is needed: the domain is the same. That is one more argument for a folder.

One more optional protection: a CAA record in the domain’s zone lists which authorities may issue certificates for your domain. The others will be refused.

Renewal: automation and a watchman

How long a certificate may last is capped by the CA/Browser Forum, the body of certificate authorities and browser makers. Its Baseline Requirements set the maximum at 398 days until 15 March 2026, 200 days from that date, 100 days from 15 March 2027 and 47 days from 15 March 2029 (checked against the Baseline Requirements text in October 2026). Let’s Encrypt’s certificates are shorter still: 90 days today, with a 64-day default planned from 10 February 2027 and 45 days from 16 February 2028 (the dates are in the lesson on HTTPS and TLS). Software renews them ahead of time, usually when a third of the term is left. It is good when that happens unnoticed, and bad when it happens without your knowing. Automation breaks silently: someone closed port 80, changed DNS, switched providers, or the disk filled up. Two and a half months later visitors see a red warning.

So you need two layers of protection.

1. Automatic renewal that you have tested once: for example, certbot renew --dry-run tries to renew without really issuing and shows the errors.
2. An independent watchman: an outside monitor that checks the expiry date and writes to you two weeks before the end. Since 4 June 2025 Let’s Encrypt itself no longer sends warnings about an approaching expiry, so you can’t count on it. You can take a watchman from the same services that watch whether your site is up (the last lesson of the part).

Check yourself: why do you need independent monitoring if renewal is automatic?

Automation breaks unnoticed. A monitor on the expiry date tells you before the site breaks, not after a visitor complains.

Mixed content

You went through TLS as if the whole page were protected. In fact a page is dozens of requests: HTML, styles, scripts, images, fonts, previews. If even one of them goes over http://, the protection is incomplete. This is called mixed content:

• active (scripts, styles, frames): the browser blocks it outright, because a swapped script breaks the whole site;
• passive (images, audio, video): browsers usually upgrade such requests to https or block them, but the padlock may go.

How to fix it. Change http:// to https:// in the addresses, and for your own files use addresses with no domain: /images/portrait.jpg. As insurance add the header Content-Security-Policy: upgrade-insecure-requests, and the browser will try to load resources over https by itself. Check the small things people forget: the address in canonical, the picture for the link preview (og:image), links inside the site and in the sitemap.

And a last detail: the site itself should redirect http:// to https:// with a permanent 301 redirect, and a cookie with the Secure flag (from the lesson on authentication) won’t travel over http at all.

HSTS, but carefully

The Strict-Transport-Security header (HSTS) tells the browser: “This site is https only, don’t try http, even if the user typed it.” It closes the last gap: the first http request, which could be intercepted.

But it has a price. The browser remembers the instruction for the max-age period, and if you break https, visitors can’t open the site and won’t be allowed to click through the warning. So you start small (a day), make sure everything works, and only then lengthen the term. Preloading (preload), where your site is built into the browser itself, is almost irreversible: a small site doesn’t need it.

Practice

The site of the 2022 era opens over https, but some “forgotten” http addresses are left in it: a picture, canonical, the link preview, the link to the policy. Fix them all. Then fill in the note: how you get the certificate, which names it covers, where the languages live, how it is renewed, what you do if renewal breaks, and what you decided about HSTS.

The check reads the page’s code: it will find every address that starts with http://. The padlock and the browser’s warnings aren’t visible in this sandbox, so after a real deploy (the lesson on publishing) look at them yourself in the developer tools, on the “Console” tab.

What was wrong before

As late as 2010 a certificate cost money (from tens of dollars a year) and was installed by hand once a year or two. People knew the date by heart or wrote it in a calendar, and every year a few well-known sites were left with a red warning on the day it ran out: the person who remembered had left. Today a certificate is free, and the problem has moved from “buying” to “not forgetting about the automation”: it works until someone breaks it.