Certbot renew failure via HTTP-01 challenge using Cloudflare

My domain is: BRUISEDSKY.COM

I ran this command: sudo certbot renew --dry-run

It produced this output:
`Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/bruisedsky.com.conf


Simulating renewal of an existing certificate for bruisedsky.com and 6 more domains

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: bruisedsky.com
Type: unauthorized
Detail: During secondary validation: 2606:4700:3030::6815:1001: Invalid response from http://bruisedsky.com/.well-known/acme-challenge/RLpsgq5R5KPKPEazGTIrkvQsNKDCPuc-mzopCgVjhEU: 403

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

Failed to renew certificate bruisedsky.com with error: Some challenges have failed.


All simulated renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/bruisedsky.com/fullchain.pem (failure)


1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.`

My web server is (include version): nginx version: nginx/1.22.1

The operating system my web server runs on is (include version): Debian 12.8

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 3.1.0

The 403 had me curious and I verified my http server's configuration is correct. Did some more digging, and it appears that Cloudflare's security is blocking Let's Encrypt's access to my site. Is there a way around this without disabling Cloudflare's protection? I prefer HTTP-01 validation as it's more simple and straightforward than the DNS challenge.

I confirmed that Cloudflare is the problem by pausing its protection, attempting a renewal dry run, and finding that succeeded. So, it seems that I will need to get comfortable configuring the DNS challenge if I want to continue using Cloudflare. :laughing:

Or use Cloudflares Cloudflare origin CA. It's not publicly trusted, but if your webserver only receives connections from the Cloudflare proxy, i.e., no regular user actually contacts your webserver, just CF, then Origin CA is fine. (Except for when you disable the CF proxy of course.)

If you want to keep using Let's Encrypt and use the dns-01 challenge with CF, then Welcome to certbot-dns-cloudflare’s documentation! — certbot-dns-cloudflare 0 documentation is probably a good option.

3 Likes

Thank you. I read through the plugin's documentation and have all my domains using DNS-01 challenges with Cloudflare. It wasn't as complicated as I thought it was going to be, so yay.

I am using Let's Encrypt to encrypt between my server and Cloudflare's. Following the advice to use Cloudflare's Origin CA is solid for most of my domains; however, there are a few that I bypass Cloudflare's proxy and access the server directly, so I'll keep using Let's Encrypt for that part, at least. Or I may just keep using Let's Encrypt as certbot is a lot easier to use than Origin CA's API.

Thank you, again, for your comment. I appreciate your input.

2 Likes

You would usually just get that certificate using the panel. It is a one time thing whereas certbot must renew the public cert every 60 days. Once it is set up it should be fine but sometimes things do go wrong.

Usually people find the origin ca to be much easier so I was surprised by your comment

2 Likes

The following configurations at Cloudflare have been successful for my HTTP-01 challenges.

2 Likes

While it seems the original issue has been resolved, what I would recommend for the future is look into Security Events tab in Cloudflare dashboard in order to identify the product that is the cause. You might e.g. search by path, or if you can get a block page directly through browser (footer of the block page) or curl (HTTP header), get a "Ray ID" and search for it.

Once identified, use Configuration Rule, similar to what @linkp mentioned to disable offending feature on the ACME path only.

2 Likes