Renew/expand etc failing .well-known challenge due to LE redirect

Help
1

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

It produced this output:
Domain: x.m0dw3rks.com
Type: connection
Detail: Fetching
x.m0dw3rks.com
Connection refused

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.

2

Sorry but authentication purely by port 443 would only be possible via TLS-ALPN.
[which is not generally supported by ACME clients nor web servers - but I would recommend that you do take the extra effort to go that route, if you can]

1 Like
3

Hi @nPHYN1T3

that's

wrong. Letsencrypt follows redirects http / port 80 -> https / port 443.

You can create redirects to another domain, that works.

Read

If that didn't work with your setup, you have another error.

If you use --apache, the redirect is overwritten, so Letsencrypt connects only port 80.

Or you have a configuration that doesn't work with the --apache plugin.

4

@JuergenAuer when the challenge comes in my logs show it hitting port 80 then dying. It does not follow the redirect to 443 based on the rules LE added to the config.

@rg305 I’d think there would be a sensible if then for the rewrite rules so if the request is coming in on port 80 AND matches .well-known (just fork it over) else redirect to secure address on port 443. I’ll have to putz around with the rewrite rules.

5

@JuergenAuer I just peeked at newer logs since I was fooling with this and it does look like it’s following the redirect now. Sadly I have tried so much crap in the last while but separated by a week or so at a time who knows which thing did what. However it does still fail with a 403. If I disable the LE SSL redirects when I update certs they succeed.

If I remove --apache the process stalls with the prompt of how to authenticate which kills renewing. I will fool more. I haven’t been overly focused on this to really line up all the testing and systematically eliminate things correctly. I have far too much on my plate and this just started happening so it was definitely an “AH F@#$ I’ll deal with that later…sigh” moment.

Frankly I’d like to wipe it all and start fresh as this feels like a mess of trial cruft and error now.

1 Like
7

I just got the email about the vulnerability in LE certbot and the only way I can get the .wellknown to work is by removing all the redirects but then it will fail anyhow because when it tries to restart / reload apache it expects all the includes I had to remove to load the new certs.

8

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