I’m trying to create a certificate using certbot on a server and I’m getting the following error:
Domain: t50.live.sreedhar.org
Type: connection
Detail: Failed to connect to 158.69.54.57:443 for TLS-SNI-01
challenge
Surprisingly enough, if I add --test-cert the certificate is created without any problems. What am I doing wrong? The command I’m using is:
certbot-auto certonly --nginx -d t50.live.sreedhar.org -n --agree-tos --email sreedhar@sreedhar.org
Thanks
hmmm… I found out what the problem was and solved it (we use nginx as a reverse proxy, so it was impossible to letsencrypt to find the random text on the local drive). But now, the big question is: why staging works? It should fail, with the exact same error as the live one, unless the --test-cert doesn’t do a full validation for the domain but just a dummy one!!!
leave it to you guys - i am under the impression the staging server performs the same validations as the live server ?
Andrei
These commands below are sequential and taken directly as copy+paste from my terminal. I think they prove that test and live, definitely don’t perform the same tests:
root:/etc/letsencrypt# certbot-auto certonly --nginx -d t50.live.sreedhar.org -n --agree-tos --email sreedhar@sreedhar.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for t50.live.sreedhar.org
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. t50.live.sreedhar.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 158.69.54.57:443 for TLS-SNI-01 challenge
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: t50.live.sreedhar.org
Type: connection
Detail: Failed to connect to 158.69.54.57: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.
root:/etc/letsencrypt# certbot-auto certonly --nginx -d t50.live.sreedhar.org -n --agree-tos --email sreedhar@sreedhar.org --test-cert
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for t50.live.sreedhar.org
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0004_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0004_csr-certbot.pem
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/t50.live.sreedhar.org/fullchain.pem. Your
cert will expire on 2017-06-21. To obtain a new or tweaked version
of this certificate in the future, simply run certbot-auto again.
To non-interactively renew *all* of your certificates, run
"certbot-auto renew"That's correct - it's the same validations.
I don't believe this is the case. I think that you had a pre-existing valid authorization for the domain in the staging environment that was reused. See this thread for more information.
If you want to test this theory, create a brand new account and try the request with staging and production. I expect that if the misconfiguration that prevents prod issuance from working is still present then both environments will fail using a new account that has no preexisting valid authorizations.
@cpu Here it is… on a previously non-existing subdomain (and hostname). I’ve even used your nick name as part of the domain 
Also here, the commands are strictly sequential (one after the other with nothing else in between) :
root:/# certbot-auto certonly --nginx -d test1.cpu.str5.net -n --agree-tos --email sreedhar@sreedhar.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for test1.cpu.str5.net
Waiting for verification…
An unexpected error occurred:
ConnectionError: (‘Connection aborted.’, error("(104, ‘ECONNRESET’)",))
Please see the logfiles in /var/log/letsencrypt for more details.
root:/# certbot-auto certonly --nginx -d test1.cpu.str5.net -n --agree-tos --email sreedhar@sreedhar.org --test-cert
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for test1.cpu.str5.net
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0011_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0011_csr-certbot.pem
IMPORTANT NOTES:
@chka, you don’t have a firewall or anti-abuse proxy that would selectively block incoming connections from some IP addresses and not others, do you? The staging server’s verification should send the same kind of request, but it could come from a different IP addresses.
There are some rules banning “trouble makers” (mainly automated rules from fail2ban) but nothing to affect letsencrypt. Don’t forget that I have managed to get the certificate once I realized that my nginx, acting as a reverse proxy, needs different handling than a standard nginx serving content locally. So, the problem is not with the firewall as I’ve managed on the exact same server to get the live certificate. But my earlier problem, uncovered a discrepancy between the test and live letsencrypt and that’s what I wanted to bring to the developers of that product
There's no intentional difference between staging and production in terms of validation process.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.