Can't create certificate


#1

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.

I’m running on debian jessie with nginx server.

Any idea how to fix this?

Thanks.


#2

Looking at your test file, I didn’t get it in the correct format

$ curl -I yeuxdelibad.net/.well-known/test
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 25 Apr 2016 12:07:32 GMT
Content-Type: application/octet-stream
Content-Length: 4
Last-Modified: Mon, 25 Apr 2016 11:57:56 GMT
Connection: keep-alive
Keep-Alive: timeout=10
ETag: "571e0644-4"
Expires: Wed, 25 May 2016 12:07:32 GMT
Cache-Control: max-age=2592000
Cache-Control: public

You will probably need to add something like the section below to your nginx config to ensure all the files are transmitted as plain text.

 location /.well-known/acme-challenge {
    location ~ /.well-known/acme-challenge/(.*) {
 allow all;
     add_header Content-Type "text/plain";
    }
}

#3

Thanks for your answer.
I followed your advice. now, content-type is plain text :

$ curl -I yeuxdelibad.net/.well-known/acme-challenge/test
url -I yeuxdelibad.net/.well-known/acme-challenge/test                              <
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 25 Apr 2016 12:25:39 GMT
Content-Type: application/octet-stream
Content-Length: 4
Last-Modified: Mon, 25 Apr 2016 12:23:23 GMT
Connection: keep-alive
Keep-Alive: timeout=10
ETag: "571e0c3b-4"
Expires: Wed, 25 May 2016 12:25:39 GMT
Cache-Control: max-age=2592000
Content-Type: text/plain

Sadly, this doesn’t solve my problem :confused:


#4

I assume that the webroot is correct ? ie your test file is in

/media/PIDATA/www/epicededune/.well-known/acme-challenge/test


#5

yes it is :
ls /media/PIDATA/www/epicededune/.well-known/test
/media/PIDATA/www/epicededune/.well-known/test

And my 443 port is reachable (instead of what we can read on other threads):

nc -zv yeuxdelibad.net 443
yeuxdelibad.net [109.190.193.124] 443 (https) open

#6

With standalone, a DNS error occurs :

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?


#7

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.


#8

Oh yeah, sorry, the first one is a typo :confused: You’re right, thanks.

I stopped the webserver before starting the standalone method :slight_smile: . I’m just trying to figue out where the problem is :slight_smile:


#9

I’ve just noted that the letsencrypt request (to my server) does’nt seems to happen, there is nothing in logs. So I’m back with the DNS problem idea.


#10

I found the full log. There is indeed a DNS error, but how can I fix such thing?
Here is the full log :
http://paste.debian.net/440773/


#11

If you’re referring to this:

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?


#12

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?


#13

Thank you all for your interest.
Yes, I have a firewall, but configured to let 80 and 443 ports open (I can go to my website :slight_smile: )

In case this is useful, here is my iptables output :

http://paste.debian.net/440788/


#14

Are there any interesting logs in your /var/log/syslog or /var/log/ufw.log from around the time you ran into that error?


#15

Yes, there is! I think this is the relevant part :

Apr 25 17:32:53 yeuxdelibad kernel: [948170.217929] [UFW BLOCK] IN=eth0 OUT= MAC= SRC=192.168.1.65 DST=239.192.152.143 LEN=164 TOS=0x00 PREC=0x00 TTL=1 ID=6373 DF PROTO=UDP SPT=56841 DPT=6771 LEN=144

So, it might be my firewall messing with letsencrypt. :confused:


#16

There is a new entry in the log every time I try to run letsencrypt. I’m confused, the IP adresse is never the same :

Apr 25 17:35:53 yeuxdelibad kernel: [948350.745338] [UFW BLOCK] IN=eth0 OUT= MAC=fc:aa:14:65:5f:86:58:98:35:56:2e:20:08:00 SRC=83.113.58.174 DST=192.168.1.65 LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=12064 PROTO=UDP SPT=41291 DPT=55550 LEN=28
Apr 25 17:36:14 yeuxdelibad kernel: [948370.895663] [UFW BLOCK] IN=eth0 OUT= MAC=fc:aa:14:65:5f:86:58:98:35:56:2e:20:08:00 SRC=90.104.37.88 DST=192.168.1.65 LEN=131 TOS=0x00 PREC=0x00 TTL=118 ID=8892 PROTO=UDP SPT=64968 DPT=55550 LEN=111
Apr 25 17:36:33 yeuxdelibad kernel: [948390.596093] [UFW BLOCK] IN=eth0 OUT= MAC=fc:aa:14:65:5f:86:58:98:35:56:2e:20:08:00 SRC=77.192.92.163 DST=192.168.1.65 LEN=48 TOS=0x00 PREC=0x00 TTL=121 ID=16255 PROTO=UDP SPT=37947 DPT=55550 LEN=28

#17

Sorry for multi-posting…
I disabled firewall and tried to launch letsencrypt again, but there is still the same error. Hum…


#18

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.


#19

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.


#20

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 :smile:)? 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.