Certbot Renew Pain

Something’s been driving me mad the last few days…

tl;dr :

certbot certonly -vvv --debug-challenges --webroot -w /opt/lampp/htdocs -d hyperdata.it

By Marc NL at English Wikipedia – Transferred from en.wikipedia to Commons., Public Domain, https://commons.wikimedia.org/w/index.php?curid=2747237

I can’t remember if I wrote this up anywhere, but I had a real nightmare getting HTTPS support working on this site. Until some kind soul pointed me to Let’s Encrypt. It still took a little while thanks to XAMPP having a different directory layout than standard Apache. But relatively speaking it was easy from there.

I’d not actually checked how long their certificates are valid for, I suppose assuming a year or more. I think it turned out to be 3 months. Whatever, all of a sudden I didn’t have HTTPS.

The main tool, certbot, is rather wonderful. I should imagine in 9/10 cases it just works. It automatically does all the stuff I found virtually impossible to do manually. But when running certbot renew, I hit what appears to be a fairly common problem. There was even a note in the response:

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

When it runs it rather cleverly creates the necessary cert files, makes temporary changes to the HTTP server config and puts a temporary file at eg.


– then checks it can see that file.

Googling around, virtually all problems related to the visibility of that file, and it appeared I too was getting a 404 on it. So I did the obvious, stuck a test file in that directory. It was visible. Hmm…

Warning : there is a rate limit on requests at the Let’s Encrypt server. While trying to get to the bottom of this I hit it a few times, extremely frustrating. There is a –dry-run option, that may avoid hitting the limit, but I only discovered this in my last few attempts so not sure if it was dodging the limit.

At this point I was fairly sure that certbot wasn’t writing the files it should have been. But, doing ls -al around the places it was meant to have touched, the modified date was today…or was that me..?

But I was wrong, it was the visibility of .well-known/acme-challenge/

I discovered this after trying a really verbose debuggy version of the command, so:

certbot certonly -vvv --debug-challenges --webroot -w /opt/lampp/htdocs -d hyperdata.it

This pauses in the middle of operations, after writing the temporary file to the server.

At this point I had a look in the filesystem – yup, it was there. In a browser – 404.


Now I can’t say for certain, but what appeared to be happening was the browser (and the certbot agent) were hitting a redirect, which I thought I’d removed, from http://… to https://…

My config files have accrued a lot of other stuff, various virtual hosts, proxies, redirects etc. I tried to be methodical, narrow down the problem, but really all I needed to do was comment out everything except the bare port 80, root dir part of my setup.

Having done this, running the command above and letting it run through the check, bingo!

I then uncommented all the other stuff, and everything worked as it had before the cert expired.

What I didn’t do was set it up to automatically renew. I should have at least tried, even if I may have to do that ^^^ again next time. But it’s already practically got me certified, so just having it running for now feels good enough for today.


Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment