Certbot failes to authentication

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. crt.sh | 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:
iotserver.st

I ran this command:
used swag with docker-compose.

swag:
    image: ghcr.io/linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Stockholm
      - URL=iotserver.st
      - SUBDOMAINS=www
      - VALIDATION=http
      - EMAIL=iotserverbackup@gmail.com
#      - CERTPROVIDER=zerossl
    volumes:
      - ~/iotstack/swag/data/config:/config
    ports:
      - xx:443
      - xx:80
    restart: unless-stopped

It produced this output:

Requesting a certificate for iotserver.st and www.iotserver.st
Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
  Domain: iotserver.st
  Type:   unauthorized
  Detail: 94.254.0.48: Invalid response from http://iotserver.st/.well-known/acme-challenge/qENS1AtHda4LS0WwrAmVWmdGozYvEvo0c8eoVJo53B4: "\n<html>\n<head>\n<META name=\"description\" content=\"iotserver\">\n<META name=\"keywords\" content=\"\">\n<title>iotserver</title>\n</head>\n"
  Domain: www.iotserver.st
  Type:   unauthorized
  Detail: 94.254.0.48: Invalid response from http://www.iotserver.st/.well-known/acme-challenge/Tnfgve_3MGAiHMAUIWpcFb18NYffVZJmu1YLVU167xQ: "\n<html>\n<head>\n<META name=\"description\" content=\"iotserver\">\n<META name=\"keywords\" content=\"\">\n<title>iotserver</title>\n</head>\n"
Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container

My web server is (include version):
? Lates docker image..

The operating system my web server runs on is (include version):
Ubuntu 20.04

My hosting provider, if applicable, is:
Through my isp.

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 --version = 1.27.0

Banging my head at this since I don't have much experience... Please ask me the right questions! :slight_smile:

1 Like
2

The first question is are you sure your DNS A record is pointing to the right IP? And, any routing to your container is correct?

Because you say you are using Ubuntu but a request to that domain shows Apache on CentOS in the header.

curl -I iotserver.st

HTTP/1.1 200 OK
Date: Wed, 11 May 2022 18:35:23 GMT
Server: Apache/2.2.15 (CentOS)
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
10 Likes
3

Could there be some firewalls or such that my isp use (same that provide the domain)? Or is it normal to have other ip to their server that hand out the ip to my domain? I can't remember exactly how but I did something yesterday that showed an ip starting with two digits..

I'm so lost :sweat_smile:

1 Like
4

The first step in getting a Let's Encrypt cert using an HTTP challenge is to make sure you have a working HTTP site.

If you go to your site in a browser do you see the response you expect? Use a cell phone connection (not wifi) to check result from the public internet.

11 Likes
5 

PORT    STATE    SERVICE
22/tcp  filtered ssh
80/tcp  filtered http
443/tcp filtered https
8 Likes
6

That hides too much.

10 Likes
7

44301:443
8001:80

Forward (unifi) 44301 to server-ip:443 and 8001 to server-ip:80.

I thought swag would setup a site for me when everything is ok?

At the moment, all I see is a sad face in chrome (connection rejected?).

8

HTTP authentication will require external port 80 to reach your ACME client system.
That means:
80:80

OR
You must have some way for external 80 going to [Your Site FQDN] to reach your system.
Which can be done by using a reverse proxy on the main system.

9 Likes
9

I see that i probably explained it wrong...

Unifi firewall forwards 80 to 8001 which is connected to 80 in the docker container... I'll try to deactivate all port forwards and just do 80:80..

Edit: i just revieved word from my isp (also domain provider) and they have no blockings on port 80. Good to know.

10

I did some tcptraceroute from the same server... Any comments?

tcptraceroute MYPUBLICIP 80
Selected device enp0s31f6, address 192.168.1.59, port 49183 for outgoing packets
Tracing the path to MYPUBLICIP on TCP port 80 (http), 30 hops max
1 h-178-174-175-127.A193.priv.bahnhof.se (MYPUBLICIP) 0.477 ms 0.450 ms 0.476 ms
2 h-178-174-175-127.A193.priv.bahnhof.se (MYPUBLICIP) 0.876 ms 0.769 ms 0.688 ms
3 h-178-174-175-127.A193.priv.bahnhof.se (MYPUBLICIP) [open] 0.892 ms 1.029 ms 0.908 ms

