The main thing I'm thankful for Let's Encrypt for is breaking the idea that an SSL-secured website is somehow magically less likely to be phishing or even anything but claiming it's the data from the domain you connected to, without changes.
Mainly this was propagated by EV cert sellers, but it was all kinda silly.
Let's Encrypt's own community forums get posts every day from people saying, wait, I got scammed/ phished/ whatever on this site, it has your certificate, shouldn't you shut it down? They do have a page to link those enquiries to, explaining the policy (and indeed they even have standard legal briefs because periodically lawyers get the same idea and a court has to be told why that's wrong).
It would be interesting to know if, say, US citizens write to the Department of State saying hey, revoke this guy's passport, I heard he ripped off somebody on Craig's List...
It's frustrating because certificate revocation doesn't even really work, since most browsers don't check for it due to the various performance/privacy issues it causes. (OCSP stapling doesn't help here, because a scammer just won't use it.)
At best Let's Encrypt could revoke the cert and block them from getting a new one, but then the scam site is still good to go for 90 days. I doubt most phishing sites even last that long.
What does work, and relatively quickly, is having the web host shut down the site (basically instant), having the registrar revoke the domain (takes effect as soon as DNS caches start expiring) or adding it to the various phishing site lists used by browsers. (Not sure how often those update, I assume at least daily.)
I hope that the misguided people asking LE to shut down the domain are at least trying to contact the web host, registrar, and the safe browsing list people before hassling the (mostly volunteer) folks on the LE forums.
> Mainly this was propagated by EV cert sellers, but it was all kinda silly.
I feel like it really started back in early(ish) days of online shopping. I remember "never enter your credit card details without looking for the lock icon" being drilled into people.
EV certs definitely took this idea farther, especially as domain-validated certs became more common & cheaper.
That idea is unfortunately alive and well. Many organizations require it, much like they require 90-day password rotation and other questionable security standards.
Some password managers have automation to change passwords, but it's... janky. I think they've manually implemented stuff for some sites (and it works for some sites and managers, not all sites).
From the context I'm going to guess that this isn't a pithy version of a nuanced take on the larger problem here but just your first instinctive reaction. Here's how we got here in two related but distinct elements
A. Why PKIX certificates expire, and why the policy in the Web PKI today is that they must expire in about a year (maximum 398 days)
The certificate binds a public key (and thus the associated private key which only one entity should have) to one or more names, typically DNS names. The issuing certificate authority says you should trust that this name is controlled by whoever has this key.
The CA confirmed (today, using one of more of the Ten Blessed Methods) that this is true when they issued it, or in some cases, within some specified period up to that point. But just because it was true then, doesn't mean it's true now. As time passes our confidence in this should reasonably wane.
Historically these certificates lasted 5 years or even more (Chrome assumes that certificates which pre-date formal policy expired after no more than 10 years). That's a long time, it's long enough for a domain to be registered for a legitimate purpose, used for a while with a certificate, given up and not renewed, a new owner takes the domain, they sell it after a while, and their buyer still has to worry that the first certificate from years ago is still valid and might be out there. Not great. How many domains do you control whose provenance you're sure of for at least five years ?
Now, in principle a CA has options to explicitly revoke a certificate before it expires. The Online Certificate Status Protocol is the most modern of them, but OCSP is not enforced universally and even where it's enabled browsers will typically give up if they can't get a Yes/No answer quickly. So this is why OCSP has been described as a "seat belt that snaps when you crash".
As a result we do not have much trust in OCSP. Shorter expiry dates mean that the information in the certificate was verified more recently, which means it's much more likely that it's still relevant to you at the point where you trust it.
The maximum expiry also sets an effective best agility for any security changes that are short of do-or-die. Something like SHA-1 deprecation for example, needed to take several years because it was impossible to go much faster without breaking a lot of important stuff that had 39 month certificates. Today you could reasonably imagine saying you've got an important but not do-or-die change, and have it done by say August/September 2023.
And agility leads us into...
B. Why Let's Encrypt certificates expire in just 90 days.
From the outset the primary purpose of Let's Encrypt is to encourage automation. The reason the certificates are $0 isn't just because they're nice, it's because machines don't have wallets. If the certificate costs $1 then your Caddy server can't get one without giving it your credit card details. Would you do that? Maybe, but it's more friction.
Automation is one of those things that even if it's easy, outside of a new nerds like me, will get rationalised as low priority. The certificates expire in 5 years? Eh, we'll sort it out when it happens, no hurry. Three years? Eh, I don't think we even have a diary for three years out, I'm sure I'll remember. 825 days? Still not sure we have a calendar for stuff like that, I'll put it on the TODO list for Jim and then when Jim leaves for a senior job elsewhere in 18 months it's forgotten.
Ninety days means that way more people get annoyed and actually automate it and when they do reliability shoots up, because machines are boringly reliable. This is true at scale (at work software called "Cortex" looks after this problem, it used to flag all the manual renewals for human attention, and guess what they would still not happen every time but now it just automatically renews all the Let's Encrypt certificates in a timely fashion) but also in people's home setups like the Caddy on this PC which just exists to emit 40x messages.
Now, one of the things that isn't said here is that although certificates should be renewed frequently because of the revocation hole, you don't need to rotate keys every 90 days if that doesn't seem appropriate. What is being renewed is the CA's assertion that this name corresponds to this key.
Certbot will cheerfully re-use a CSR with the same exact keys in it, and same names wanted, over, and over, and over again unless there's a problem with the keys or you need to change the list of names or whatever, you can do this indefinitely.
Mainly this was propagated by EV cert sellers, but it was all kinda silly.