on
Let's Encrypt Notice, ACME TLS-SNI-01 Deprecation, Certbot Upgrade
Today I received an email from Let’s Encrypt regarding one of my domains. The cert was renewed recently with a deprecated validation method and therefore needs updating.
I’ve received one email like this before for a different domain on a different server, but couldn’t find my notes, so decided to publish them here so they can be found by other people.
Hello,
Action may be required to prevent your Let's Encrypt certificate renewals from
breaking.
If you already received a similar e-mail, this one contains updated
information.
Your Let's Encrypt client used ACME TLS-SNI-01 domain validation to issue a
certificate in the past 7 days. Below is a list of names and IP addresses
validated (max of one per account):
example.com (1.2.3.4) on 2019-03-04
TLS-SNI-01 validation is reaching end-of-life. It will stop working permanently
on March 13th, 2019. Any certificates issued before then will continue to work
for 90 days after their issuance date.
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.
Our staging environment already has TLS-SNI-01 disabled, so if you'd like to
test whether your system will work after March 13, you can run against staging:
https://letsencrypt.org/docs/staging-environment/
If you're a Certbot user, you can find more information here:
https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210
Our forum has many threads on this topic. Please search to see if your question
has been answered, then open a new thread if it has not:
https://community.letsencrypt.org/
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
My server is an Ubuntu Xenial server running my site behind a Nginx proxy, using Let’s Encrypt v0.25.0.
We’re going to follow these instructions given in the email above.
Diving in I can see my certbot is old, so let’s upgrade it:
$ certbot --version
certbot 0.25.0
We’ll follow the instructions here once Nginx and Ubuntu 16.04 (Xenial) is selected:
$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository universe
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install certbot python-certbot-nginx
And we’ll check what version we’re on now:
$ certbot --version
certbot 0.31.0
The line just below here helps us remove all references to tls-sni-01, but
let’s actually see what that means. Inside /etc/letsencrypt/renewal/ I have
one file (multiple on other servers, but just one here) named as
example.com.conf. Looking inside I can’t see any files with tls-sni-01 so I
suspect the following command won’t actually do anything:
$ sudo sh -c "sed -i.bak -e 's/^\(pref_challs.*\)tls-sni-01\(.*\)/\1http-01\2/g' /etc/letsencrypt/renewal/*; rm -f /etc/letsencrypt/renewal/*.bak"
As suspected nothing happened, so I guess that’s fine. If you were using a different version of certbot, renewed at different times, or based on some other factors, your command may well have done something.
And the final test is now:
$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Waiting for verification...
Cleaning up challenges
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/example.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/example.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IMPORTANT NOTES:
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
It looks like we’re all good to do it properly now.
$ sudo certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not yet due for renewal
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certs are not due for renewal yet:
/etc/letsencrypt/live/example.com/fullchain.pem expires on 2019-06-02 (skipped)
No renewals were attempted.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Interesting. Since we only renewed last week and we usually get 2 months before we renew again (ie. the cert last 90 days, but they generally renew with 30 days left), then it says we don’t need a new cert. However, even though the dry-run worked, I’d just like to make sure we get a new cert now and not have to come back to the server.
Let’s try this instead (remember, we’re using Nginx):
$ sudo certbot --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: example.com
2: www.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1,2
Cert not yet due for renewal
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/example.com.conf)
What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (limit ~5 per 7 days)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/example.com.conf
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/example.com.conf
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Traffic on port 80 already redirecting to ssl in /etc/nginx/sites-enabled/example.com.conf
Traffic on port 80 already redirecting to ssl in /etc/nginx/sites-enabled/example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Your existing certificate has been successfully renewed, and the new certificate
has been installed.
The new certificate covers the following domains: https://example.com and
https://www.example.com
You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=example.com
https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com/privkey.pem
Your cert will expire on 2019-06-12. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew *all* of
your certificates, run "certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
So yay! All is good in the world.
You’ll notice that as well as choosing to renew & replace the cert, I’m also
redirecting http requests over to https. In my Nginx config I’m also
redirecting www.example.com to example.com so any of the following will all
redirect to https://example.com:
http://example.comhttp://www.example.comhttps://www.example.com
And finally, you can see by the following two lines that we’re now using the
http-01 validation method, which was the whole reason of the original email
and therefore this adventure.
http-01 challenge for example.com
http-01 challenge for www.example.com
Have fun!
Cheers, Chilts
(Ends)