Well-known/acme-challenge error . missing /

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:
hempenings.com
I ran this command:
sudo certbot -v renew --dry-run
It produced this output:
IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: hempenings.com
    Type: connection
    Detail: Fetching
    https://hempenings.com.well-known/acme-challenge/hR4aH4vbr876gXT7WoHCXQLCHQqsZFK7XINClM94mUE:
    Invalid host in redirect target "hempenings.com.well-known". Check
    webserver config for missing '/' in redirect target.
    My web server is (include version):
    apache2 2.4.38-3+deb10u4
    The operating system my web server runs on is (include version):
    debian 10
    My hosting provider, if applicable, is:
    self
    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):
    0.31.0

The

1 Like

Welcome to the Let's Encrypt Community, Stuart :slightly_smiling_face:

This is likely something in your Apache configuration or .htaccess files.

What is the output of:

sudo apachectl -S

1 Like

user@janusblog:~$ sudo apachectl -S
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:443 janusblog.com (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
*:80 127.0.1.1 (/etc/apache2/sites-enabled/000-default.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33
user@janusblog:~$

1 Like

Thanks for that. :slightly_smiling_face:

Let's take a look. :mag:

What are the outputs of:

sudo certbot certificates
sudo ls -lRa /etc/letsencrypt
sudo ls -lRa /etc/apache2/sites-available
sudo ls -lRa /etc/apache2/sites-enabled
sudo cat /etc/apache2/sites-enabled/000-default.conf
sudo cat /etc/apache2/sites-enabled/000-default-le-ssl.conf

Please put 3 backticks above and below each output, like this:

```
output
```

1 Like

It appears like I may need to move all of my certificates into the reverse proxy vm. I have about 7 vms running letsencrypt ssl certs, doing individual vm's for each page I serve. The odd part is that one of them has updated 12 generations of keys doing the update in the target vm.

Anyway, the simple question is...

When working behind an apache2 proxy, does the ssl key need to be on the proxy or the machine running the web server?

Thanks,

Stuart

1 Like

The short answer is that the certificate and its private key need to be on the device "terminating ssl", which is typically the reverse proxy server (or load balancer when in play). This prevents needing to "poke holes" in your reverse proxy or issue individual certificates (or make copies) to workers in a load balancing situation.

Obviously if you choose to terminate ssl at your reverse proxy server, you will want to ensure that the connection between your reverse proxy server and your actual webserver is secure.

They are VM's running on the same host, and said host is only exposed to the internal network. The internal network can only be reached internally or via an OPEN VPN connection.

What I'm not understanding is how one of the servers has renewed through 12 generations of the keys at the individual VM but now won't renew except at the proxy. The issue seems to be the lack of a slash in the verification URL. Is this a known issue?

Stuart

1 Like

The missing slash is normally a result of a rule that generates an HTTP 301 redirect but slightly incorrectly, where that rule needs to be updated to add a slash to it. That rule could be in your end server or in the reverse proxy configuration.

1 Like

That is what I am thinking, but how to fix it? I haven't changed anything in recent times, except I did change the external IP address...moved my whole setup.

My reverse proxy 000-default.conf contents...for ONE of the several pages I run

#ALWAYS redirect http://xxxxxx.com to https://xxxxxx.com
<VirtualHost *:80>
ServerName xxxxxx.com
ServerAlias xxxxxx.com *.xxxxxx.com
ServerAdmin nobody@nowhere.com
Redirect permanent / https://xxxxxx.com

#Reverse proxy to the specific VM running this...
<VirtualHost :443>
ServerName xxxxxx.com
ServerAlias xxxxxx.com .xxxxxx.com
ServerAdmin nobody@nowhere.com
SSLEngine On
SSLProxyEngine On
ProxyRequests Off
ProxyPreserveHost On
SSLCertificateKeyFile /etc/letsencrypt/live/xxxxxx.com/privkey.pem
SSLCertificateFile /etc/letsencrypt/live/xxxxxx.com/fullchain.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ProxyHTMLInterp On
ProxyHTMLExtended On
ProxyHTMLURLMap (.
)192.168.1.27(.
) https://xxxxxx.com$2 [Rin]
ProxyPass / https://192.168.1.27/
ProxyPassReverse / https://192.168.1.27/
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

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