v20 certbot not working

Bergwerk IT

Silver Partner
Joined
Dec 18, 2020
Messages
17
Reaction score
0
after adding a letsencrypt snippet containing the following to nginx, creating the directory structure and adding a ping.txt file containing "pong" I can reach this at http://3cx.domain.tld/.well-known/acme-challenge/ping.txt. This can be reached per browser using HTTP as well as CURL. However, after installing certbot and setting "webroot-path = /var/www/letsencrypt" in /etc/letsencrypt/cli.ini and running certbot certonly --debug-challenges -v --test-cert --webroot -d 3cx.domain.tld -w /var/www/letsencrypt it fails. This same process works on all other debian boxes we have that is running either Apache or NginX.

Code:
#############################################################################
# Configuration file for Let's Encrypt ACME Challenge location
# This file is already included in listen_xxx.conf files.
# Do NOT include it separately!
#############################################################################
#
# This config enables to access /.well-known/acme-challenge/xxxxxxxxxxx
# on all our sites (HTTP), including all subdomains.
# This is required by ACME Challenge (webroot authentication).
# You can check that this location is working by placing ping.txt here:
# /var/www/letsencrypt/.well-known/acme-challenge/ping.txt
# And pointing your browser to:
# http://xxx.domain.tld/.well-known/acme-challenge/ping.txt
#
# Sources:
# https://community.letsencrypt.org/t/howto-easy-cert-generation-and-renewal-with-nginx/3491
#
#############################################################################

# Rule for legitimate ACME Challenge requests (like /.well-known/acme-challenge/xxxxxxxxx)
# We use ^~ here, so that we don't check other regexes (for speed-up). We actually MUST cancel
# other regex checks, because in our other config files have regex rule that denies access to files with dotted names.

location ^~ /.well-known/acme-challenge/ {

    allow all;

    proxy_redirect off;

    # Set correct content type. According to this:
    # https://community.letsencrypt.org/t/using-the-webroot-domain-verification-method/1445/29
    # Current specification requires "text/plain" or no content header at all.
    # It seems that "text/plain" is a safe option.
    default_type "text/plain";

    # This directory must be the same as in /etc/letsencrypt/cli.ini
    # as "webroot-path" parameter. Also don't forget to set "authenticator" parameter
    # there to "webroot".
    # Do NOT use alias, use root! Target directory is located here:
    # /var/www/common/letsencrypt/.well-known/acme-challenge/
    root         /var/www/letsencrypt;

    try_files $uri =404;

    break;
}

# Hide /acme-challenge subdirectory and return 404 on all requests.
# It is somewhat more secure than letting Nginx return 403.
# Ending slash is important!
location = /.well-known/acme-challenge/ {
    return 404;
}

If anyone has any idea how this could happen please let me know.

thx
chuck
 
funny how audio works on our internal LAN/VPN and not the external address.
 

Forum statistics

Threads
111,956
Messages
589,927
Members
164,859
Latest member
MichaelRussell3