Alert: Let's Encrypt to revoke about 2 million HTTPS certificates in two days Let's Encrypt, a non-profit organization that helps people obtain free SSL/TLS certificates for websites, plans to revoke a non-trivial number of its certs on Friday because they were improperly issued. In a post to the Let's Encrypt discussion community forum, site reliability engineer Jillian explained that on Tuesday, a …
Wouldn't help in this case, as these certificates were revoked due to a technical reason and not due to their 90 day lifecycle.
Still love as a company gets bigger (not actually), the more they lean on estimated percentages a fatal flaw caused than the raw victim count.
It's like saying only 15% of the US population (excluding the Canadian side) experienced a power outage in August 2003.
Hell, that'd be like saying that a population slightly larger than California, Colorado and Connecticut lost power... just 3/50th of the states...
90 days was chosen for a couple reasons.
One of which was to force automation.
With 1 year certificates, inertia would have caused LE certs to be managed by hand as a majority of certs from old CAs are. 90 days, nobody goes live with that before automating them.
The other one is stated as "They limit damage from key compromise and **mis-issuance**".
Which ties in real well with the current situation: why not let them expire?
Even better if they _reduced_ the default (and maximum) lifetime to 5 days. This would have several effects:
- Firstly, they wouldn't have to do anything in order to meet their five day deadline (because all the affected certificates would expire anyway.
- Secondly, even lazy verifiers that don't bother checking the CRL/OCSP will pick up the cancellation.
- Thirdly, _everybody_ would have to automate their certificate renewals (like you should anyway, but the automation may not handle an out-of-cycle renewal).
The only downsides I can see are:
- Let's Encrypt would need a _lot_ more servers. (Renewing every ?3? days instead of every ?80? is an almost 30-fold increase). (But they don't need to support CRL or OCSP.)
- If someone could take Let's Encrypt offline for a few days, it would wipe out a large chunk of the web.
GAH, no, please no! An organization I support is behind a cable modem, and due to ISP-enforced port limits the only approach I can currently use is the DNS verification. The DNS provider has no provision for automating the record update so I have to do this manually. I'm probably not the only one who does NOT need yet another weekly critical-to-someone task.
I sympathise, but it is probably about time to move your client's cert issuing to a cheap cloud server with the org behind the cable modem pulling the new certificate down when it is updated. In fact, it could be a free-tier AWS instance as it only needs to run a few minutes a month.
While you are about it - maybe move their DNS to a hoster who supports ACME - no need to change the registration just change the nameserver delegation.
Home users running free DuckDNS style DNS's don't need a middle-man, ACME works right out of the box. But, does LetsEncrypt work without ALPN-01 in this case? I really don't know. All my VPS's are setup in places that this doesn't matter, but for people hosting from home or at least along the lines of more independent state this could be an issue.
I really don't know a lot about all of this (obviously), but I do know that some home users can not validate across common ports (80/443) so they resort to ALPN (which at one point 'certbot' did NOT support... directly).
"...can easily avoid expired ones."
Can't lie, a couple years back it took me a lot longer than I'd admit to setup a shared cert between 2 dockers :-/ (one web, the other mail which didn't like the same filename OR symlinks so the cp/mv operations at renewal time were... finicky/race-condition'icky.). Me no good computers :-/
Nope, the whole idea is to get certificates automated. A full year would lead to a lot of people renewing manually and forgetting to do so.
90 days is a reasonable compromise where if you are unable to fully automate it you can deal with it manually, with some hassle.
30 days would be better as old certificates would become invalid much quicker.
Shorter periods than that would become burdensome.
As an example, I have a system set up where certificates are acquired on one server, then transferred to another in a backup cycle. The backup server then checks for newer certs and applies them some time later. Currently that process can take 2+ days (assuming the backup is successful). Yes I could streamline that process, but for policy reasons the destination server cannot renew itself.
Because the certs are free, there are also a larger number of people requesting them without really good certificate and especially key management (not that those paying are often more careful, but there are less because of the money involved) - with a longer validity there could be large number of abandoned or compromised certificates still valid. This way they aren't valid for too long unless one doesn't keep on renewing them.
I completely disagree. The aim is to force automation and it works.
I have had warnings that my certificates would fail soon and I then have to go and figure out which my automation isn't working. I hate working dealing with certificates and figuring out why certbot isn't working. I have performed a manual refresh before just to get past the issue. But the second time it happens 90 days later, you do something about it.
I guarantee if it was a year, I wouldn't bother trying to fix it.
I didn't know that OIDs are used for anything other than SNMP.
Why isn't certificate pinning the default? Why can't I use my old self-signed certificate to sign my new self-signed certificate? There is no technical reason, it is just not part of X.500. Is it because CAs are an important backdoor that certificate pinning would close?
Or is trust on first use (which most people do all the time with SSH) perceived as the bigger threat? That doesn't explain why Apple's app store doesn't allow it for user apps though.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