tcptraceroute iotserver.st 80
Selected device enp0s31f6, address 192.168.1.59, port 49677 for outgoing packets
Tracing the path to iotserver.st (94.254.0.48) on TCP port 80 (http), 30 hops max
1 192.168.1.1 0.468 ms 0.430 ms 0.406 ms
2 gw1.A193.priv.bahnhof.se (178.174.175.1) 1.528 ms 1.498 ms 1.470 ms
3 hlm-lig-ar1.hlm-hst-dr1.bahnhof.net (46.59.112.216) 1.996 ms 1.539 ms 1.442 ms
4 hlm-hst-dr1.gbg-cr5.bahnhof.net (46.59.113.112) 13.789 ms 13.662 ms 13.577 ms
5 gbg-cr5.gbg-cr4.bahnhof.net (46.59.112.172) 13.779 ms 13.772 ms 13.623 ms
6 gbg-cr4.sto-cr2.bahnhof.net (46.59.112.130) 13.679 ms 13.645 ms 13.566 ms
7 sto-cr2.sto-cr1.bahnhof.net (46.59.112.95) 13.792 ms 13.753 ms 13.672 ms
8 sto-cr1.sto-thu-dr7.bahnhof.net (176.10.180.83) 13.873 ms 13.657 ms 13.624 ms
9 sto-thu-dr7.thu-dr1.bahnhof.net (85.24.151.207) 13.266 ms 13.371 ms 13.502 ms
10 newsletter.bahnhof.se (94.254.0.48) [open] 13.561 ms 13.673 ms 13.647 ms

Edit:How can I test that I'm really redirected to my server when I surf to my domain?

11

Try below from the public internet. Setup a test page on your server if you need to be sure it is yours. Using curl -i I still see an Apache server 2.2.15 on CentOS in response headers.

9 Likes
12

I setup a simple webserver (Docker Hub) and I can reach it by going to server local ip or iotserver.st from my phone (ofc mobile network).. Still no cigar with swag..

Why am I directed to 192.168.1.1 when browsing iotserver.st from my lan?

13

If i ping iotserver.st I get:
64 bytes from newsletter.bahnhof.se (94.254.0.48): icmp_seq=8 ttl=55 time=13.5 ms

What does this mean for SWAG?

14

Without showing the actual IP, that traceroute is useless.
If it happens to be:

Name:    h-178-174-175-127.A193.priv.bahnhof.se
Address: 178.174.175.127

That IP doesn't match this one:

Name:    iotserver.st
Address: 94.254.0.48

[and might be why you are having trouble getting a cert for that name]

9 Likes
15

It means that the rDNS for IP 94.254.0.48 returns newsletter.bahnhof.se.

8 Likes
16

Any idea why this could be?
Why can I reach the webserver when browsing the domain if the trace won't won't find ny ip?

I'm trying to understand a bit more so I can explain my problem to bahnhof.
Is there anywhere I can read up on how this works?

17

That depends...
Where are you browsing from?
If from within the same server, that is difficult to mess up and doesn't prove if anyone else can reach it.
If from within the same LAN, that doesn't prove that anyone else (one the Internet) can reach it.
If from the Internet, then certbot should be able to get a cert for it.
So, I suspect that you haven't tried to access it from the Internet.
OR
There are firewall rules that only allow your IP (or some countries or certain networks) access.

If you really want help, start by drawing out the entire system and then test as much of it as possible.
Until you find a problem - get that one fixed and continue testing until all problems have been fixed.
If you don't know how to test any part of it, I'm sure that many here (myself included) would provide you with some simple and effective testing instructions.

7 Likes
18

Thanks. I can reach my website when entering iotserver.st from my phone. Can you?
..but trace can't find the correct IP..

Could this be the problem?

"To ensure that a PTR record is set up for your IP, you might need to contact your internet service provider (ISP). In cases where an ISP provides you with a static IP address, only the provider can point the zone (domain name and IP address) to your DNS server. "

19

I've tried to turn the ufw on the server off but no luck.. Could be something within unifi, but that's setup according to default (except the port forward)..?

20

That's impossible, I'm nowhere near your phone!
LOL

But seriously, yes, I can reach it (but TLS is not working):
This is HTTP and good:

curl -Ii http://iotserver.st
HTTP/1.1 200 OK
Date: Fri, 13 May 2022 05:38:42 GMT
Server: Apache/2.2.15 (CentOS)
Connection: close
Content-Type: text/html; charset=iso-8859-1

This is HTTPS and fails:

curl -Ii https://iotserver.st
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

This is HTTP via the HTTPS port (not good, but possibly easy to fix):

curl -Ii http://iotserver.st:443
HTTP/1.1 200 OK
Date: Fri, 13 May 2022 05:38:45 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/4.4.9
Connection: close
Content-Type: text/html
7 Likes