Timeout during connect followed by rate limit hit


#1

My domain is: wifi.ethos.com

I ran this command: sudo letsencrypt certonly -d wifi.ethos.com

It produced this output: Failed authorization procedure. wifi.ethos.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout during connect (likely firewall problem)

My web server is (include version): Apache2

The operating system my web server runs on is (include version): Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-1061-aws x86_64)

My hosting provider, if applicable, is: AWS

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

Good morning… This certificate was previously updating automatically via cron. For some reason that did not happen this last pass and I went to update manually, which gave me a timeout. I checked the firewall and IPTables, port 80 was free and clear- apache2 was stopped and our tomcat app was shut down. I tried a couple different variations of the update and it eventually gave me the rate limit.

I assume that because the rate limit was hit, the timeout is not legit? Now I am stuck with a bad cert for the domain until the rate limit clears out…


#2

TLS-SNI-01 validation uses port 443, and https://wifi.ethos.com/ really does time out.

Is that what you expect to happen?

Can you open port 443 on your firewall / security groups?

The TLS-SNI-01 validation type is deprecated; if fixing this would be complicated, it would be logical to switch to HTTP-01, since you already have port 80 open.

What version of Certbot are you using? How was it installed?

And, by the way, there’s an issue with the redirect on http://wifi.ethos.com/: It goes to “https://wifi.ethos.com:8443” instead of “https://wifi.ethos.com:8443/” so, for example, someone who tries to visit http://wifi.ethos.com/ will get redirected to https://wifi.ethos.com:8443index.html", which isn’t valid. You should add a “/” to the end of the “Redirect” directive.


#3

It times out right now because I have apache stopped


#4

Timeouts usually mean a firewall or networking problem.

If there wasn’t a firewall or networking problem, and the service was stopped, the error would usually be “Connection refused”.

Edit:

Before, ports 80 and 8443 worked, and port 443 timed out.

Now, all 3 ports return “Connection refused”.

Apparently the networking issue is fixed, and Certbot would probably succeed if you start Apache again.


#5

I have been fighting with java on the box today as well, Ubiquity apparently does not like newer versions so its possible that you got in there while I was messing with it & rebooting. I do have 443 open though…

Will certbot bypass the rate limit?


#6

Which rate limit? If you hit the failed validations rate limit, that only lasts for an hour.


#7

Oh thats a relief… I had a problem back when certs first started issuing where the rate limit kicked me out for a week, I wasnt aware that it was lowered. Thanks!


#8

It wasn’t lowered, it’s just a different rate limit—Failed Validation vs. Duplicate Certificate.


#9

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