Http-01: The server could not connect to the client to verify the domain

Help
1

Hi,

I’m working with a rather old server (RHEL 5). After some struggle (compiling openssl and python, then setting certain obscure flags), I finally got letsencrypt to run. The machine runs Apache web server 2.2.3. Upon issuing the following command:
/usr/local/letsencrypt/certbot/letsencrypt-auto certonly --webroot -w /var/www/html -d eprint01.cameron.edu,
I get the message:
Failed authorization procedure. eprint01.cameron.edu (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to eprint01.cameron.edu

I inspected the log file in /var/log/letsencrypt/letsencrypt.log. It shows:
Connection: keep-alive

{
“identifier”: {
“type”: “dns”,
“value”: “eprint01.cameron.edu”
},
“status”: “invalid”,
“expires”: “2017-04-27T16:22:44Z”,
“challenges”: [
{
“type”: “http-01”,
“status”: “invalid”,
“error”: {
“type”: “urn:acme:error:connection”,
“detail”: “Could not connect to eprint01.cameron.edu”,
“status”: 400
},
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/o2jiLQK0vvwv6tBmandHdryuiCN2If0AG0XeQGx-Fe8/1056429074”,
“token”: “aZvcs9YE3eMTiuEmdLBAYj3o9vskakis5CJxPOShCjA”,
“keyAuthorization”: “aZvcs9YE3eMTiuEmdLBAYj3o9vskakis5CJxPOShCjA.6IcBT17Xguy9NWmdYbHKlyI2JJQbMbDrD46qjnNnUDw”,
“validationRecord”: [
{
“url”: “http://eprint01.cameron.edu/.well-known/acme-challenge/aZvcs9YE3eMTiuEmdLBAYj3o9vskakis5CJxPOShCjA”,
“hostname”: “eprint01.cameron.edu”,
“port”: “80”,
“addressesResolved”: [
“164.58.112.58”
],
“addressUsed”: “164.58.112.58”
}
]
},
{
“type”: “tls-sni-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/o2jiLQK0vvwv6tBmandHdryuiCN2If0AG0XeQGx-Fe8/1056429075”,
“token”: “ORaKGqBc1Y673FbUn0dfhGoC2bxfKrLBf2J3rpIUj5o”
},
{
“type”: “dns-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/o2jiLQK0vvwv6tBmandHdryuiCN2If0AG0XeQGx-Fe8/1056429076”,
“token”: “oO-uk3wQJYE_KL63EExmlk8V4bAouKXzfzYUuHs-6l4”
}
],
“combinations”: [
[
1
],
[
0
],
[
2
]
]
}

Originally, I thought this was a firewall issue. I pinged acme-v01.api.letsencrypt.org, and found the ip address to be 184.86.145.80. I had my network admin create a rule to allow traffic from this ip through the firewall on ports 80 and 443. I tried again and still received the same error. I went as far completely shutting down the firewall on the server (not on the entire network). Still received the same error message.

I have tested my web root directory (/var/www/html) and ensured that files placed there and in sub folders are accessible.

Does anyone know of what I might be doing wrong?

Thank you.

2

As long as this error remains and you're certain the webserver is up and running on port 80, nope:

osiris@desktop ~ $ telnet eprint01.cameron.edu 80
Trying 164.58.112.58...
telnet: connect to address 164.58.112.58: Connection refused
osiris@desktop ~ $
3

Are you absolutely certain it's not firewalled? By the name of it, that looks like some printer at Cameron University, in which case it would make sense to have that firewalled from the outside world. As for the specific IPs, it has been previously discussed here that the IPs of validation servers may change rather often and multiple ones can be used, so there is no guarantee you are unblocking the right one.

So, before running LE client make some basic checks:

a) Ensure that the server is actually running (service httpd status)
b) Check that it is indeed httpd sitting on the proper port (with either netstat -tulpn or lsof -i)
c) Check that it is actually possible to connect to the web server from outside (for example https://validator.w3.org/ will do the job just fine if you ask it to validate some dummy page)

4

Thanks for the quick responses.

I ran the commands you mentioned. I can confirm that httpd is running on 80 and 443 (the service is running too). Obviously, since I don't have the server open to everyone the validator will not work.

The server is not a print server despite the name. It's more like an application server that sits behind a presentation server. We would prefer to give this server as little exposure outside the firewall as possible. I looked at the whois information for the validation server and it gives an IP address range of 184.84.0.0 - 184.87.255.255 with a net mask of 14 bits. That's a huge range of addresses to open up! Does the server need to be completely open to the public to use Let's Encrypt?

5

There are three validation methods used by Let’s Encrypt. Two of them require a direct inbound connection to your server (HTTP-01, which uses HTTP on port 80, and TLS-SNI-01, which uses TLS on port 443). If you don’t want to allow the public to make connections to your server, you can use the remaining method, DNS-01, which requires you to set specific requested DNS records in your DNS zone in order to prove your control over the domain.

6

Well, if you use DNS verification, then it does not have to be open up at all or even exist (you just need to create a TXT record in DNS). If you prefer using HTTP verification for some reason and not expose the box, you might for example achieve that with split-DNS (by resolving the same name into a server in DMZ for the outside queries).

7

DNS sounds like a good idea, the only issue with that is we would have to manually add the DNS entry (on three different servers BTW), and we would have to wait a day for the DNS entries to synchronize with other servers. I asked my network admin to perform a packet capture. When he did, he noticed that there is an ephemeral port opened up 52727. Then, I asked him to allow all traffic through from that IP (on any port), and I got to the next level of error.

{
    "type": "urn:acme:error:rateLimited",
     "detail": "Error creating new authz :: Too many invalid authorizations recently.",
     "status": 429
}

Looks like another port is being used besides just 80 and 443. Should this be the case?

You guys are awesome BTW. Thanks you so much for your help.

8

Technically, for the clients supporting plugins, you might not need to add an entry manually - you might automate that with a bit of programming for example. Also LE checks the records against the authoritative servers (if I remember that correctly), so waiting for a day is probably not going to be needed (unless of course that is how long it takes to replicate zone info between your DNS servers).

Regarding the port - are you sure that’s not some outbound connection unrelated to the process? Since he used pcap, he might load up the data into Wireshark for example and do a trace, to get a better understanding what that might be about.

Finally, getting an actual error about too many authz is likely caused by those failing attempts. Since I’m not actually using certbot, I’m not entirely sure if it can reset those, so I’ll leave that to be answered by someone more familiar with the official client :slight_smile:

1 Like
9

Thanks leader.

My network admin looked through the packet capture and found that nothing was accessing port 80. Instead, we see port 443 being used. We have certbot working on three other computers, but this is really strange. I might have to give up on this one .

10

Sorry I didn't notice this in order to clarify: the validation server is not the same as the API endpoint. Whitelisting connections from the IP address that you see for acme-v01.api.letsencrypt.org will not help because validations are never performed from that IP address! Let's Encrypt's recommendation is to allow any IP address to connect for validations, or else to use DNS-01.

11

Until telnet eprint01.cameron.edu 80 works from outside of your network, you won’t be able to get any certificates using the method you’re using (whether because you don’t actually have an existing web server listening on port 80, or because of some firewall rule). Like @Osiris, I still see it not working from where I am!

12

Looks like Let’s Encrypt is not the right solution for this server. We’re going to leave it behind the firewall. I will create my own CA for internal uses.

To everyone who participated, thank you.

13

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