Hi,
I’m trying to get certificates thanks to letsencrypt, but I keep getting this (so famous) error :
Failed authorization procedure. yeuxdelibad.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://yeuxdelibad.net/.well-known/acme-challenge/AFZxSAQ2_cn6x-oQRdDBNSbEh3r4jI0qk1SS_0g1fDA
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: yeuxdelibad.net
Type: connection
Detail: Could not connect to http://yeuxdelibad.net/.well-known
/acme-challenge/AFZxSAQ2_cn6x-oQRdDBNSbEh3r4jI0qk1SS_0g1fDA
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.
It’s getting me mad, as I don’t know where to look for a mistake.
I try to get my certificate with this command : letsencrypt certonly --rsa-key-size 4096 --webroot -w /media/PIDATA/www/epicededune/ -d yeuxdelibad.net
I tried to get a sample file, and I can get it : http://yeuxdelibad.net/.well-known/test
My DNS filed is ok. I even already got a certificate a few month ago without any issue.
letsencrypt certonly --rsa-key-size 4096 --standalone -d yeuxdelibad.net
Failed authorization procedure. yeuxdelibad.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: yeuxdelibad.net
Type: connection
Detail: Failed to connect to host for DVSNI 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.
But my DNS fields seems ok. Any tip to check this again?
Just double checking … please see the difference between
/media/PIDATA/www/epicededune/.well-known/test ( that you said in your last post) and, doesn’t return a plain text file for me, and
/media/PIDATA/www/epicededune/.well-known/acme-challenge/test ( which is the correct location )
This may just be a typo on your behalf, just checking though.
For the standalone test you tried - that’s a different issue ( from the look of things). You would need to stop your webserver for that. It’s probably easier to just debug one issue at a time.
2016-04-25 14:07:02,005:DEBUG:acme.challenges:dns-01 was not recognized
That's expected; it's about a challenge type not supported by the client, not a DNS error. You can ignore those log messages.
The error you're seeing means that the CA server is unable to establish a connection to port 80. If the CA server fails to look up the A record for your domain, you'd be seeing a different error. A 404 or anything like that would yield a different error message as well.
It's hard to determine what exactly is causing this. Do you have any firewall rules that could be interfering? Something like a country blocklist? Maybe some overzealous iptables rules triggering a false positive which you could disable to test this?
This piqued my curiosity, Thuban and I jumped into the logs on the server. As pfg said, DNS is resolving fine. Attempting to connect to yeuxdelibad.net from the primary DC fails. Ping still works, but port 80 times out. From the secondary DC, it succeeds fine.
I’ll echo pfg’s question: Do you have any firewalls blocking inbound traffic?
Those look unrelated to me. With webroot, only lines with DPT=80 should be relevant. Anything like that in there?
Not sure which OVH product you’re using, but some of them come with an additional firewall you can configure through the manager, as well as a DDoS filter. Maybe you’re running into a false-positive or that firewall is interfering in some other way? IIRC some product lines allow disabling that feature, maybe that’ll work.
Unrelated, undoublty, but they showed up each time I ran letsencrypt. Disturbing. ^^
I just have my domain name from OVH. The weirdest part is that I already had a letsencrypt certificate before with the same setup a few month ago. Something might have changed in the API.
Oh, it seems I misread the whois output and figured you’re using one of their dedicated servers or something like that.
Looks like it’s a DSL connection (and the ISP happens to be OVH, hence my confusion )? ISPs often do some weird inbound filtering for their residential customers before the traffic even reaches them. Some downright block ports like 80/443, others use country blocklists or more advanced heuristics to decide whether to block traffic or not. This might very well be what you’re seeing here, given that the connection works most of the time, but not from Let’s Encrypt’s data center. The fact that your firewall logs don’t show any blocked traffic during your attempts support the theory that the filtering is happening at the ISP level.
The error you’re seeing is not consistent with any API change on Let’s Encrypt’s end.
. I’m just trying to figue out where the problem is 
)? ISPs often do some weird inbound filtering for their residential customers before the traffic even reaches them. Some downright block ports like 80/443, others use country blocklists or more advanced heuristics to decide whether to block traffic or not. This might very well be what you’re seeing here, given that the connection works most of the time, but not from Let’s Encrypt’s data center. The fact that your firewall logs don’t show any blocked traffic during your attempts support the theory that the filtering is happening at the ISP level.