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 domain is: m0dw3rks.com
I ran this command: /usr/bin/certbot renew --apache
My web server is (include version): apache 2.4.29
The operating system my web server runs on is (include version): Ubu 18.04
My hosting provider, if applicable, is:
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.31.0
Most the stuff above this seems irrelevant. I’ve searched around for this for weeks, trying various crap which all has failed. Error logs all seem filled with obvious but useless crap. Tonight I decided to try something else, which was disable the letsencrypt redirects and things finally worked.
The reason I’m posting this is to ask is there a way to “fix” this stupid behavior where LE adds (upon your OK) redirects from port 80 to 443 but then only checks the .well-known on port 80 which it has created a rule to basically fail with. i.e. can you make it check for .well-known on 443 rather than 80 since the LE client doesn’t follow the redirect.
Quick addendum don’t try x.m0dw3rks.com I just used X as a placeholder for any subdomain as they all fail for the same reason, the request is denied/redirected because the LE server connects on port 80.