Validation with wrong domain and slash before .well-known missing

Help
1

My domain is:
www.f-us.de

I ran this command:
sudo certbot certonly -n -m johndoe@mydomain.de -d www.f-us.de --standalone --preferred-challenges http-01 --agree-tos --http-01-port 115 --staging

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for www.f-us.de
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. www.f-us.de (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.domain-offensive.de.well-known/acme-challenge/6ZbFz_SE9rph94YU5IG9JuWd-OV3flmIQrxhKT8i-6c: Error getting validation data

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: www.f-us.de
    Type: connection
    Detail: Fetching
    http://www.domain-offensive.de.well-known/acme-challenge/6ZbFz_SE9rph94YU5IG9JuWd-OV3flmIQrxhKT8i-6c:
    Error getting validation data

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

My web server is (include version):
Apache/2.4.25 (Debian), but as I am using certbot standalone this should not matter

The operating system my web server runs on is (include version):
Debian 9.6 “stretch”

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine:
yes

I’m using a control panel to manage my site:
no

My Problem:
I am using certbot 0.10.2 from Debian “stretch” as that’s the newest version available there. My connection is by DSL and uses a dynamic IP address. The domain provider is www.domain-offensive.de and the IP address in the DNS entry matches that from e.g. www.whatismyip.com. Updating the IP address works as it should. External port 80 is routed to port 115 on my server. This should work and the error message suggests that this is not the problem.

To solve this problem I am currently using the staging system as rate limiting applied…

The URL that is fetched by the server is http://www.domain-offensive.de.well-known/acme-challenge/MY1RekDIVmwvr0kwyd4pb6zUXfeV9nOof7vlpiycOUY

This is URL contains 2 errors

  1. It is not the domain I specified (www.f-us.de), but the domain from my domain provider. I did not mention this domain at all during setup of my small server.

  2. The slash between the domain name and .well-known is missing creating a wrong domain. I read that this can be caused by wrong rewrite rules for the web server, but my web server is not running and I am using certbot in standalone mode. It might be the web server of my domain provider, which should not be contacted in the first place.

Why is Let’s Encrypt trying to access my domain provider?

2

The only reason Let’s Encrypt would try to access the “wrong” domain is if it received a redirect response when it made its initial request to the correct domain. So perhaps your domain was pointed at the wrong IP address, such as a holding page of your domain provider? It doesn’t seem to be, at the moment, at least from my vantage point here, but maybe it was when you tried earlier?

3

Please show:
certbot certificates

4

Hi @Bholnu_Zabimur

what says

There should be an order url, there urls of the challenges.

There should be the ip address used and the list of files Letsencrypt had tried to fetch.

So share your log, that we can find this information.

5

Thank you for the suggestions. The log file does not contain the IP address, but only the URL.

As all local checks showed no problem I checked the DNS entry. It contains a dynamic IPV4 entry and an unused IPV6 entry that was parked at my provider. There also was an unneeded Entry for f-us.de (without www) which was also parked.

After removing these two entries everything worked as expected and I suspect the IPV6 entry to be the cause. Due to the missing IP address in the log and in the error message it took longer to detect the cause. My local Tests always showed the correct IPV4 address.

6

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