Let's Encrypt has permanently disabled TLS-SNI challenge. Package not compatible any more with LE

Bug #1745126 reported by Roope Lehmuslehto on 2018-01-24
54
This bug affects 10 people
Affects Status Importance Assigned to Milestone
python-letsencrypt (Ubuntu)
Undecided
Unassigned

Bug Description

Problem discussed in further detail here:
https://community.letsencrypt.org/t/solution-client-with-the-currently-selected-authenticator-does-not-support-any-combination-of-challenges-that-will-satisfy-the-ca/49983

Ubuntu 16.04 default letsencrypt-package currently fails all new certificates with error message: "Client does not support any combination of challenges that will satisfy the CA."

summary: - Let's Encrypt has permanently disabled TLS-SNI challenge.
+ Let's Encrypt has permanently disabled TLS-SNI challenge. Package not
+ compatible any more with LE
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in python-letsencrypt (Ubuntu):
status: New → Confirmed
Ame Nomade (ame-nomade) wrote :

So, yes the package is broken right now, as its first purpose is to obtain a certificate.

And as explained here: https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811
"Renewals will continue to work with TLS-SNI", and yes it's still working.

But it seems that the next LTS Bionic is already up-to-date, with the direct use of "certbot 0.21" as requested (it's right now the 0.21.1-1): https://packages.ubuntu.com/bionic/letsencrypt

So, maybe it's time to switch manually to "certbot", or wait for Bionic... and switch to "certbot"!

Brad Warren (bradmwarren) wrote :

I work at EFF and am an upstream developer of Certbot.

This issue has jumped in priority now that TLS-SNI support will be dropped on February 13th, 2019. See https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209.

While the TLS-SNI challenge was initially disabled over 10 months ago, an exception had been made for people renewing certificates they had previously obtained using the challenge. This exception is going away on the above date. This means that unless users manually intervene or are upgraded to a new version, certificate renewal will fail.

I pulled some numbers on this a couple months ago and found that there were nearly 10,000 unique Ubuntu 16.04 installations that were relying on this exception. This is for over 18,000 certificates covering over 30,000 domains. I certainly would like to avoid having all of these renewals fail.

It's worth noting that the package that actually needs to be upgraded here is the python-letsencrypt-apache package, however, for this package to be upgraded to a newer version, python-letsencrypt will need to be as well as the packages were being released in lockstep.

Please let me know if there's anything I can do to make this upgrade happen.

tags: added: xenial
removed: letsencrypt ssl tls-sni
AlpineCarver (acarv) wrote :

My domains are part of the 30,000 whose renewals will begin failing on March 13th, 2019.

Can this be fixed before then?

Yo (yobuntu) wrote :

It looks like it may not be fixed in time. There is a workaround that has worked nicely for me. The announcement for Let's Encrypt mentions this:
https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811

They suggest "If you use the certbot or letsencrypt command, you are using packages provided by your operating system vendor, which are often slow to update. If this is the case, you should probably switch to certbot-auto".

Here is how to switch to certbot-auto:
https://certbot.eff.org/lets-encrypt/pip-apache

For me, I had to add their PPA, install certbot, and then it recognised all my existing certificates that had been created via the letsencrypt command. You can test this by running
sudo certbot renew --dry-run
That will simulate doing a renew for your current certificates, so you should see everything coming through. It automatically adds a cron job or systemd timer to renew certificates that are expiring soon. This article was use in confirming the job for me because I couldn't see the Cron job (as had been suggested in the documentation):
https://stackoverflow.com/questions/48443791/certbot-where-is-packaged-automatic-renewal-cron-job
If you had a cron job set for the letsencrypt command, remember to comment it out.

The other benefit is that this should be kept more up to date.

Hope this helps.
Hope this helps.

Marc Deslauriers (mdeslaur) wrote :

The python-letsencrypt binary package is being replaced by the new python-certbot SRU that is currently in xenial-proposed and is being tracked in bug #1640978.

There is no actionable item to do in this bug, and it can be closed once the python-certbot SRU has completed.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers