Failed authorization for renewal

Server
1

I’m having issues renewing a certificate that I just got notified by through the mailing service.

I originally did this to make a certificate and move it to my Go webserver:

certbot certonly --standalone -d espaldd.com -d www.espaldd.com
cp /etc/letsencrypt/live/espaldd.com/fullchain.pem /home/espal/go/src/espaldd.com/espal/
cp /etc/letsencrypt/live/espaldd.com/privkey.pem /home/espal/go/src/espaldd.com/espal/
chown espal:espal /home/espal/go/src/espaldd.com/espal/fullchain.pem
chown espal:espal /home/espal/go/src/espaldd.com/espal/privkey.pem

Doesn’t matter if I try certbot renew or certbot certonly with option 1. I also had my server turned off, but to no effect.

Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for espaldd.com
tls-sni-01 challenge for www.espaldd.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. espaldd.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data, www.espaldd.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data

What am I doing wrong? All other articles don’t really give me a sense of what the best practice is in this situation.

2

Hi @Allendar,

In this case the certificate authority would be trying to make an inbound connection on port 443 and expect to reach your Certbot process there. Do you expect that would work? There’s no firewall or anything restricting connection to port 443?

3

Hi @schoen,

Thank you for your response.

My ufw is set to the following:

To                         Action      From
--                         ------      ----
443/tcp                    ALLOW       Anywhere                  
80/tcp                     ALLOW       Anywhere                  
36022                      ALLOW       Anywhere                  
8080/tcp                   ALLOW       Anywhere                  
8443/tcp                   ALLOW       Anywhere                  
443/tcp (v6)               ALLOW       Anywhere (v6)             
80/tcp (v6)                ALLOW       Anywhere (v6)             
36022 (v6)                 ALLOW       Anywhere (v6)             
8080/tcp (v6)              ALLOW       Anywhere (v6)             
8443/tcp (v6)              ALLOW       Anywhere (v6)

Maybe it’s UDP?

4

Is your Go web server still running at the time that you try to do the renewal? In order to use the --standalone method, the port has to be free, not bound by another process, at the time that the standalone server tries to prove your control over the domain name.

Edit: you said you had your “server turned off but to no effect” — did you see exactly the same error message in both cases?

5

I disabled ufw and turned down my server again. I get this output:

root@ubuntu-512mb-ams2-01:/etc/letsencrypt/live/espaldd.com# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/espaldd.com.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for espaldd.com
tls-sni-01 challenge for www.espaldd.com
Waiting for verification...
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/espaldd.com.conf produced an unexpected error: Failed authorization procedure. www.espaldd.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data, espaldd.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data. Skipping.

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/espaldd.com/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

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

   Domain: www.espaldd.com
   Type:   connection
   Detail: Error getting validation data

   Domain: espaldd.com
   Type:   connection
   Detail: Error getting validation data

This is part of the error log (trying to censor, as I’m not sure whats sensitive):

  "challenges": [
    {
      "type": "tls-sni-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:connection",
        "detail": "Error getting validation data",
        "status": 400
      },
      "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/SENSORED/SENSORED",
      "token": "SENSORED-Wh2ilY",
      "keyAuthorization": "SENSORED",
      "validationRecord": [
        {
          "hostname": "www.espaldd.com",
          "port": "443",
          "addressesResolved": [
            "95.85.53.182"
          ],
          "addressUsed": "95.85.53.182",
          "addressesTried": []
        }
      ]
    },
6

@jsha, could you please take a look to see what the underlying cause of this error was?

7

Will this help too?

2017-07-08 18:28:27,225:INFO:certbot.auth_handler:Cleaning up challenges
2017-07-08 18:28:27,229:DEBUG:certbot.plugins.standalone:Stopping server at 0.0.0.0:443...
2017-07-08 18:28:27,718:WARNING:certbot.renewal:Attempting to renew cert from /etc/letsencrypt/renewal/espaldd.com.conf produced an unexpected error: Failed authorization procedure. espaldd.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data, www.espaldd.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data. Skipping.
2017-07-08 18:28:27,723:DEBUG:certbot.renewal:Traceback was:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/certbot/renewal.py", line 413, in handle_renewal_request
    main.obtain_cert(lineage_config, plugins, renewal_candidate)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 659, in obtain_cert
    action, _ = _auth_from_available(le_client, config, domains, certname, lineage)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 104, in _auth_from_available
    renewal.renew_cert(config, domains, le_client, lineage)
  File "/usr/lib/python2.7/dist-packages/certbot/renewal.py", line 296, in renew_cert
    new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains)
  File "/usr/lib/python2.7/dist-packages/certbot/client.py", line 265, in obtain_certificate
    self.config.allow_subset_of_names)
  File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 77, in get_authorizations
    self._respond(resp, best_effort)
  File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 134, in _respond
    self._poll_challenges(chall_update, best_effort)
  File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 198, in _poll_challenges
    raise errors.FailedChallenges(all_failed_achalls)
