Renew certificate failed because verification code does not follow redirect

This is about renewal of the certificate of 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):
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification…
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/ 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:

“error”: {
“type”: “urn:acme:error:unauthorized”,
“detail”: "Invalid response from "\u003c!DOCTYPE html\u003e\n\u003chtml :zap:\u003e\n\u003chead\u003e\n\u003cmeta charset=“utf-8”\u003e\n\u003clink rel=“icon” type=“image/png” href=“favicon-32x32.png” sizes=“32x32"”,
“status”: 403

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).

With so-called TLS-SNI challenge that what would have happened - connection to HTTPS. HTTP-01 has HTTP in it for a reason :slight_smile:


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.

1 Like

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. :slight_smile:

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?

Thanks for the TLS-SNI suggestion, I’ll look into that.

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.

1 Like

Ah, great, thank you so much!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.