Hi,
This is about renewal of the certificate of www.demuziekwerkplaats.nl. During the last year all renewals went perfectly (certbot renew --logs-dir $dir). But since a few days it fails with an obscure error message:
Cert is due for renewal, auto-renewing…
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.demuziekwerkplaats.nl
Waiting for verification…
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/www.demuziekwerkplaats.nl.conf produced an unexpected error: ‘ascii’ codec can’t encode character u’\u26a1’ in position 226: ordinal not in range(128). Skipping.
It took me a while to find out what the cause was. This in the logfile triggered me:
It tries a request via http instead of https. There is a redirect (301) in the nginx config and it works great. But the verification code sees a 403 instead of a 301. That can not be right.
Anyway, I removed the redirect from nginx and the renewal worked. Of course the redirect is back, so next time it will fail again, unless this is fixed.
So it looks to me like some bug is introduced. Or am i wrong? Please advise what to do.
Ah, wait a minute, the redirect is done to the homepage anyway, instead of same page with https. So, the redirect was correctly followed (but should result in a 200 of course). But I would have preferred the verification would be done to https in the first place (for renewals at least).
I guess you’ve understood that you’ll need to make the redirect point to the same page with HTTPS, instead of the homepage, at least for URLs under /.well-known/acme-challenge on your site.
You are using the webroot plugin, which always performs validation via HTTP. You were probably recommended to use this because you’re running nginx. If you have a recent version of Certbot (if I remember correctly, since 0.12.0), you could try to switch to the nginx plugin, which is able to perform validation via HTTPS. This plugin is still considered somewhat experimental.
You can also get validation via HTTPS with the standalone plugin, but it requires shutting down your webserver briefly during the certificate renewal process, which may not be what you want.
Thanks for your answer. Usually I do the redirect to same page with https, so I was surprised I did not do it in this case. That is back to normal.
What would have loved to see here is helpful error handling. It have been so much easier to solve if it made clear that it validated the home page instead of the challenge file. Would that be doable?
I'm embarking on a big project to create a "failed challenge diagnostics" page, where Certbot will try to interpret errors from the server and then point users to a detailed debugging reference explaining what went wrong and why.
In this case, as you notice, the server didn't mention that it followed a redirect, and so Certbot would have no way of knowing that in any case. I'll make a note to see if Boulder (the CA software) can start mentioning this in its error messages somehow.