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?
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):
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.
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
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
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:
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.
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
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]
