Could not connect to .well-known

Please provide output of:
sudo netstat -plant | grep “:80”

tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 7007/apache2
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 7007/apache2
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN 7007/apache2
tcp 0 0 85.25.210.22:8080 91.65.64.238:7047 TIME_WAIT -
tcp 0 0 85.25.210.22:8080 91.65.64.238:7048 TIME_WAIT -
tcp 0 0 85.25.210.22:8080 91.65.64.238:7043 TIME_WAIT -
tcp 0 0 85.25.210.22:50970 108.161.187.134:80 TIME_WAIT -
tcp 0 0 85.25.210.22:8080 91.65.64.238:7045 TIME_WAIT -
tcp 0 0 85.25.210.22:8080 91.65.64.238:7044 TIME_WAIT -
tcp 0 0 85.25.210.22:50971 108.161.187.134:80 TIME_WAIT -
tcp 0 0 85.25.210.22:8080 91.65.64.238:7046 TIME_WAIT -

You’ve asked it to run the acme challenge on port 80 but your apache instance is already bound to 80 on all interfaces:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 7007/apache2

Try stopping apache and then rerunning the command.

It doesn’t help. I am wondering because, when the apache isn’t working, LE is uanble to connect and verify the client.

@sleepypikachu: --webroot doesn’t bind to any port, it just puts challenge files in a directory. The existing web server (apache) is supposed to serve the challenge files.

@MikeFrizz: Take a look at my reply (example.com is your domain in this example):

1 Like

D’oh. My bad, thanks for clearing that up.

I have a directory called .well-known only. There is no directory in there.

The client automatically deletes it afterwards. Try putting a test file in .well-known/acme-challenge and try browsing to it.

After I manually created a directory acme-challenge, I could display the contents of the file TEST in the browser.

Is one of the affected domains behind a firewall that blocks access from the public internet?

If you wouldn’t mind sharing the URL to your test file, that would probably help analyze the problem. Note that all domains you request a certificate for a published to Certificate Transparency log servers, so they are in some way already public anyway.

Try:
https://www.beulenrechner.de/.well-known/acme-challenge/test

Looks good to me. Try running the client with -vvvv and paste the contents of /var/log/letsencrypt/letsencrypt.log here.

i.e.:

sudo /opt/letsencrypt/letsencrypt-auto certonly --webroot --rsa-key-size 4096 -w /var/www/clients/client2/xyz.de/web/ -d www.xyz.de1 -d xyz.de -vvvv

Sorry. Did not work.

Not sure I follow. What did the client return? What’s in your /var/log/letsencrypt/letsencrypt.log?

https://www.beulenrechner.de/.well-known/acme-challenge/letsencrypt

Your non-HTTPS website redirects to the HTTPS variant of the same website. But the HTTPS site is “”“protected”"" by a self-signed certificate.

While a redirect isn’t going to be a problem (it shouldn’t anyway), I think a redirect to an invalid TLS secured site isn’t going to work.

You could try to disable redirecting for the /.well-known/acme-challenge/ location.

This here is the snippet , which necessary must be entered in the Apache directives sections. As I said I used ispconfig.

The problem must be caused by a change in the LE clients recently.

# Verzeichnis für Let's Encrypt Webroot Methode
<IfModule mod_headers.c>
    <LocationMatch "/.well-known/acme-challenge/*">
        Header set Content-Type "text/plain"
    </LocationMatch>
</IfModule>
# Immer Umleiten auf https
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>

@Osiris: Self-signed or expired certificates are generally fine when used with http-01 - the validation is based on the IP address returned by DNS and something that IP address serves in cleartext without authentication, so if that connection is compromised, it’s game over anyway.

I’ve seen some issues where boulder was unable to connect because of a self-signed SHA-1 certificate, so it could still be related to the certificate, although this one isn’t SHA-1. I tried debugging this using a local CA server (boulder), but it’s succeeding (as in: I’m getting an expected HTTP 404, and not a “general” connection error). Could be a configuration difference between what I’m running and the production boulder instance, though.

@MikeFrizz: Here is one more idea on how to avoid redirecting to HTTPS for .well-known/acme-challenge. Add the following line:

RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/

right before

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

If Let’s Encrypt is still reporting a connection error with your next run, it’s not related to your SSL configuration, but rather some network issue.

1 Like

You did it. Thx a lot.

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