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 18.104.22.168:443 for TLS-SNI-01 challenge
- The following errors were reported by the server:
Detail: Failed to connect to 22.214.171.124:443 for TLS-SNI-01
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.
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.
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.
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.
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.