Failed authorization procedure 20170111

Help
1

Please fill out the fields below so we can help you better.

My domain is: www.taygeta.com

I ran this command:./certbot-auto --apache certonly

It produced this output:

 Performing the following challenges:
tls-sni-01 challenge for www.taygeta.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.taygeta.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 206.55.232.80:443 for TLS-SNI-01 challenge

My operating system is (include version):
debian 7.11
My web server is (include version):
apache
My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know): y
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): n

IMPORTANT NOTES:
apache2ctl configtest returns OK
https://www.ssllabs.com/ssltest/analyze.html rates the site A

DNS is properly configured both forward and reverse

dig www.taygeta.com
    www.taygeta.com.	86400	IN	A	206.55.232.80

dig -x 206.55.232.80
     80.232.55.206.in-addr.arpa. 86400 IN	PTR	www.taygeta.com.

but the debug log shows:

  "identifier": {
    "type": "dns",
    "value": "www.taygeta.com"
  },
  "status": "invalid",

this is the only clue I have that the LE server is unhappy but I have no idea why

2

That’s kinda weird, I can connect succesfully from my end too (The Netherlands).

Perhaps some firewall issue on your end with selective blocking of certain IP’s?

3

oh yeah I forgot. Since this is our public web server the firewall allows inbound 80 and 443 from the world. And the DNS server allows TCP and UDP 53 from the world.

4

Perhaps this incident has something to do with it: https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/5876be6e1bd119502a00081e

5

The outage is over, and no change

This inability to solve this is an unfortunate show stopper. I have to get a $$ cert in a few days

6

@cpu, any ideas about the source of this error on the LE side? … if the ACME error message is being echoed correctly it sounds like it’s not actually DNS-related.

1 Like
7

@schoen The error being reported is accurate. From our end the only additional information I can add is that the connection wasn’t refused, but timed out.

Could this be a certbot configuration issue? How does ./certbot-auto --apache certonly provision the TLS-SNI-01 challenge setup when there is already an existing HTTPS configuration on 443 as in this case?

8

Can you guys from LE actually traceroute to that address?

Edit: UDP seems blocked. ICMP works.

# traceroute -I -f 6 www.taygeta.com
traceroute to www.taygeta.com (206.55.232.80), 30 hops max, 60 byte packets
 6  pax-brdr-01.inet.qwest.net (63.146.26.233)  219.972 ms  219.920 ms  219.909 ms
 7  svl-edge-23.inet.qwest.net (67.14.12.82)  182.663 ms  182.641 ms  182.638 ms
 8  208-46-220-242.dia.static.qwest.net (208.46.220.242)  189.602 ms  189.590 ms  189.792 ms
 9  er3.sns1.got.net (207.111.241.57)  186.327 ms  186.317 ms  186.434 ms
10  mbay.got.net (207.111.222.6)  182.424 ms  182.415 ms  182.402 ms
11  taygeta-fe1-0.2.core-01.mbay.net (206.55.246.130)  192.197 ms  190.847 ms  190.796 ms
12  www.taygeta.com (206.55.232.80)  187.387 ms  187.358 ms  187.442 ms
9

Thats an interesting question, just how IS that supposed to work. Is my apache server supposed to be off when I’m doing this ?

10

did the test, apache needs to be running already

11

Since you’re using certonly mode anyway, it might be worth trying the webroot plugin. If the webroot plugin works, it would rule out network issues (unless they’re specific to port 443), and would point towards an issue with the temporary apache configuration change certbot uses to validate domain ownership or something like that. The command for webroot would look roughly like this (note that you’ll have to explicitly provide the domains with this plugin, certbot won’t read them from your apache configuration):

certbot-auto certonly --webroot -w /var/www/html -d taygeta.com -d www.taygeta.com

/var/www/html should point to the directory your DocumentRoot directive is pointing to.

If that one fails with a network-related error as well, you’re probably looking at a network issue somewhere between you and all the network hops to Let’s Encrypt. These tend to be close to impossible to debug from your end.

1 Like
12

I asked our operations team to try and rule this possibility out but it would be great if we could rule out other more mundane possibilities in parallel!

Thanks @pfg

1 Like
13

webroot worked! Thanks. It looks like it was a good idea to run it in in certonly mode if it silently had problems with the apache configuration

1 Like
14

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