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.
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.
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
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
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.
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!
