Will Cloudflare proxy block certbot challenge?

Yes, flexible redirect setting causes too many redirect error.

certbot challange trys http, cf redirects it to https, and your origin server redirects back to http

3 Likes

Flexible breaks the sites I'm hosting with too many redirects.

You are saying these are mutually exclusive and I need flexible to work with the certbot challenge which breaks my site?

no flexible was the reason it was broken not sure what you were asking if you already fixed that

3 Likes

Correct, flexible was the reason it was broken. I changed it to full/strict as I said in my top post.

The question is: will Cloudflare proxy and their TLS set to Full/Strict interfere with certbot HTTP challenge?

From what little I understand the challenge happens over HTTP and cloudflare bouncing that to HTTPS might break it??

Certbot has a --dry-run mode for testing which can be very helpful for this.

As for Cloudflare, there are many options. These are just three:

One option is because Cloudflare is configured to redirect the HTTP Challenge to HTTPS you need to have your origin server handle the challenge in its HTTPS server block.

Another option is to use CF page rule so the HTTP challenge is not redirected. See linkp comment (link here) or the Cloudflare page rule docs (link here)

Another option is to use a Cloudflare Origin CA Cert on your origin server. Then, you don't use a Let's Encrypt cert on your origin at all. The CF Origin CA cert is long-lived. (link here)

5 Likes

I forgot about that! I was very much not expecting this error;

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
An unexpected error occurred:
The server will not issue certificates for the identifier :: Error creating new order :: Cannot issue for "ry-run": Domain name needs at least one dot
Please see the logfiles in /var/log/letsencrypt for more details.

The only thing I changed recently was this;

    #root /var/www/html;  #this WAS the default folder
    root /var/www/jalbert.me/html; # my site

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.htm index.nginx-debian.html;  # added htm

I don't get any results with this below so I don't think certbot uses that folder??

egrep "/var/www/html" letsencrypt.log

I'm going to turn cloudflare proxy off and try again after a while.

I think your --nginx plug-in should work

But, it's --dry-run added to that command not -dry-run

3 Likes

Thanks I struggle with CLI sometimes. I was missing the dash and the renew command, but I did this and it is happy.

sudo certbot renew --dry-run

I'm going to turn on CF proxy again and try this again in a while.

2 Likes

OK, looks like we are good. I waited a while and I'm definitely seeing cloudflare IP for my site. Cloudflare proxy is turned ON and SSL/TLS in Cloudflare is set to Full (strict). Certbot dry run says it is happy still.

Thank you everybody!

2 Likes

When using any CDN, you should not expect to see any HTTP connections to your server.
If you do, the last thing you need to do is to redirect them to HTTPS.
[that should be done by the CDN]
When you do, you might be redirecting what you think is an HTTP connection to HTTPS, but it might have already been an HTTPS connection it was just being proxied by the CDN to your server via HTTP.
If so, that creates an endless redirection loop to the originating client.
When they request HTTP:
HTTP > HTTPS > HTTPS > HTTPS ...
When they request HTTPS:
HTTPS > HTTPS > HTTPS > HTTPS ...

3 Likes

Yes, in my case I wasn't considering what the Cloudflare reverse proxy was doing. When set wrong it seems it was asking for http from my back end site leading to the loop. According to the listen statement certbot adds to the nginx config it's only listening on 80, and if Cloudflare is set right the back end server only ever sees https. Or at the very least it doesn't attempt the 301 independently, lets the back end server do it and not fight?

This is exactly what lead to my question, where does this leave the certbot challenge? I still don't exactly know but it seems to work. Maybe Cloudflare has a stock exception for the challenge? Maybe it will accept the challenge over https? I haven't really found the hook certbot listens on in the nginx config.

But this is the redirect certbot adds to the nginx sites configured:

server {
if ($host = www.jalbert.me) {
return 301 https://$host$request_uri;
} # managed by Certbot

if ($host = jalbert.me) {
    return 301 https://$host$request_uri;
} # managed by Certbot

    listen 80;
    listen [::]:80;

    server_name jalbert.me www.jalbert.me;
return 404; # managed by Certbot

}

Yes, that's the redirect and what caused trouble when you were using Flex in Cloudflare.

Flex means Cloudflare always uses HTTP to your Origin. Your Origin then redirected that to HTTPS. So, the browser responded by sending in that HTTPS request which Cloudflare converted to HTTP to your Origin and repeats forever.

But, you fixed that by using Full(Strict)

The server block you show now is only the one for HTTP (port 80). There is also a server block for port 443 which has your cert definitions.

When using the --nginx plug-in Certbot adds temp code to both port 80 and port 443 server blocks so it will see the challenge from Cloudflare even on HTTPS

With a CDN there are two distinct comms interactions. One is between the client (browser) and the CDN and the other between the CDN and the Origin Server.

3 Likes

True, I see it too. I was looking for something on 80 that might pertain to the challenge.

That I did not know, and I guess that solves the question. Thank you.

3 Likes

As of Certbot v1.13.0 (released March 2021), Certbot's --nginx plugin added support for authenticating your domain when using Cloudflare's Full (Strict) setting. From this version, Certbot will set up the nginx challenge for both port 80/HTTP and port 443/HTTPS.

Prior to Certbot v1.13.0, you would either have to use Cloudflare's Flexible setting, or use the --webroot plugin. because Certbot would only set the nginx challenge up on port 80/HTTP.

If you intend to use Cloudflare on Full (Strict), then I strongly suggest that you use a newer version of Certbot, either from the snap or pip.

3 Likes

Hmm. Yes, of course you know the proper version numbers. The snap version should be easiest on Ubuntu 20.

That said, the certbot renew --dry-run worked after Full(Strict) was in place.

So, some info is mis-matched. @Nephilimi can you confirm the certbot version with:

sudo certbot --version
3 Likes

certbot 0.40.0 is what I have.

I will look into updating this today. I have no idea where I originally got certbot from, in those days it might have been a package download.

I assume I can install the snap version right on top of this without breaking anything?

Just follow the instructions here

4 Likes

Super easy, I'm feeling pretty good about my Let's Encrypt donations. Thanks again!

user@computer:/etc/nginx/sites-enabled$ sudo certbot --version
certbot 1.32.2
user@computer:/etc/nginx/sites-enabled$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/jalbert.me.conf


Simulating renewal of an existing certificate for jalbert.me and 3 more domains


Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/jalbert.me/fullchain.pem (success)


user@computer:/etc/nginx/sites-enabled$ ping jalbert.me
PING jalbert.me (172.67.138.173) 56(84) bytes of data.
64 bytes from 172.67.138.173 (172.67.138.173): icmp_seq=1 ttl=55 time=25.9 ms
64 bytes from 172.67.138.173 (172.67.138.173): icmp_seq=2 ttl=55 time=31.0 ms
^C
--- jalbert.me ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 25.908/28.462/31.017/2.554 ms

I wonder why the apt version is so old? The instructions included removing old versions and this is what I discovered;

user@computer:~$ sudo apt-get remove certbot
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
jsvc libcommons-daemon-java libfwupdplugin1 libjs-jquery-hotkeys libxmlb1 python3-acme python3-certbot python3-configargparse python3-future python3-icu python3-josepy python3-mock python3-parsedatetime python3-pbr python3-pyparsing python3-requests-toolbelt python3-rfc3339 python3-zope.component
python3-zope.event python3-zope.hookable
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
certbot python3-certbot-nginx
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 337 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 138735 files and directories currently installed.)
Removing python3-certbot-nginx (0.40.0-0ubuntu0.1) ...
Removing certbot (0.40.0-1ubuntu0.1) ...

2 Likes

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