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
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?
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?
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.
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
#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