As SSL/TLS certificate lifespans shrink, IT departments must adapt to faster renewal cycles. This shift toward shorter lifecycles, driven by a need for better security, will soon create immense operational pressure.
We predict major internet instability on October 1, 2026, when expiring SSL certificates could begin disrupting global internet services.
This stark prediction is rooted in a fundamental policy shift already underway, an industry mandate driven by major browser vendors and formalized through the CA/Browser Forum.
[..] For organizations that issue certificates in March 2026, their maximum 6-month (approx. 200-day) term will expire in early October 2026. On the week of October 1, 2026, we expect to see headlines about unexpected outages as the wave of these first short-lived certificates begin to expire.
While some Fortune 500 companies with robust IT teams and abundant resources may weather the storm and avoid disruption thanks to proper planning and implementation of automated certificate management tools, the story will be different for smaller organizations with less resources.
(Score: 5, Insightful) by Anonymous Coward on Thursday April 02, @10:34PM (3 children)
The centralization of these certificates isn't about security. They make everyone beholden to certain authorities. Otherwise no website for you. Self signed? The browser pops a thousand warnings if it even lets you go to the site. http? no that's insecure, lets force https even if it doesn't exist.
now they will expire faster to keep you checking in with your masters. step out of line and your key is revoked.
meanwhile workplaces and god knows who else MITM this shit so they can decrypt it.
(Score: 3, Interesting) by Anonymous Coward on Friday April 03, @01:26AM (1 child)
They're pretending to solve a problem that isn't a huge deal in reality. Tons of people are clicking through warnings and getting phished/pwned anyway.
You'd get most of the same security without the overheads if they had used the ssh style system where you decide whether the server is OK or not at the start.
(Score: 5, Insightful) by RS3 on Friday April 03, @03:28AM
What's bugged me for years is all this worry about https and "security" when I'm just reading something and don't need security.
Then we have sites where we've put our personal info, that info then being shared / sold / hacked / stolen anyway.
(Score: 2) by darkfeline on Sunday April 05, @10:13PM
No it's not about control. Please shelve your conspiracy theories.
This is motivated by the very banal reason that revocation doesn't work. CRLs don't get updated. Faster expiry is way more reliable. And as a side effect, faster renewal cycles ensure that the renewal is either automated or at least a human is likely familiar with how to do it, as opposed to no one knowing how to or even that it has to be done every couple of years.
Join the SDF Public Access UNIX System today!
(Score: 5, Interesting) by Undefined on Thursday April 02, @11:26PM (1 child)
SSL certs nominally provide encryption. At least unless your site isn't compromised such that the cert has been collected by mad hatters. Or the threat of quantum decryption manifests in reality.
SSL certs nominally provide identification. At least unless your site isn't compromised such that the cert has been collected by mad hatters. And presuming the cert authorities haven't been fooled (yeah, they can be, I've done it with an image of my driver's license modified because my then state of residence's version of my name wasn't what all my other ID said... the cert authority swallowed the faked ID without question. No bad intent on my part, just bypassing the otherwise non-issue because who needs the headaches.)
Further security -- well, imaginary security, anyway -- is offered in the form of SSL-encrypted DNS request/replies. Of course all you end up with in the end is an IP, which can be trivially reversed, so... yeah. Not actually secure at all. Performative bullshit, more like.
What's (darkly) funny to me is that this stuff was supposed to make the Internet (not just the corporate part of it) better. So how did this all work out?
Initially, major cert "authorities" jumped right on this with price gouging. No surprise there. Hurray for greed, I guess.
Then there was some relief as others realized providing a cert as a cert "authority" was actually a near-zero cost once the setup hoops were jumped. Strangely enough, some cert "authorities" continue to price gouge to this day. It frankly amazes me, even with the low overhead, that they manage to continue to make a success out of that, as no one actually needs to pay those prices at this point. Oh well.
Then devs bowed to bad arguments and made their browsers shit and go blind when faced with self-signed certificates, with zero consideration or mechanisms for whether a site actually needed ID verification as opposed to just encryption, which would have made the problem go away. Even the awful warning sequences eventually became a brick wall.
And because HTTP/HTTPS negotiation occurs before a webserver can determine which website is actually being requested, mixing self-signed HTTPS sites -- even if that site is only for in-house use -- with HTTP sites on the same machine became a freaking nightmare of invalid and misdirected responses. Which, while certainly bad enough on its own, some browsers (for example Firefox) completely fumbled into disaster. Other browsers (for example Safari) blundered by arbitrarily sending the visitor's request for HTTP directly and irrevocably to HTTPS if they had ever had an HTTPS response -- which exacerbated the problem with constantly landing on the wrong pages.
Then Google, which had a stranglehold on search, began de-emphasizing HTTP vs. HTTPS results. With zero consideration or mechanisms for whether a site actually needed to be HTTPS.
Then this complex system of short-lived (but at least free) certificates that depends on external handshaking and frameworks/code etc. comes into being, making actually having one of these short-lived certs require a fair bit of both more expertise, work, and sometimes maintenance. Not to mention breaking older sites that could not comply.
Then Google, still with its stranglehold intact, stopped reporting actual search results, instead presenting an ML/LLM result cribbed from our websites... reducing our visitors no matter what we've done to try and comply with all this. I've had Google spout ML/LLM results that directly quote my websites minus link or attribution in response to my search queries. Once it did it from one of the stack exchange sites; same thing. Correct (my) answer, verbatim, no attribution or link.
Of course one should always consider the damage done by major corporate players like Facebook, reddit and so on that also turned users into single site gardeners as opposed to web surfers. They have the resources to deal with all this crap, while the smaller and/or less skillful players end up further and further out in the cold.
What is that term Cory Doctorow uses? Oh, yes... enshittification. The web has decayed into crapola.
I use a dedicated preprocessor to elaborate abbreviations.
Hover to reveal elaborations.
(Score: 4, Interesting) by JoeMerchant on Friday April 03, @01:07AM
Just a personal experience note:
Buggy software provided by 3rd parties (we all use it) has done horrible things to our systems (memory leaks fast enough to swallow 16GB and bring the system to instability within 30 seconds or less) upon encountering expired certificates. Yes, we test for that, now. Luckily it happened during development and not after pushing it out to thousands of customers around the globe.
🌻🌻🌻🌻 [google.com]
(Score: 4, Interesting) by Bentonite on Friday April 03, @02:42AM (2 children)
The number of people who still haven't realized SSL is as secure as null encryption and TLS is used instead now.
The certificates are X.509 TLS certificates even (SSL used X.509 certs too, but TLS uses somewhat different fields).
(Score: 3, Interesting) by tekk on Friday April 03, @03:12AM (1 child)
In my opinion the problem is really more that TLS wasn't called SSL 4.0. I assume there was some sort of trademark issue with Netscape at the time, or something like that?
(Score: 5, Informative) by Bentonite on Friday April 03, @04:40AM
"Secure Sockets Layer" is not a good name, as it implies that the layer is already secure without ongoing work required (no version of SSL was well designed and therefore it was never secure).
There wasn't in fact a trademark issue, it was; "so it wouldn't look [like] the IETF was just rubberstamping Netscape's protocol" but regardless, "Transport Layer Security" is a good name, as it makes it clear that the security is ongoing work, which also explains why breaking changes to the protocol are sometimes required to fix identified security issues (too bad middleboxes exist and ossify protocols to the point that TLSv1.3 had to revert to keeping an unencrypted TLSv1.2 version number in the unencrypted protocol headers and move the v1.3 version number to within the encrypted handshake).
(Score: 4, Funny) by sonamchauhan on Friday April 03, @11:22AM (2 children)
BROWSER ALERT "you have clicked a link. Please wait while the server provisions a new certificate to fulfill your request"
(Score: 2) by JoeMerchant on Friday April 03, @02:22PM (1 child)
Modded funny, because there is no "sad but true" option.
Anybody bored enough could have an LLM develop an automated script to do just this. I would guess it would take less than an hour to may the script. A more practical implementation would be to pre-provision a pool of certificates and use a new one for every unique visitor. Let's Encrypt and similar will call this abuse and attempt to stop it, then starts the arms race with automatic captcha fillers etc.
20+ years ago I auto-submitted shareware to about 100 of the various schlocky sites that indexed it at the time. Back then FOS auto captcha fillers were about 60% successful on the first try, over 90% after 3 attempts. Both captcha and auto captcha fillers have evolved since then, but I'm willing to bet the auto fillers are pulling ahead in that arms race.
🌻🌻🌻🌻 [google.com]
(Score: 2) by sonamchauhan on Friday April 10, @05:17AM
Thanks :)
(Score: 1) by BigJ on Friday April 03, @06:51PM (3 children)
So, DNSSEC ensures that DNS queries are authortative (using self generated keys). Why don't we just 1) dump cert authorities, 2) deliver self signed domain certs over DNS. Sure you'll get complaints about needing to store all these certs, but nobody vists even a small fraction of the internet (aside from hyperscalers).
(Score: 1, Insightful) by Anonymous Coward on Saturday April 04, @01:42AM (2 children)
It's all about Money. You don't really need them for ssh - which is basically self signed certs that don't expire.
People regularly click through warnings, get pwned etc and banks, IT etc have to deal with that anyway.
Self signed certs can be way more secure than the CA system or even DNSSEC.
Since I don't need to worry about some CA the browser auto-added, signing some fake cert pretending to be my bank's. I don't know of a browser that by default warns you if the CA or server cert is correctly signed but has changed unexpectedly (e.g. signed by a CA of a different country).
Nor do I have to worry about the DNS stuff getting pwned.
I just have to worry that the site is still using the same self-signed cert as it did years ago, and whether the site is pwned already. Of course if the site was pwned already neither the CA nor DNSSEC system will help.
But browsers don't do "remember this self-signed cert for this server, don't bug me anymore until it changes". Which is safer than CAs, DNSSEC etc for those who know what they are doing. Those who don't know what they are doing are unsafe whatever bullshit system you make them use. 🤣
When you apply to create an online account with the bank the bank can tell you what their self-signed cert fingerprint should be. And if it has been the same one for decades, even grandma might be able to tell you.
(Score: 2) by VLM on Saturday April 04, @04:38PM (1 child)
If this is "at work" the windows kids can set a GPO or the Unix/Ansible adults can toss self signed root CA certs into /usr/local/share/ca-certificates and run the update script. Browsers usually/always/sometimes trust the OS list of valid root certs AFAIK.
At "home" you can kind of do the same.
I suspect making SSL/TLS too hard to use is an intentional attempt at making security weaker on the internet by making it hard to do "good enough". Eventually, my bank is going to give me a self signed root cert and for the paranoid their logo will have some kind of fingerprint in the logo to verify its authenticity.
Or make it impossible to use anything except hyper locked down appliances where you only have to trust the combo of the component chip makers, the mfgr, the government, the company that sold it, and your ISP, in summary all the people who are out to screw you all the time anyway.
If you make it too hard to use, people will not use it, LOL.
(Score: 0) by Anonymous Coward on Sunday April 05, @03:21AM
I don't want the site's cert to be treated like a CA though, that's not secure. I just want the browser to warn me if a site's self-signed cert has changed unexpectedly.
(Score: 2) by VLM on Saturday April 04, @04:28PM
Does anyone there, or here, actually work in IT?
Long time ago set up cert-manager on K8S. Yes its a PITA for initial setup but then its pretty much hands off.
I poked around in the cluster and found a TLS cert issued on April Fools day (about 3 days ago). RenewalTime is May 31st and notAfter is June 30th. OK then I didn't even realize I have three month certs that start trying to rotate two months in.
Its a pretty much hands off system.
What "most IT depts need" is a simple way to watch your entire K8S cluster, look at all the Certificate objects, and spam the hell out of the admins if for some reason there exists a Certificate object with a "renewalTime" more than a day in the past. You got a month to fix it, well, 29 days I guess. Or you can do the "see no evil" hands over the eyes and wait for everything to break in a month LOL. This is the only "operational pressure" I'm aware of, with 3 month cert lifetimes I have 1 month to fix stuff so I'd be pretty annoyed if cert lifetimes dropped to only 72 hours, but, whatever.
From memory, if you use "old school Ingress" objects you annotate the Ingress object with the specific (or only?) intermediate root cert you want to use (if you roll like that) and annotate to set the cert CN to the DNS address of the server (is that even required?), then in the "tls:" section you tell it the DNS name again (why?) and give it a K8S Secret name to store the cert into after it requests it, and you're done, assuming your cert-manager is set up and working it'll request and apply the cert, the Ingress will "just work" in like a minute or two. I honestly don't remember if you have to do anything in the IngressClass to initially set it up initially, this is old stuff. I don't think I ever did anything interesting to the IngressClass. Some "cybersecurity experts" don't want to give a wildcard cert to an automated cluster system so we got an intermediate root cert out of them; whatever. I know for a fact other people use ACME to get letsencrypt certs automatically using cert-manager. It pretty much "does it all" if you want.
If you don't use something like legacy Ingress objects on a Traefik and cert-manager RKE2 K8S cluster the above probably is fairly useless OTHER than as an example that even "not real" IT orgs automated all this crap years ago, such that I had to log in and poke around to discover that apparently cert-manager has been requesting and rotating TLS certs every two to three months and I didn't even notice. Well if it works I'm not going to fix it LOL.
(Score: 2) by VLM on Saturday April 04, @04:45PM
It's the other way around. Big companies to NOT do "proper planning and implementation" just the pre meetings to organize the meetings will take years. Meanwhile at the small companies "well here's a one hour guide to setting up fully automated cert-manger or you can spend a whole day figuring out how to do it by hand" and its done.
Smaller companies are always more agile and have less dead weight in the way.
Now REALLY REALLY small like the doctors office that has a 15 year old unmaintained NAS on the network have different issues, but they're kind of a lost cause anyway.