Error: The server could not connect to the client for DV

Help
1

I have an invite to the beta for 2 domains. I’m trying to get it working on one of them first. I have provisioned a fresh Ubuntu 14.04 VM on Google cloud compute, and allowed HTTP and HTTPS traffic. I’ve added the domain name to DNS, and checked that it has propogated (it was added about 16 hours ago). The only ‘extra’ packages I have installed are git and apache2 (as yet unconfigured).

Using the command ./letsencrypt-auto auth and completing the dialogue boxes results in

    Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/<my_whitelisted_domain>/fullchain.pem.
   Your cert will expire on 2016-02-05. To obtain a new version of the
   certificate in the future, simply run Let's Encrypt again.

when I add the server parameter (./letsencrypt-auto auth --server https://acme-v01.api.letsencrypt.org/directory) and answer the dialogue questions with the same responses as before, I get the following result:

   The following 'connection' errors were reported by the server:

   Domains: <my_whitelisted_domain>
   Error: The server could not connect to the client for DV

   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.

Am I doing something wrong?

2

Nothing seems obviously wrong at first glance. I do notice one thing: it looks like you have edited out your domain to replace it with <my_whitelisted_domain>. I just want to make sure you know that on successful issuance, your certificate, including your domain name, will be publicly available in the Certificate Transparency logs. If you’re willing to include the actual domain name here, it might be easier for people to help diagnose, e.g. by looking at the Certificate Transparency logs or double-checking that your domain actually resolves.

2 Likes
3

I appreciate that, but was hoping to get a chance to make sure the relevant security was in place first - as I have left it ‘raw’ as per my inital post to make sure nothing was impeding on the certificate process!

In case it does help, the domain is grasberg.oraclefinance.co.uk

4

So, checking from my home connection, that host is not reachable by ping or curl. Perhaps it is down, or firewalled?

5

Apologies, that’s because I destroyed the server to start again!

It should be back up and running now (with the same config as before; these commands from a different server, on a different network:

sheepeatingtaz@coruscant:~⟫ ping -c 5 grasberg.oraclefinance.co.uk
PING grasberg.oraclefinance.co.uk (130.211.59.59) 56(84) bytes of data.
64 bytes from 59.59.211.130.bc.googleusercontent.com (130.211.59.59): icmp_seq=1 ttl=49 time=13.7 ms
64 bytes from 59.59.211.130.bc.googleusercontent.com (130.211.59.59): icmp_seq=2 ttl=49 time=13.4 ms
64 bytes from 59.59.211.130.bc.googleusercontent.com (130.211.59.59): icmp_seq=3 ttl=49 time=13.3 ms
64 bytes from 59.59.211.130.bc.googleusercontent.com (130.211.59.59): icmp_seq=4 ttl=49 time=13.4 ms
64 bytes from 59.59.211.130.bc.googleusercontent.com (130.211.59.59): icmp_seq=5 ttl=49 time=13.4 ms

--- grasberg.oraclefinance.co.uk ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 13.399/13.492/13.740/0.178 ms


sheepeatingtaz@coruscant:~⟫ curl grasberg.oraclefinance.co.uk

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
...

(At 11:30 UTC the DNS set, it is still propogating at the time of writing)

6

It looks like we still have a cached copy of the old IP address. It looks like the TTL was on the order of a day, and there are about 17 hours left of caching.

Also, I’d recommend running with --text -vv next time to get better debugging information.

1 Like
7

I’ve run again this morning with the same result - the output of the command with --text -vv is here:

http://pastebin.com/RMiThh2P

8

@steve.garton

curl grasberg.oraclefinance.co.uk
curl: (7) Failed to connect to grasberg.oraclefinance.co.uk port 80: Connection refused

9

That’s because I had to (have to?) shut apache down to run letsencrypt otherwise it complains that it can’t use port 80.

I’ve started it up again if you want proof!

10

In output that you have posted, there is a line:

validationRecord":[{“hostname”:“grasberg.oraclefinance.co.uk”,“port”:“443”,“addressesResolved”:[“146.148.125.16”],“addressUsed”:“146.148.125.16”}]}],“combinations”:[[0],[1],[2],[3]]}’

It seems that you DNS TTL still has not expired. Can someone from LE verify when will DNS cache on their recursive DNS expire?

11

dig grasberg.oraclefinance.co.uk @8.8.8.8

; <<>> DiG 9.8.3-P1 <<>> grasberg.oraclefinance.co.uk @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14485
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;grasberg.oraclefinance.co.uk. IN A

;; ANSWER SECTION:
grasberg.oraclefinance.co.uk. 21599 IN A 130.211.59.59

;; Query time: 58 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov 12 10:10:50 2015
;; MSG SIZE rcvd: 62

1 Like