FailedChallenges: Failed authorization procedure. espaldd.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data, www.espaldd.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data

2017-07-08 18:28:27,726:DEBUG:certbot.main:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.11.1', 'console_scripts', 'certbot')()
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 882, in main
    return config.func(config, plugins)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 688, in renew
    renewal.handle_renewal_request(config)
  File "/usr/lib/python2.7/dist-packages/certbot/renewal.py", line 430, in handle_renewal_request
    len(renew_failures), len(parse_failures)))
Error: 1 renew failure(s), 0 parse failure(s)
8

This shows up in the logs as “connection refused.” Note that once https://github.com/letsencrypt/boulder/pull/2843 lands in production next Thursday, “connection refused” will be provided in the error message.

9

Could you enlighten why this happens while the firewall is turned off?

10

It strongly suggests to me the presence of some other firewall-like device or software that is preventing these connections from getting through.

Are you familiar with using netcat? Could you do a test from outside of your server’s network with netcat to see if it can make a connection to an nc -l 443 process on the server?

11

Running nmap for port 80/443 when my Go server is not running it says they’re closed. When running my Go server it says;

80/tcp  open  http
443/tcp open  https

I listened with your command on the server but even when visiting the website or scanning with nMap it showed nothing.

I’m not a network expert sadly. Can it be that the OS’ routing messes with this and that it only worked the first time because that was the init and now it’s the renew call?

FYI: My server is a Digital Ocean droplet with the latest Ubuntu installed. I don’t think I really tempered with anything else than installing ufw

12

You were running nc -l 443 on the server, but nmap showed "closed" at that point?

13

Casus 1:

  • ufw is disabled
  • The Go webserver is running on 80 and 443
  • I run nc -l 443 on the server
  • Then run sudo nmap -sS -O -p443 95.85.53.182 from my local computer and it says 443/tcp is open over https
  • When checking the server nc hasn’t reported anything

Casus 2:

  • ufw is disabled
  • The Go webserver is shutdown
  • I run nc -l 443 on the server
  • Then run sudo nmap -sS -O -p443 95.85.53.182 from my local computer and it says 443/tcp is closed over https
  • nc hasn’t reporting anything
14

Instead of nmap, can you use nc www.espaldd.com 443? Then you should be able to type in one nc and see the text appear in the other nc (after you press Enter).

15

hi @Allendar

You need to differentiate between a port being open and a port having an application functioning as expected

For example: you may write some code that listens to port 443 but if there are no handlers etc to deal with the queries properly then things won’t work

It seems that your go application is not running when I checked however as @schoen pointed out earlier you should not have the Go Web Server and standalone running at the same time

Andrei

1 Like
16

@ahaw021 Thank you for your answer. I didn’t have them running at the same time. The documentation also states that. The last time I was testing I didn’t reboot the server again as I was waiting for a response and nothing crucial is running on the domain yet anyway, so that’s why you got no response on the domain browser call.

If I run the server and besides that run nc -l 443. And then on my local computer run nc www.espaldd.com 443 it stays open. Then I send some random messages followed by enter and nc on the server reads nothing, but the Go server does detect it.

Then I shutdown the Go server. And re-run nc -l 443 and the nc command local. The nc command just instantly exits.

With literally everything turned off and running certbot certonly --standalone -d espaldd.com -d www.espaldd.com it still just says it can’t authorize.

I also check if the Droplet has the new Firewall feature enabled and it’s all not enabled.

Guess I’ll try a clean Droplet somewhere this week. I have no idea either…

17

Same trouble. Any benefit response? :flashlight:

18

a droplet instance running a go webserver?

19

hi @Allendar

Looks like you have everything sorted with a valid certificate

What ended up being the problem? (just so other can benefit)

image.png771×313 4.79 KB

Andrei

20

It’s not working. That’s still the current certificate running. It expires in a few days. The problem is that the renew process doesn’t work. The initial request worked perfectly.

And yes; running Go webserver is not very hard on a Droplet. It binds a port just like Nginx and Apache do.