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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My web server is (include version):
Apache 2.4.25 (Debian)
The operating system my web server runs on is (include version):
Debian Stretch, patched to current
My hosting provider, if applicable, is:
Linode
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):
certbot 0.28.0
I can see what the problem is, I just have no idea how to fix it. If you look at the URL above, certbot is attempting to verify at https://epyc.org.well-known/acme… instead of https://epyc.org/well-known/acme… It’s a simple matter of a “.” that should be a “/”. I’ve tried both the Debian packaged certbot, and the certbot-auto installed version. No difference. Is there a parameter that I can pass to force the generated URL to be correct?
The bad redirect comes from Apache. You need to add a trailing slash.
It appears that a redirect was generated by your web server that is missing a trailing slash after your domain name: https://epyc.org.well-known/acme-challenge/letsdebug-test. Check your web server configuration and .htaccess for Redirect/RedirectMatch/RewriteRule.
Figured out the permissions issue - it may be Debian specific.
Certbot creates the necessary config entries, pointing them at .well-known/acme-challenge. Unfortunately, certbot then creates the verification files in /var/lib/letsencrypt/http_challenges. Which isn’t in the web root, and not where the url rewrite rules point. Which is pretty useless.
Quick & Dirty solution: remove the acme-challenges subdirectory, and create a link there that points back to the dir in /var/lib, with the necessary permissions. Voila! Certbot creates the rewrite rules, creates the verification file in the wrong place, and serves it up properly via the link. Fixed now, and hopefully for future renewals.
The idea in the Apache authenticator/plugin is that it injects temporary configuration that directs the challenge requests towards that other, non-web root directory. This is the simplest approach because otherwise it would have to also go hunting for .htaccess files etc that might be interfering.
Occasionally it has been known to be incompatible with certain exotic or incorrect configurations (mod_jk, mod_uwsgi, duplicate virtualhost names), but it mostly "just works".
If you can post the full Apache config where it didn't work for you, that could form the basis for a bug report.
The changes you made shouldn't be necessary, but i'm happy to hear that it's working for you now.
Hmmm. Not sure what you want in the way of "full Apache config", but this is the site .conf file contents Note the date at top - that's how long ago I first setup LetsEncrypt SSL certs on this server. Had been working fine until this year. I deleted the # at the beginning of the line, as the forum was insisting on BOLDing that line.
It’s the port 80 virtual hosts that can help diagnose this - since that’s where the validation occurs. Because the malfunctions sometimes are caused by the way that the entire Apache configuration combines together, the best way is to create an archive of the entire /etc/apache2/ directory (excluding any log or other sensitive directories).
Visible Content: Not Found The requested URL /.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de was not found on this server. Apache/2.4.25 (Debian) Server at epyc.org Port 443
Your 443 vHost has
DocumentRoot /var/www/epyc.org
as DocumentRoot. So use this to create a new certificate:
certbot run -a webroot -i apache -w /var/www/epyc.org -d epyc.org -d www.epyc.org
