Dear all,
I guess my problem will seem fairly "known" as I found many examples of it through google. However I found no solution (or I am actually too dumb to understand that I am reading a solution when it is written).
My Problem is this: I have a certificate with multiple subdomains connected. It is already renewed once on this server, which is installed behind a cable router. Ports 80 and 443 are forwarded.
Pages Served on port 80 and 443 are actually available from the outside IP.
However I get a "connection refused" when trying to renew with "certbot renew".
also Let's Debug and https://check-your-website.server-daten.de/?q=passys.nl tell me "unable to connect to server".
This is something I do not understand as nginx server is there, and it does serve pages.
I'm not seeing anything wrong with the current affairs, in the sense that something might be misconfigured or things like that. I believe this might be one of the cases where nginx is being reloaded to serve the challenges and Let's Encrypt tries to query those challenges while nginx isn't ready yet.
You might want to increase the delay between the nginx reload for the challenges and the request by certbot to the Let's Encrypt servers to try to validate those challenges from the default value of 1 second to something longer with the --nginx-sleep-seconds option. Perhaps a few extra seconds is enough.
First, try it with --dry-run and a relative large number (i.e., 10 or 30 seconds or something like that) to see if this option actually helps. If it does help, you might want to decrease the delay to the amount of seconds when the --dry-run still functions. Then, you can remove the --dry-run for the actual renewal.
If --nginx-sleep-seconds doesn't help at all, we'll need to look further.
thank you for the warm welcome.
Thank you for your suggestion, that sounds like a lead.
I tested with: certbot renew --dry-run --nginx-sleep-seconds 10
however no change.
Error log: Letsencrypt.log nginx 10 secs - Pastebin.com
right, that is exactly how I tested as well (from an external IP).
I have a port forwarding on a router, no firewall settings there, I have Fail2ban, and I have shorewall as Firewall. But ports 80 and 443 are explicitly open.
also: stopping shorewall and fail2ban seems to make no difference.
I get your analysis, and I truely think you are right. However I am at a loss how I should approach this.
As you also tested: from a browser, you get a result.
I went through all the services on the system, and there is nothing there that could be blocking in some way. Worse: as I don't "see" that I have a blockage, I'm not even sure how to test for this. I mean: I see that a browser request works and certbot does not. But what is the difference between these to requests that one fails and one works?
I think the only different is the source IP address of the request: somehow something is acting as a firewall and blocking connections from some IP addresses, but not from others. That could be on your server itself, or upstream in your ISP or host.
In some cases this could be based on country or region, although it's not that common to have such a block without realizing it or asking for it.
It's not actually Certbot that's making the failed connections, it's the Let's Encrypt CA validator, which is distributed across several commercial data centers.
Certbot asks for a certificate from the Let's Encrypt API, and that triggers the CA to make its own connection attempts to your site in order to confirm that you really control the domain name that you're asking for a certificate for. Those are then incoming connections from unpredictable data centers anywhere out on the Internet.
A complicating factor is that Let's Encrypt does not publish the IP addresses that will be used for these connections, in order to discourage people from whitelisting them in firewalls (because they can change, and are expected to change, over time).
The examples with the other testing tools are pretty representative, though, because they're located in datacenters elsewhere on the Internet (not necessarily the exact same ones that Let's Encrypt uses!) and they can't connect to your service either. So those tests' failures are probably symptomatic of the same underlying cause.
You can also experiment with the --debug-challenges option. With that option, certbot will wait before triggering the validation until the user has signaled to continue the pause.
During that pause, you could try to remotely fetch the challenge file and see if something goes wrong.
Some of the testing tools (that I think also failed to connect to your site) do have predictable IP addresses, so you could try to debug using that... and maybe ask your ISP to help investigate if you can't solve it on your server itself.
the [quote]No connection could be made because the target machine actively refused it 130.180.67.26:80[/quote]
where is that coming from? I didn't get that. That would indeed suggest it is my server.
I am trying to see if at least i can the challenge in the browser as per @Osiris suggestion.
So I am trying to run:
certbot renew --dry-run --debug-challenges
However before I can even paste the string to the browser, certbot already continues. Am I missing a parameter here?
, welkom!