"no one is buying our expensive SSL certs. If we show businesses how unreliable a free service is, CTOs will make their admins buy from us."
or
"domain xyz's certificate is expiring. If we pay for a ddos, their site won't be able to renew and (customers wont go to the site due to expired cert/API people use wont work/we can take advantage of a compromised cert longer)"
And you get the extra benefit of being emailed[0] a few times beforehand if the certificate fails to renew as long you register your account with an email address.
Very much so. In my experience with nightly jobs in a corporate setting, the more often something happens, the more likely you are to catch an upstream dependency that breaks it.
The sooner you catch that breakage, the easier it is to get the resources (either from that team, or from your own team) to fix it. It’s a matter of “Oh we changed that API 2 months ago, everything is fine for us, all of our people have moved on to other tasks” versus “Oh our change broke you? We can revert it until we have a workaround”.
2 months, in most orgs, is enough time to figure something out before your entire business goes offline.
Let's Encrypt is a Certificate Authority, so, it doesn't have any "default behaviour" in respect of renewals, from the CA's point of view "renewing" is just a new issuance that happens to be for an identical subject. Let's Encrypt's rate limiting policies do actually care about that ("Duplicate Certificate Limit" five per week for each subject) but it can't put in place any particular policy about when you must or will renew.
CAs which charge for issuance often have a policy which implies an earliest sensible renewal date, because they will "carry over" remaining time on the previous certificate. There is a practical limit to that, (for example today your "one year" certificate from such a CA can only have up to 398 days until it expires, so renewing two months early won't make sense) because of the Baseline Requirements and/or trust store policies.
But if you're doing client development for ACME, the protocol Let's Encrypt implements for issuance, then yes, they'd tell you that they advise you to begin trying to renew with 30 days left. The EFF's Certbot tool, which a long time ago was just named "letsencrypt" implements this policy as do many other stand alone ACME clients.
Possibly testing or demonstrating a botnet. "For bragging rights" is a thing, as is advertising ("my botnet took down critical infrastructure, wanna buy my DDoS service?").
Not sure. Unless this is sustained for a long time it shouldn't affect autorenewals which are done well in advance of expiry. So it _shouldn't_ affect cert expiry unless people are still manually renewing and leaving it to last minute.
[edit] Unless the attackers identified a bug in certbot (commonly used autorenewal scripts), e.g what happens when LE is unavailable when autorenew is triggered - you'd hope it would retry periodically until LE is restored, but perhaps not. If not you could time the DDoS just right to ensure a specific cert does not get renewed even after the DDoS stops, then maybe a couple weeks later it would expire... But that's relying on such a bug existing and the site owners not noticing it (LE will also email the registered email address eventually regardless of autorenewal scripts), so maybe this is too much of a stretch.
Just last week our shared hosting provider was attacked and the attacker tried to brute-force it‘s way into a management API. I cannot image another reason as „fun“ and „just because we can“ because there‘s nothing to get [besides money after encrypting all data].
So I think the attacker just attacks LE because it‘s in the internet and he can.
They could be aiming for credentials to use in credential stuffing attack, a place to put malware, a place to distribute malware, servers to add to their botnet, a proxy to use for shady stuff, the list goes on. I see plenty of reasons to attack a hosting provider and its infrastructure?
Often a DDoS is used as a smokescreen/cover for an actual compromise. I guess the hope is that it gets unnoticed in all the noise and whilst all hands are busy at the pumps. Hope not!
I see in their status page that OCSP endpoints are also impacted. There could be any number of motivations including interfering with someone's ability to check if a certificate has been revoked.
Given the complete absence of information could it just be an accident? I think Wikipedia recently had performance issues where it turned out that a popular app was just pulling an image in the background and the app developers fixed it once they were notified.
The keys to the kingdom are ever more being placed in the hands of relatively few internet custodians. Figuratively here of course, since the private keys are generated locally and never transmitted to LE.
Is it really a single point of failure though? Certificates are renewed well in advance, and there are several free alternatives with ACME support to LetsEncrypt today.
Switching to a new provider in case LetsEncrypt goes down is as simple as updating your scripts.
it's better to assume that people will simply do everything that is possible, you can't open umbrella in your butt so that can be assumed not to be done, but everything possible should be assumed done/to be done sonner or later; motivation of "because I can" is simply enough.
or
"domain xyz's certificate is expiring. If we pay for a ddos, their site won't be able to renew and (customers wont go to the site due to expired cert/API people use wont work/we can take advantage of a compromised cert longer)"
Just some possible but implausible scenarios.