Renew: Error getting validation data

Help
1

I’m trying to renew my certs on Ubuntu 16.04 with Apache and I’m getting the above error. It was setup according to this article. I’m fairly certain that the dry-run succeeded a few months ago when I first set this up, but now it’s not working. Any assistance would be appreciated. All of my domains are A records pointing to my IP.

My domain is: stonewallgaming.net

I ran this command: sudo certbot renew

It produced this output:

Processing /etc/letsencrypt/renewal/stonewallgaming.net.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator standalone, Installer apache
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Running pre-hook command: service apache2 stop
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for stonewallgaming.net
tls-sni-01 challenge for fleet.stonewallgaming.net
tls-sni-01 challenge for knights.stonewallgaming.net
tls-sni-01 challenge for swvg.stonewallgaming.net
tls-sni-01 challenge for www.stonewallgaming.net
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (stonewallgaming.net) from /etc/letsencrypt/renewal/stonewallgaming.net.conf produced an unexpected error: Failed authorization procedure. stonewallgaming.net (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/stonewallgaming.net/fullchain.pem (failure)

-------------------------------------------------------------------------------
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/stonewallgaming.net/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
-------------------------------------------------------------------------------
Running post-hook command: service apache2 start
1 renew failure(s), 0 parse failure(s)

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

   Domain: stonewallgaming.net
   Type:   connection
   Detail: Error getting validation data

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA 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.

My web server is (include version): Apache 2.4.18

The operating system my web server runs on is (include version): Ubuntu 16.04

My hosting provider, if applicable, is: DigitalOcean

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

2

The IP for:
fleet.stonewallgaming.net
knights.stonewallgaming.net
swvg.stonewallgaming.net
www.stonewallgaming.net
is 162.243.125.163

The IPs for:
stonewallgaming.net
are:
2001:4860:4802:32::15
2001:4860:4802:34::15
2001:4860:4802:36::15
2001:4860:4802:38::15
216.239.32.21
216.239.34.21
216.239.36.21
216.239.38.21

Is that expected?

3

It’s a custom domain redirect hosted on shared Google infrastructure.

You are not going to be able to keep using the TLS-SNI challenge in this case.

Try re-issue the certificate using --apache --preferred-challenges http perhaps.

4

In order for this to work, please also ensure that you're using Certbot 0.21.0 or later.

5

I removed the synthetic record and attempted to renew again, but received a new error:

Attempting to renew cert (stonewallgaming.net) from /etc/letsencrypt/renewal/stonewallgaming.net.conf produced an unexpected error: Failed authorization procedure. swvg.stonewallgaming.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout after connect (your server may be slow or overloaded), www.stonewallgaming.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout after connect (your server may be slow or overloaded), fleet.stonewallgaming.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout after connect (your server may be slow or overloaded), knights.stonewallgaming.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout after connect (your server may be slow or overloaded). Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/stonewallgaming.net/fullchain.pem (failure)

Any ideas why they might be failing? My sites are up and running properly.

6

The TLS cert is expired but that shouldn’t break the renewal.
I would try forcing an HTTP renewing as @schoen mentioned:
--preferred-challenges http

7

Is that method less secure than the default?

8

Not at all.
Nothing is ever passed that isn’t already practically public information.
If it were insecure, it wouldn’t even be an option!
It was recommended to you by a Certbot engineer and EFF employee.
Do you need more?

The one thing that you must always keep safe are private keys.

9

Wasn’t asking if it was insecure, just less secure. Mainly out of my own naivety on the subject matter. Thank you for reassuring me.

The http method worked! Thanks!! Any ideas why TLS didn’t work?

10

Not sure why it would fail.
Maybe you could run a cron job that calls two renewal requests…
The first with --preferred-challenges tls
The second with --preferred-challenges http
(built-in automatic failsafe backup plan FTW)
(nothing beats recursively repeating redundancy!)

11

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