Live certificate creation fails but --test-cert works perfectly!


#1

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


#2

hi @chka

can you grab the log files for the failed run and the run before that

Andrei


#3

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


#4

@cpu @schoen

leave it to you guys - i am under the impression the staging server performs the same validations as the live server ?

Andrei


#5

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"

#6

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.


#7

@cpu Here it is… on a previously non-existing subdomain (and hostname). I’ve even used your nick name as part of the domain :slight_smile: 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:

  • Congratulations! Your certificate and chain have been saved at
    /etc/letsencrypt/live/test1.cpu.str5.net/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"

#8

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


#9

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


#10

@cpu so, should I assume that test and live behave differently regarding their testing?


#11

There’s no intentional difference between staging and production in terms of validation process.


#12

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