Error on Requesting Certificate: The server could not connect to the client to verify the domain

Help
1

My domain is: tehtotalpwnage.io

I ran this command: ./letsencrypt-auto certonly --standalone

It produced this output:

Failed authorization procedure. solder.tehtotalpwnage.io (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 108.184.52.126:443 for TLS-SNI-01 challenge

IMPORTANT NOTES:
- The following errors were reported by the server:

Domain: solder.tehtotalpwnage.io
Type:   connection
Detail: Failed to connect to 108.184.52.126:443 for TLS-SNI-01
challenge

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 operating system is (include version): Ubuntu 14.04 LTS

My web server is (include version): Nginx 1.10.1

My hosting provider, if applicable, is: Self Hosted

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

I’ve actually used Let’s Encrypt in the past without running into any problems. I also did a bit of tinkering, and this is what I know: For some reason, any subdomains I append after the 8th subdomain automatically have this error. I tested the subdomains individually and didn’t get any problems when getting individual certificates. So the problem only exists when I try to add more than eight subdomains to my request. Now, my only question is why in the world this would happen.

2

Does this thread help ....

3

My best guess: Your ISP is doing some sort of filtering on incoming packets (for example to prevent some DDoS attacks), and it gets triggered when the validation server establishes more than 8 simultaneous connections.

This would certainly be tricky to verify. :smile:

4

That probably figures :stuck_out_tongue: I’ll talk to my ISP about it to see if that’s the case.

5

It seems that using webroot gets around the problem. I’ll try out the webroot method instead of the usual standalone method then.

EDIT: Never mind, I’m not quite sure why, but even though the person in the thread you linked seems to have the same problem that I do, using webroot didn’t solve it for me. The same symptoms persist.

6

Out of curiosity, if you use --standalone with --standalone-supported-challenges http-01, does that work too? This would use the same challenge type that webroot uses, but does spawn its own web server.

7

Yeah, I did try http-01, but that didn’t work either. Same 8 certificate limit.

8

That’s interesting. I wonder if it’s a bug with the standalone web server, or just some small implementation difference that causes the packet filtering to trigger, like for example the standalone plugin requesting the validation in parallel, while webroot does it sequentially, making it look less DDoS-y. Will do some testing.

9

Disregard my above comment. It seems that the issue carries over to webroot as well. I would think that a way to solve the problem is to allow a ratelimit parameter for users that are encountering this sort of issue.

10

Problem’s solved. I cleared it up with my ISP. I still think a rate parameter for the certbot would be a neat addition though :slight_smile:

11

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