The server could not connect to the client to verify the domain, nginx

Help
1

My domain is: engineblock.co.uk

I ran this command: sudo certbot certonly --manual --email my@email.com -d engineblock.co.uk

It produced this output:

Failed authorization procedure. engineblock.co.uk (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://185.214.140.112/.well-known/acme-challenge/90v1ut946hUGB-Je3V8ynU7X53V0VvuZerzfm_rUs7o: Error getting validation data

IMPORTANT NOTES:

My web server is (include version): nginx/1.10.3 (Ubuntu), pointing to nodejs (v6.4.0)

The operating system my web server runs on is (include version): ubuntu 16.04

My hosting provider, if applicable, is: loveservers

I can login to a root shell on my machine: yes

I have my nginx config set up like:

server {
        listen 80;

        server_name engineblock.co.uk;
        location ^~ /.well-known/acme-challenge/ {
                default_type "text/plain";
                alias /var/www/acme-challenge/;
        }
        location / {

so I'm copying the acme challenge file into that location, when it asks for it, and I can verify that copying "http://185.214.140.112/.well-known/acme-challenge/90v1ut946hUGB-Je3V8ynU7X53V0VvuZerzfm_rUs7o:" into my browser does produce the string the certbot gave me for the file contents. And the same is true if I go to http://engienblock.co.uk/.well-known.....", however the browser address bar converts it back to the IP, could that be the problem?

I also have port 443 open, though I have not referred to it anywhere in the nginx config. I have also tried the same procedure but using nodejs to return the acme-challenge file, but with the same results.

I have a AAAA record set, which I verified using this site "Network Tools: DNS,IP,Email"

Any help/advice much appreciated.

2

I'm not sure; I guess it could be. But even if it's not, you need to fix that anyway. Let's Encrypt certificates can't be issued for IP addresses, so even if you got a certificate, you couldn't use it to protect the connection to the IP address.

(and I suppose there's not much benefit to having an AAAA record if all it does is redirect to an IPv4 address anyway...)

The redirect might be in your nginx configuration or it might be some code in your application.

3

Yes, it’s a problem. By design, Let’s Encrypt won’t follow redirects to an IP address like that. (It’s a kind of arbitrary decision to simplify the software, I believe.)

The browser isn’t converting the URL. The web server is configured to respond with an HTTP redirect, and clients follow it (or don’t).

I’m not sure what’s generating the first redirects – but it’s probably not Nginx – but it looks like the last redirect is being generated by an ASP.NET application.

(By the way, the site has an AAAA record, but connecting over IPv6 results in “Connection refused”. If it’s running Nginx, you need to add “listen [::]:80;” For other web servers, something similar.)

2 Likes
4

The redirections are beyond my comprehension:

#1 wget http://engineblock.co.uk/
–2017-10-14 17:41:20-- http://engineblock.co.uk/
Resolving engineblock.co.uk (engineblock.co.uk)… 50.63.202.27, 2a07:4580:b0d:6b5::9d53
Connecting to engineblock.co.uk (engineblock.co.uk)|50.63.202.27|:80… connected.
HTTP request sent, awaiting response… 302 Found
Location: /OKRKY/ [following]
–2017-10-14 17:41:26-- http://engineblock.co.uk/OKRKY/
Connecting to engineblock.co.uk (engineblock.co.uk)|50.63.202.27|:80… connected.
HTTP request sent, awaiting response… 302 Found
Location: / [following]
–2017-10-14 17:41:26-- http://engineblock.co.uk/
Connecting to engineblock.co.uk (engineblock.co.uk)|50.63.202.27|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 360 [text/html]

#2 wget http://engineblock.co.uk/OKRKY/
–2017-10-14 17:44:36-- http://engineblock.co.uk/OKRKY/
Resolving engineblock.co.uk (engineblock.co.uk)… 50.63.202.27, 2a07:4580:b0d:6b5::9d53
Connecting to engineblock.co.uk (engineblock.co.uk)|50.63.202.27|:80… connected.
HTTP request sent, awaiting response… 302 Found
Location: /cpZZm/OKRKY/ [following]
–2017-10-14 17:44:41-- http://engineblock.co.uk/cpZZm/OKRKY/
Connecting to engineblock.co.uk (engineblock.co.uk)|50.63.202.27|:80… connected.
HTTP request sent, awaiting response… 302 Found
Location: /OKRKY/ [following]
–2017-10-14 17:44:41-- http://engineblock.co.uk/OKRKY/
Connecting to engineblock.co.uk (engineblock.co.uk)|50.63.202.27|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 367 [text/html]

#3 wget http://engineblock.co.uk/WTF!/
wget http://engineblock.co.uk/WTF/etc/apache2/sites-enabled/
–2017-10-14 17:45:10-- http://engineblock.co.uk/WTF/etc/apache2/sites-enabled/
Resolving engineblock.co.uk (engineblock.co.uk)… 50.63.202.27, 2a07:4580:b0d:6b5::9d53
Connecting to engineblock.co.uk (engineblock.co.uk)|50.63.202.27|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 391 [text/html]

#1 <frame src=“http://185.214.140.112” frameborder=“0” />
#2 <frame src=“http://185.214.140.112/OKRKY/” frameborder=“0” />
#3 <frame src=“http://185.214.140.112/WTF/etc/apache2/sites-enabled/” frameborder=“0” />

5

Thank you everyone for your help.

I tried using “forward with masking” from my dns supplier, but that’s a no go too isn’t it, as it just wraps everything in an iframe which again the certbot doesn’t like.

I have also just served using a simple python server (with no nginx, )and the same redirect happens so I think it is outside the control of my server, does that sound right? There is nothing I can do in my server that would prevent this redirect from happening is there, by the looks of things?

I assume the next port of call would be the company that host my server then, would that be the source of the redirect? Is this a general problem with some hosting providers, can their configuration be incompatible with letsencrypt?

6

Thanks all again.

Turns out I just didn’t know ho to configure my dns settings at godaddy.

It’s not “forwarding” that needs to be set but simply the “value” field of the A record. A RTFM kinda issue.

1 Like
7

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