The SSL Certificate That Couldn't Renew Because the Site Was Too Secure

Certificates are a chore, until they aren't

I manage SSL certificates for our brand sites, and the renewals are automated with Certify The Web and Let's Encrypt. The beauty of automation is that you stop thinking about it.

The danger of automation is also that you stop thinking about it.

So when the renewal for one of our brand sites started failing, I had to remember how the whole thing actually works.

How Let's Encrypt checks that you own the site

Before Let's Encrypt gives you a certificate, it wants proof that you control the domain. One common way is the HTTP-01 challenge.

Your server puts a small file at a specific address. Let's Encrypt visits that address over plain HTTP, on port 80. If the file is there, you pass.

Let's Encrypt:  "Prove you own this domain."
Your server:    puts a token file at
                http://example.com/.well-known/acme-challenge/<token>
Let's Encrypt:  visits it over HTTP (port 80)
                ✓ found it → certificate issued

The missing door

The site had no HTTP binding for port 80 in IIS. It only answered on HTTPS.

So Let's Encrypt knocked on port 80, and nobody was home. Validation failed, so the renewal failed.

That's the funny part. A site set up to only speak HTTPS was blocking the very check that keeps its HTTPS working. It was too secure to stay secure.

The fix

Add the missing port 80 binding so the validation request had somewhere to land. Renewal went through.

If you redirect HTTP to HTTPS, that's still fine. Let's Encrypt follows the redirect. But something has to be listening on port 80 to answer the knock in the first place.

What I took away from it

• Know how your certificate validation works, not just that it's automated.
• Automation fails quietly. Watch the results, not just the setup.
• One site with a different setup can break a process that works everywhere else.
• "More secure" settings can break the things that keep you secure.