Valentines will be nice
Roses are red
Violets are blue
The website is down
Should have used TLS 1.2
Get in the bin: Let's Encrypt gives admins until February 13 to switch off TLS-SNI-01
If you're still using TLS-SNI-01, stop: a year after a slip-up allowed miscreants to claim Let's Encrypt certificates for domains they didn't own, the free certificate authority has announced the final sunset of the protocol involved. In January 2018, Let's Encrypt discovered that validation based on TLS-SNI-01 and its planned …
-
-
-
Tuesday 22nd January 2019 18:55 GMT tialaramex
Re: Proof of ownership
tls-sni-01 was Let's Encrypt's implementation of one of the Ten Blessed Methods authorized for proving you control a DNS name to a Certificate Authority, specifically method 3.2.2.4.10. TLS Using a Random Number
They also offered dns-01, an implementation of method 3.2.2.4.7 DNS Change and http-01, an implementation of method 3.2.2.4.6 Agreed‐Upon Change to Website. Those are unchanged, they still work, if you're using either of them everything remains as before. Most Let's Encrypt users are using one or the other of these methods.
But tls-sni-01 is a problem because it can be tricked by sufficiently half-arsed bulk hosting or service provider setups into letting a bad guy have certificates for somebody else's names (see linked example in article). So, various smart people invented a new implementation of 3.2.2.4.10 called tls-alpn-01 which you can use instead of tls-sni-01 and isn't tricked by such mis-configuration. Let's Encrypt offers this today, and will continue to offer it after tls-sni-01 is forbidden.
If you have email setup for your Let's Encrypt certs, and didn't get warnings about this, you're fine. If you have warning emails, and you understand what you're doing, switch to either tls-alpn-01, or dns-01 or http-01 as appropriate. If you got warning emails and you don't understand what you're doing you're going to need somebody to help fix it for you or your certificates may expire in the next three months or so and not get replaced.
-
-
Tuesday 22nd January 2019 11:22 GMT PyLETS
Got the email, fixed it
I was emailed by LETSEncrypt to say that I was using the old protocol. This was the case on a Debian stable (stretch) server. Putting the new client just needed adding the backports repository to /etc/apt/sources.list and installing the backported certbot package over the outdated one in the main stretch repository. That's why for some purposes you should give an email address to those upon whose software and services you depend.
-
-
Tuesday 22nd January 2019 20:42 GMT Phil Endecott
Re: Got the email, fixed it
> Debian stable
Yes, I also run Debian stable and got the email, so upgraded certbot to the version in backports (0.25 to 0.28 I think). But I’m not entirely confident that it has fixed the problem, i.e. that it will now use a different method, because I don’t have any certs that will expire before the Feb cut-off. An earlier email would have helped I guess. Are you confident that simply upgrading certbot to the backports version is sufficient to fix it, without e.g. any config changes?
-
Wednesday 23rd January 2019 10:52 GMT Stuart 22
Re: Got the email, fixed it
No email which is good news but obviously I shouldn't assume I'm in the clear.
I presume I can wait till February 13th and carefully monitor the renewals thereafter (I have a nice little script for that). If I get a failure I assume I still have 30 days to fix the problem (mine auto-renew 60 days into the 90 day validity).
-
-
-
-
Tuesday 22nd January 2019 18:54 GMT Norbie
Too many LE devices, no clue as to which need updating
It would be helpful if the Let's Encrypt email that I have received informing me that I have a Let's Encrypt client that used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days, told me what the hostname was so I had a chance of discovering which of the many servers / devices that I have LE implemented on is affected!
Biting the hand that feeds IT
