Failed authorization procedure


#1

My domain is: ericsowncloud.ddns.net

I ran this command:

sudo certbot certonly --standalone -d ericsowncloud.ddns.net

It produced this output:
Failed authorization procedure. ericsowncloud.ddns.net (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://ericsowncloud.ddns.net/.well-known/acme-challenge/XDk9D1N6E5W0tysfQPJOFm_X6TTBBex1N76BjNM1L7Y: Timeout during connect (likely firewall problem)

My web server is (include version): apache2

The operating system my web server runs on is (include version): Raspbian Stretch

I can login to a root shell on my machine (yes or no, or I don’t know): yes

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.28.0

I tried to create a certificate as above. Apparently, it looks for something in /var/www/html/.well-known . The thing is: this folder does not even exist, so maybe the problem doesn’t have anything to do with firewalls?
(btw, I like the way you help people creating questions)


#2

Your domain needs to be accessible from the outside internet, on port 80. At the moment, neither your IPv4 nor IPv6 addresses can be accessed externally.


#3

Strange, why can I access it then via the browser?


#4

Probably because you are inside the same local network as your Raspberry Pi? Reflected NAT on your modem-router is probably enabling you to access it by those IPs.

For external visitors, you need to setup port forwarding on your router and confirm that your ISP isn’t blocking port 80.


#6

So it could be me or the ISP right? This is how I set up port forwarding in my router, is this correct?


#7

It looks okay, but I don’t know if it’s exactly the right config for your network.

One thing you could do might be to confirm with your ISP’s support staff about whether they do any port blocking, so you know whether to blame your ISP or your configuration.


#8

Hi @Eric-Sommer

it doesn’t work: Only timeouts - ipv4 and ipv6 ( https://check-your-website.server-daten.de/?q=ericsowncloud.ddns.net ):

Domainname Http-Status redirect Sec. G
http://ericsowncloud.ddns.net/
89.1.208.234 -14 10.026 T
Timeout - The operation has timed out
http://ericsowncloud.ddns.net/
2001:4dd6:a268:0:91d9:2c21:94c0:7517 -14 10.023 T
Timeout - The operation has timed out
https://ericsowncloud.ddns.net/
89.1.208.234 -14 10.027 T
Timeout - The operation has timed out
https://ericsowncloud.ddns.net/
2001:4dd6:a268:0:91d9:2c21:94c0:7517 -14 10.024 T
Timeout - The operation has timed out

You use standalone. That starts an own webserver.

Is there a running webserver if Certbot isn’t running?


#9

yes there is an apache server running.

is it a problem that the ipv6 listed in my screenshot does not match the IP address from ifconfig?


#10

Good. Does your server catch all ipv4 and v6 - addresses?

Now your screenshot looks wrong. An ipv4 192.168. is a private address, not a public.

The ipv6 of your screenshot is the public address.

If your ifconfig restricts, that may be a problem.


#11

Good. Does your server catch all ipv4 and v6 - addresses?

not sure. how do I find out about this?

If your ifconfig restricts, that may be a problem.

ifconfig obviously gives me the public ipv6. Whenever I set up port forwarding in the fritz box, an ‘IPv6 Interface-ID’ is set automatically. Or is this also an internal address?


#12

If you use

<VirtualHost *:443>

it’s ok. If you use

<VirtualHost 192.169.1.2:443>

it may be bad.

These are internal ipv6 addresses. Link-local addresses starting with fe80: or unique local addresses from fc00: to fdff:

But your ipv4 in your screenshot is wrong, 192.168 is a private ipv4, not an internet ip.


#13

Sorry for the dumb question, but where do I set this?

Could this be due to the fact that I don’t necessarily get an ip4 from my ISP?


#14

If it is a home server: Where comes the 89.1.208.234 of your dns entry?

Same with 2001:4dd6:a268:0:91d9:2c21:94c0:7517

The tool (and Letsencrypt when checking your domain) sees these two ip addresses. And must find your server there. So there must be correct routing entries.

If a server is located in a datacenter, it’s the job of the datacenter managers to route that correct. But if you have a home server, your ISP must support this ip address.

Check the config file of your Apache. There it should be defined.


#15

The two ip addresses refer correctly to my Raspberry Pi (= the server).

I only found <VirtualHost *:80> in 000-default.conf.


#16

This means that is only setup to listen to IPv4:80

To include both (IPv4 & IPv6) use:

<VirtualHost ip.v4.address:80 [ip.v6.address]:80>
or for all addresses:
<VirtualHost *:80 [::]:80>

#17

There was an issue with the Port Forwarding. Now at least not all tests above fail. IPv6 via port 80 seems to work.

Now,
sudo certbot certonly --standalone -d ericsowncloud.ddns.net
yields
Problem binding to port 80: Could not bind to IPv4 or IPv6.'


#18

Yep, reading your last test ( https://check-your-website.server-daten.de/?q=ericsowncloud.ddns.net )

Domainname Http-Status redirect Sec. G
http://ericsowncloud.ddns.net/
89.1.208.234 -14 10.016 T
Timeout - The operation has timed out
http://ericsowncloud.ddns.net/
2001:4dd6:773d:0:8d2d:b1f3:84b:ecb4 200 0.077 H
https://ericsowncloud.ddns.net/
89.1.208.234 -14 10.017 T
Timeout - The operation has timed out
https://ericsowncloud.ddns.net/
2001:4dd6:773d:0:8d2d:b1f3:84b:ecb4 -2 1.110 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it [2001:4dd6:773d:0:8d2d:b1f3:84b:ecb4]:443
http://ericsowncloud.ddns.net/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
89.1.208.234 -14 10.030 T
Timeout - The operation has timed out
http://ericsowncloud.ddns.net/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2001:4dd6:773d:0:8d2d:b1f3:84b:ecb4 404 0.096 A
Not Found

Ipv6 answers with a correct http status 404.

So your port 80 is blocked with your running Apache. But don’t use standalone, use instead the DocumentRoot - parameter of your Apache as webroot:

certbot run certonly --webroot -w yourDocumentRoot -d ericsowncloud.ddns.net

Letsencrypt prefers ipv6, so your not working ipv4 may be ignored.


#19

I finally solved the problem. Port Forwarding could not work for me as my ISP provided me with DualStack Lite. Thanks to you all for your effort.


closed #20

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