Action is required to prevent your encrypt certificate renewals from breaking


#1

Hi, i received this email this morning:

Hello,

** Action is required to prevent your encrypt certificate renewals from breaking. **

Your Let's Encrypt client used ACME TLS-SNI-01 domain validation to issue to certificate in the past 60 days.

TLS-SNI-01 validation is reaching end-of-life and will stop working on ** February 13th, 2019. **

You need to update your ACME client to use an alternative validation method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your certificate renewals will break and existing certificates will start to expire.

If you need help updating your ACME client, please open a new topic in the Help category of the Let's Encrypt community forum:

  https://community.letsencrypt.org/c/help

Please answer all of the questions in the topic template so we can help you.

For more information about the TLS-SNI-01 end-of-life please see our API announcement:

https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209

Thank you,
  Let's Encrypt Staff

I manage several VPS with Ubuntu 16.x and 18.x
Are these commands the same for both Apache and Nginx?

Thank you


Action is required to prevent your Let's Encrypt certificate renewals from breaking Ubunty 14.04 (Trusty Tahr)
#2

Hi. I’m splitting your post into a different thread because your situation might be different in some ways.

Are you using Ubuntu 16.04, 18.04 or 18.10? Other versions?


Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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


#3

I don’t let certbot change my Nginx configuration, I just let it create the certificate files and edit the Nginx configuration files by hand. The same should work for Apache, too.

But if you let Nginx edit your configuration, I don’t know if and how this works.


Action is required to prevent your Let's Encrypt certificate renewals from breaking Ubunty 14.04 (Trusty Tahr)
#4

The certificates are all associated with the same email, and in the email the domain for which I received the email is not specified.

So it’s hard to talk about a specific case.
The domains are customers of the company I work for. I understand that they are public but I do not know if I can publish them here on the forum. I hope they are not strictly necessary.

  • I have a simple weekly cron that has always worked for all domains and servers: crontab renew
  • Use both Ubuntu 16.04 and Ubuntu 18.04
  • The versions of Apache and Nginx may be different for the various VPS. Apache 2.4.x - Nginx 1.14.x
  • The VPS are on OVH and on Hetzner
  • I have root access for all VPS
  • I do not use any control panel, only terminal.

EDIT: cerbot version: 0.26 and 0.28


#5

I’m sorry it’s so complicated. :slightly_frowning_face:

How was Certbot installed now? apt? Using Ubuntu’s repositories, or the PPA? certbot-auto?

Since the email didn’t specify which servers are still using TLS-SNI – or were recently – you’ll probably have to check all of them.

Can you upgrade all of your Certbot installations to a very recent version?

Edit:

Oh.

Okay, that’s sort of good and sort of complicated.

Both versions of Certbot should support HTTP validation fine, I think.

However, when HTTP and TLS-SNI validation are available, 0.28.0 uses HTTP by default and older versions use TLS-SNI.

You might want to go around testing certbot renew --dry-run --preferred-challenges http-01,dns-01 on all of your servers.

(You can simply use certbot renew --dry-run on the 0.28.0 servers, but it might be simpler to copy and paste the same command everywhere.)


#6

This command certbot renew --dry-run --preferred-challenges http-01,dns-01 seems to work on most servers.
On one in particular I found the following problem:

Attempting to renew cert (*******. Com) from /etc/letsencrypt/renewal/(*******.com.conf produced an unexpected error: Deserialization error: Could not decode 'status' ( 'ready'): Deserialization error: Status not recognized.

-------------------------------------------------- -----------------------------
Processing /etc/letsencrypt/renewal/www.*******.com.conf
-------------------------------------------------- -----------------------------
Cert not two for renewal, but simulating renewal for dry run
Plugins selected: Apache Authenticator, apache Installer
Renewing an existing certificate
Attempting to renew cert (www. *******. Com) from /etc/letsencrypt/renewal/www.*******.com.conf produced an unexpected error: Deserialization error: Could not decode ' status' ('ready'): Deserialization error: Status not recognized. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/*******.com/fullchain.pem (failure)
  /etc/letsencrypt/live/www.*******.com/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/*******.com/fullchain.pem (failure)
  /etc/letsencrypt/live/www.*******.com/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
-------------------------------------------------- -----------------------------
2 renew failure (s), 0 parse failure (s)

Certbot/0.22.2 (I had missed this version, the oldest one)
Apache/2.4.18
Ubuntu/16.04
Provider/OVH
Access/root


#7

That’s a very separate issue. It isn’t related to the TLS-SNI deprecation.

Depending on Certbot’s configuration, it might only be breaking --dry-run, and regular renewal against the production environment may be working.

So you might be fine, but it’s hard to test!

Can you upgrade Certbot to a newer version? That issue has been fixed.


#8

yes I should not have problems updating them, I try as soon as possible, thank you


#9

I came here because of the same email. I’m using Ubuntu 18.04 that comes with certbot 0.23.

From the discussion above, it looks like cerbot versions earlier than 0.28 have different preferences. Currently, my cron job for renewal is this:

certbot renew -q --no-self-upgrade

Am I correct that I should add --preferred-challenges http-01,dns-01 to that?

Otherwise, is there a reason to manually install certbot instead of using the Ubuntu package?


#10

Certbot 0.23 is recent enough that although the apache and nginx plugins still use tls-sni-01 by default, they should automatically switch to http-01 when it’s disabled in February, so you probably don’t really need to do anything. To test and be sure of this you can try a dry-run renewal:

certbot renew --dry-run --preferred-challenges http-01

If that works, you should be fine.

If you want a more recent version of certbot you can get it from the PPA - see https://certbot.eff.org for instructions. Note that in both cases the package installs its own systemd timer so your cron job might not necessarily have any effect if the timer kicks in first.


#11

On a server with cerbot 0.22.2 I tried both
certbot renew --dry-run
and
certbot renew --dry-run --preferred-challenges http-01

It seems that both commands work correctly.

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/tbiz.it/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
-------------------------------------------------------------------------------

Now which one should I use for the renewal and which one should I insert in the crontab? thank you


#12

You shouldn’t need to modify the cron job.
You should just use this from the prompt:
certbot renew --preferred-challenges http-01
[once it renews, it should update the renewal.conf file(s) automatically to use http-01]