Staging environment works, production has connectivity issues


#1

I’m obfuscating the domain name here because while publicly accessible, this multi-domain server hosts only testing environments for a web application, and I do not wish to have it listed on the internet.

My domain is: example.com

I ran this command:
certbot certonly --test-cert --webroot -d machine1.example.com -d env01.example.com -d env02.example.com
And it worked fine.
Then, I ran the exact same command, without the --test-cert flag:
certbot certonly --webroot -d machine1.example.com -d env01.example.com -d env02.example.com
And it failed.

It produced this output:

Failed authorization procedure. env01.example.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to env01.example.com

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

   Domain: env01.example.com
   Type:   connection
   Detail: Could not connect to env01.example.com

My operating system is (include version):
Debian 8 Jessie (Linux machine1 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1 (2016-12-30) x86_64 GNU/Linux)

My web server is (include version): Nginx version: nginx/1.10.2

My hosting provider, if applicable, is:

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

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): DNS is managed through Godaddy’s web interface.

What I don’t get is why the hell is everything working fine when using staging environment, and some domain fail to validate when trying to generate production certificates.
Every subdomain I provide to certbot for validation has its own web root, and is publicly accessible.
I don’t get what’s going wrong.

Any help appreciated!
Thanks!


#2

Have you tried using a new account on staging? It may be that your existing staging account has some previously validated authorizations that are being reused, preventing the requests from failing like they would if a fresh validation were attempted.

I appreciate your concern, but the domain will also be included in certificate transparency logs and it is quite difficult to debug this sort of problem without knowing the domain :slight_smile:


#3

Thanks for the tip @cpu!

I removed the account for the staging environment and you were right, a previous validation succeeded when I tried to verify only one subdomain probably helped me avoiding the error.

Yeah you’re right, I probably can post them here as well.

I tried to issue certificates for the following domains:

Each t00x subdomain uses the exact same nginx configuration, only the server name and root path or log file path changes accordingly. They all redirect 301 from standard HTTP:80 to HTTPS:443.
The as-105507 subdomain has a different server block configuration, and only supports http on port 80.

Somehow, t006 and as-105507 succeed to verify, as they do not appear in the error output below.
However, every other one fails.
I checked that accessing files under .well-known folder works for every subdomain, and it does.
The “manual” proof is here for each subdomain:
http://xxxxx.allsquaregolf.com/.well-known/whoami.html

Command I used to issue the request:

certbot certonly --test-cert --webroot -w /var/www/html -d as-105507.allsquaregolf.com -w /home/allsquare/test-001/current/public -d t001.allsquaregolf.com -w /home/allsquare/test-002/current/public -d t002.allsquaregolf.com -w /home/allsquare/test-003/current/public -d t003.allsquaregolf.com -w /home/allsquare/test-004/current/public -d t004.allsquaregolf.com -w /home/allsquare/test-005/current/public -d t005.allsquaregolf.com -w /home/allsquare/test-006/current/public -d t006.allsquaregolf.com

Here’s the actual output of my certbot command:

Failed authorization procedure. t002.allsquaregolf.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to tOO2.allsquaregolf.com, t003.allsquaregolf.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to tOO3.allsquaregolf.com, t001.allsquaregolf.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to tOO1.allsquaregolf.com, t005.allsquaregolf.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to tOO5.allsquaregolf.com, t004.allsquaregolf.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to tOO4.allsquaregolf.com

IMPORTANT NOTES:
 - If you lose your account credentials, you can recover through
   e-mails sent to webmaster@allsquaregolf.com.
 - The following errors were reported by the server:

   Domain: t002.allsquaregolf.com
   Type:   connection
   Detail: Could not connect to tOO2.allsquaregolf.com

   Domain: t003.allsquaregolf.com
   Type:   connection
   Detail: Could not connect to tOO3.allsquaregolf.com

   Domain: t001.allsquaregolf.com
   Type:   connection
   Detail: Could not connect to tOO1.allsquaregolf.com

   Domain: t005.allsquaregolf.com
   Type:   connection
   Detail: Could not connect to tOO5.allsquaregolf.com

   Domain: t004.allsquaregolf.com
   Type:   connection
   Detail: Could not connect to tOO4.allsquaregolf.com

   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.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

#4

You can sort of see this above but you appear to have a redirection-related typo where you’re interchanging 0 (zero) and o (letter o).


#5

Hi @jordan,

As @schoen said, you have a wrong redirection for your first 5 domains, example with t001:

curl -IkL t001.allsquaregolf.com
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 25 Apr 2017 18:00:02 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://tOO1.allsquaregolf.com/  <--- you are using O (capital letter) instead of 0 (zero)

curl: (6) Couldn't resolve host 'tOO1.allsquaregolf.com'  

Cheers,
sahsanu


#6

Oh man I feel really stupid right now… Thanks for pointing this out!! I actually didn’t notice when testing because I directly used https in order to access my whoami.html test files…
Obviously with wrong redirection that can’t work…
I tried debugging with curl as well, just like you did, but did not notice the O's instead of the 0s… Meh

Thanks guys, everything worked fine after correcting the redirections!


#7

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