Acme Challenge Location NGINX

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
gamerstechsupport.com
I ran this command:
sudo certbot certonly -v --dry-run --nginx -d gamerstechsupport.com
It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Simulating a certificate request for gamerstechsupport.com
Performing the following challenges:
http-01 challenge for gamerstechsupport.com
Waiting for verification...
Challenge failed for domain gamerstechsupport.com
http-01 challenge for gamerstechsupport.com

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: gamerstechsupport.com
  Type:   unauthorized
  Detail: 2606:4700:3033::6815:3d80: Invalid response from http://gamerstechsupport.com/.well-known/acme-challenge/YdmBKl2JhGtULLY6HXj1cGcBrSu2NknGWPu0S8Jf404: 404

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.

Cleaning up challenges
Some challenges have failed.
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/1.18.0
The operating system my web server runs on is (include version):
Ubuntu 22.04
My hosting provider, if applicable, is:
Selfhosted
I can login to a root shell on my machine (yes or no, or I don't know):
yes as sudoer user
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 1.21.0

So I am in the process of moving adding a reverse proxy hosted by ovh to my webstack in order to use their IPs instead of my residential IP. The connection between the VPS and my locally hosted reverse proxy is over a wireguard vpn. since I have the vpn im going to be terminating https at the vps for simplicity instead of needing to copy certs all over the place. I have multiple TLDs and subdomains hosted on my current setup but the one we can use for this is listed above. the Let's Debug output for gamerstechsupport.com looks fine but im still having the acme issue. different sites are bound to different IPs. i created a test file at /var/www/html/.well-known/acme-challenge and can access it just fine with

https://gamerstechsupport.com/.well-known/acme-challenge/test.html

I am thinking the issue might be with the location block but every example ive seen has it setup similarly...

Since I am terminating https at this server i needed to add a location block for acme challenges from my understanding.

heres the .conf for that TLD

server {
        listen IPWASHERE:80;
        server_name gamerstechsupport.com;

        # General proxy settings
        proxy_buffering off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_read_timeout 600;
        proxy_connect_timeout 300;
        proxy_redirect off;
        client_body_buffer_size 2048M;

        # ACME challenge location
        location ^~ /.well-known/acme-challenge/ {
            root /var/www/html;
            default_type text/plain;
        }

        location / {
            proxy_pass http://10.10.10.2;
        }
    }

Realizing I was using the old version of certbot I installed the latest from Snap but am still having the same problem. New certbot version is certbot 2.10.0

Does this command give same error (the 404?).

sudo certbot certonly --dry-run --webroot -w /var/www/html -d gamerstechsupport.com

As an aside, why do you need to specify the IP address here? Doesn't listen 80; work?

3 Likes

Ive never used the webroot command before. does webroot work for reverse proxies where the sites are located on different machines with their own webservers?
as for the ip yes each of the sites has its own dedicated ip it sends and receives on. if i didnt specify the ip there then each site would use all available ips.

You already have a specific location directive for the path /.well-known/acme-challenge/ which is used by the http-01 challenge, which is also used by the webroot authenticator. So it's probably even the easiest solution, as your nginx is already set up for it.

No, and neither does the --nginx method. They both interact with nginx and not the servers it proxies to.

Your nginx system is the one that should respond to the challenge.

The --nginx method you tried in your first post failed with a 404. A 404 is "Not Found" which means something went wrong with Certbot's temp changes to your nginx config to satisfy the challenge.

I suggested --dry-run --webroot as a diagnostic tool to isolate where this might be going wrong.

Are you running Certbot on a machine that controls that nginx? Or did you run it on the server it proxies to?

2 Likes

So the sudo certbot certonly -v --dry-run --webroot -w /var/www/html -d gamerstechsupport.com

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Simulating a certificate request for gamerstechsupport.com
Performing the following challenges:
http-01 challenge for gamerstechsupport.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
The dry run was successful.

you suggested worked fine! I need to do some reading up on webroot lol.

So I did some light reading that I really should have done a long long time ago and learned that you can mix and match authenticators and installers... I now have a working command
sudo certbot -v -a webroot -i nginx -w /var/www/html -d gamerstechsupport.com
i am curious as to why the nginx authenticator doesnt work though. any ideas as to why?

mixing and matching auth and installer plugins worked great but im having issues understanding why...

sudo certbot -v --dry-run -a webroot -i nginx -w /var/www/html -d gamerstechsupport.com
--dry-run currently only works with the 'certonly' or 'renew' subcommands ('run')
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /tmp/certbot-log-ov9v7ucp/log or re-run Certbot with -v for more details.
ubuntu@vps-fa0967f5:~$ sudo certbot certonly -v --dry-run -a webroot -i nginx -w /var/www/html -d gamerstechsupport.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer nginx
Simulating a certificate request for gamerstechsupport.com
Performing the following challenges:
http-01 challenge for gamerstechsupport.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
The dry run was successful.
ubuntu@vps-fa0967f5:~$ sudo certbot -v -a webroot -i nginx -w /var/www/html -d gamerstechsupport.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer nginx
Requesting a certificate for gamerstechsupport.com
Performing the following challenges:
http-01 challenge for gamerstechsupport.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/gamerstechsupport.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/gamerstechsupport.com/privkey.pem
This certificate expires on 2024-07-16.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/gamerstechsupport.com.conf
Successfully deployed certificate for gamerstechsupport.com to /etc/nginx/sites-enabled/gamerstechsupport.com.conf
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/gamerstechsupport.com.conf
Congratulations! You have successfully enabled HTTPS on https://gamerstechsupport.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ubuntu@vps-fa0967f5:~$ sudo nano /etc/nginx/sites-enabled/gamerstechsupport.com
ubuntu@vps-fa0967f5:~$ sudo nano /etc/nginx/sites-enabled/gamerstechsupport.com.conf
ubuntu@vps-fa0967f5:~$ sudo certbot --nginx rollback
Saving debug log to /var/log/letsencrypt/letsencrypt.log
ubuntu@vps-fa0967f5:~$ sudo nano /etc/nginx/sites-enabled/gamerstechsupport.com.conf
ubuntu@vps-fa0967f5:~$ sudo certbot -v -a webroot -i nginx -w /var/www/html -d gamerstechsupport.com --nginx rollback
Saving debug log to /var/log/letsencrypt/letsencrypt.log
ubuntu@vps-fa0967f5:~$ sudo nano /etc/nginx/sites-enabled/gamerstechsupport.com.conf
ubuntu@vps-fa0967f5:~$ certbot certificates
The following error was encountered:
[Errno 13] Permission denied: '/var/log/letsencrypt/.certbot.lock'
Either run as root, or set --config-dir, --work-dir, and --logs-dir to writeable paths.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /tmp/certbot-log-5iwrp3ls/log or re-run Certbot with -v for more details.
ubuntu@vps-fa0967f5:~$ sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: gamerstechsupport.com
    Serial Number: 30d2933c649a384641c49d501b5ea84e8f2
    Key Type: ECDSA
    Domains: gamerstechsupport.com
    Expiry Date: 2024-07-16 20:31:00+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/gamerstechsupport.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/gamerstechsupport.com/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ubuntu@vps-fa0967f5:~$ sudo certbot revoke --cert-name gamerstechsupport.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you like to delete the certificate(s) you just revoked, along with all
earlier and later versions of the certificate?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es (recommended)/(N)o: Y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certificate(s) are selected for deletion:

  * gamerstechsupport.com

WARNING: Before continuing, ensure that the listed certificates are not being
used by any installed server software (e.g. Apache, nginx, mail servers).
Deleting a certificate that is still being used will cause the server software
to stop working. See https://certbot.org/deleting-certs for information on
deleting certificates safely.

Are you sure you want to delete the above certificate(s)?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y
Deleted all files relating to certificate gamerstechsupport.com.
Congratulations! You have successfully revoked the certificate that was located at /etc/letsencrypt/live/gamerstechsupport.com/cert.pem.

Since webroot worked that points to an unusual incompatibility between what the --nginx plugin is expecting and what your nginx config looks like.

Your later test with --nginx installer was affected by you also using certonly which cancels the effects of the installer. The --nginx plugin won't work as installer if it can't work as authenticator. It needs to identify and update the proper server block but something is making that fail.

The next step is to look at your nginx config. Please post the entire output of the below command. An upper case T is essential. The output will be long. Please add 3 backticks before and after so formatting is maintained like
```
output of command: sudo nginx -T
```

Or, pipe output to a .txt file and upload that in a post
sudo nginx -T >config.txt

And, why did you revoke the cert? That just invalidated the one you got

2 Likes

This entire thread is not surprising to me, and why I pretty much always suggest people with complex configurations – or who have active proxypass configurations – use the standalone mode with --http-01-port=8080 or similar and then just proxypass the challenge directory to that port.

I suggest exploring that usage in this situation. IMHO, it is easier to test and fewer things go wrong.

@cpjet64 something related that popped out at me is all your general proxy_ prefix settings were declared within the block. the common pattern of doing that in nginx is to have all of those settings defined in a single "macro" file like proxy_settings.conf, and then include /path/to/proxy_settings.conf whenever it is needed.

2 Likes

So from my testing with mixing and matching authenticator and installers the installer properly modified the .conf. I revoked the cert because I want to script this as I have 12 other domain names that need certs. I basically just rolled all changes and certs back so I could continue testing on a single domain from scratch.
Here is the pastebin for the output of -T # configuration file /etc/nginx/nginx.conf:user www-data;worker_processes au - Pastebin.com

I am still learning the intricacies of certbot but would standalone mode allow me to get 1 certificate per TLD/sub?

As for the proxy settings... Several of the sites behind the proxy have unique settings so I keep all the settings in each individual .conf for ease of access.

Before we go any further I want to thank everyone who has jumped in this thread and helped. It is very much appreciated!!!

1 Like

So I was experimenting some more... And I discovered something... Apparently, if you have a location block for acme challenges the nginx plugin fails! Removing the location block for acme challenges now has the normal command working fine... Apparently the acme challenge location block is only to be used for webroot authentication.

sudo certbot -v --nginx -d gamerstechsupport.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Requesting a certificate for gamerstechsupport.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/gamerstechsupport.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/gamerstechsupport.com/privkey.pem
This certificate expires on 2024-07-16.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/gamerstechsupport.com.conf
Successfully deployed certificate for gamerstechsupport.com to /etc/nginx/sites-enabled/gamerstechsupport.com.conf
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/gamerstechsupport.com.conf
Congratulations! You have successfully enabled HTTPS on https://gamerstechsupport.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I cant find any documentation stating such though.

That is not usually the case. The --nginx plugin does not need that location block as it inserts its own code temporarily to handle the challenge.

In my own test systems I alternate between these methods often when helping people and have never seen that kind of location block be the reason for a failure.

The temp changes look like below. You can also see this in the /var/log/letsencrypt log file. Extra location blocks are just left in place.

I did notice the error message in your first post was for an IPv6 address but you don't have a listen clause for IPv6 (only IPv4). But, you are using Cloudflare so that makes it harder for me to debug (not impossible but takes a careful approach).

server {rewrite ^(/.well-known/acme-challenge/.*) $1 break; # managed by Certbot

    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/html;

location = /.well-known/acme-challenge/MxkxRxkxzxkxgxHxvxkxOxpxkxVxkx8xkx4xFxExuxg {default_type text/plain;return 200 MxkxRxkxzxkxgxHxvxkxOxpxkxVxkx8xkx4xFxExuxg.AwQwgwgwzwgwJwgw4wew3wrwxwiw-wpwvwqwxwBwswT;} # managed by Certbot

}
1 Like

Please don't revoke perfectly good certs.
Just DELETE them when you no longer need them.

3 Likes

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