[SOLVED] EC2 and Let's Encrypt - Could not connect to the client to verify the domain

Server
1

[SOLUTION] Found /etc/ufw/before.rules had rules configured to redirect traffic from 443 to 8443. Temporarily disabled and was able to receive certificate.

I’m using a script called JSS-in-a-Box to configure JSS and Let’s Encrypt on an Amazon EC2 Ubuntu 16.04.2 instance.

Full domain: jamfpro.simply.ca
Command I ran: sudo -H /opt/letsencrypt/certbot-auto certonly --standalone -m myemail@domain.ca -d jamfpro.simply.ca --agree-tos --test-cert
The output of that command: (see below)
Name and version of OS and web server: Ubuntu 16.04.2 LTS - Tomcat8
Hosting provider: Amazon AWS - EC2 instanc

sudo -H /opt/letsencrypt/certbot-auto certonly --standalone -m myemail@domain.ca -d jamfpro.simply.ca --agree-tos  --test-cert
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for jamfpro.simply.ca
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. jamfpro.simply.ca (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 34.208.3.77:443 for tls-sni-01 challenge

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: jamfpro.simply.ca
   Type:   connection
   Detail: Failed to connect to 34.208.3.77:443 for tls-sni-01
   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.

I have added a rule to my security group to allow inbound HTTPS traffic from anywhere, but am still receiving this error. UFW is also set to allow HTTPS traffic. Thoughts?

2

lsof -i as an additional check that port 443 is actually being listened on and what listens on it is a webserver. Actually, since you are using standalone, the client itself would be your “webserver”, so it should in theory work. Unless of course 443 is already in use by another process but I’d imagine that in this case certbot would have shown another error. In any case - double check ports and processes.

3

Correct. There is no response when using the lsof -i command. It would appear that there is nothing running on the server hijacking port 443.

4

Basically there might be 4 straightforward reasons for not being able to connect:

  • Security groups (though you said that you have enabled HTTPS there)
  • Local firewall (again, as you said, inbound 443 is enabled)
  • No processes listening on port (which should not be the case with standalone I believe)
  • Networking issue preventing LE verification server from reaching your server (can happen sometimes)

Obviously there could be more. Personally what I would do in this case, if Security groups and Local firewall are in order, I would try to connect to 443 myself from another box while having either a webserver running and listening on 443 or some simple script that would bind to 443 and printed out “OK” if received the connection :slight_smile:

It would be nice though if the error message produced by the client was a bit more elaborate (for example to tell “connection reset” from “timeout”) …

5

You can do this with

echo OK | nc -l 443

on your server, and

nc yourserver 443

on another machine (not on the same LAN).

6

nc is indeed another way to do that, though usually one would have a server installed already anyway (for which the cert is being obtained) and could try connecting to that. As for the script - that’s my personal choice I guess, for me it’s easier to spawn a simple server with Perl oneliner :slight_smile:

7

With the command echo OK | nc -l 443 running on the server, there is no output displayed in terminal after issuing the command and no prompt to enter new commands, so I presume it’s running successfully. I was only able to run this command as root.

root@ip-172-40-0-86:/home/ubuntu# echo OK | nc -l 443

When attempting to run the command nc yourserver 443 using the hostname OR IP address, terminal provides no output/response, and proceeds to a new line for my next command.

MacBook-Pro:~ User$ nc jamfpro.simply.ca 443
MacBook-Pro:~ User$ nc 34.208.3.77 443
MacBook-Pro:~ User$

By comparison, I DO receive response when testing on port 22 for SSH.

MacBook-Pro:~ User$ nc jamfpro.simply.ca 22
SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
8

Thanks for trying the experiment. That looks like there is still a firewall somewhere preventing the port 443 connections.

9

Would it be accurate to say that running:

echo OK | nc -l 443

on the server, then also running:

nc 127.0.0.1 443

on the server and receiving an “OK” response would indicate that this is not related to the firewall within the server’s OS?

10

The server firewall could apply only to one particular network interface, so that experiment isn’t totally conclusive.

11

Found some redirection rules in the firewall log (8443->443) to be causing the issue. After disabling I could successfully receive a certificate.

Thanks leader and schoen for the helpful tips.

12

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