Sysadmins rage over Apple’s ‘nightmarish’ SSL/TLS cert lifespan cuts plot Apple wants to shorten SSL/TLS security certificates' lifespans, down from 398 days now to just 45 days by 2027, and sysadmins have some very strong feelings about this "nightmarish" plan. As one of the hundreds that took to Reddit to lament the proposal said: "This will suck. My least favorite vendor manages something like …
Not to mention the difficulties of doing automated rotation for public certs, when your service is not HTTP-based, and runs over a cluster of hosts (do they have one cert each? One for the cluster? How to do challenge/response when the cluster is load-balanced and you don't want to give DNS admin rights to the whole network ...)
If you're terminating TLS at the application servers, each one is going to need a copy of the same certificate. Generate on one (or even elsewhere) and rsync to the rest. If you're terminating at the load balancer, perhaps you can reencrypt with longer-lived certificates, but ideally you'd use IPsec and/or MACsec instead.
This post has been deleted by its author
"Max lifespans of certs have been gradually decreasing over the years in an ongoing effort to boost internet security."
It has little to do with security. Either a cert is secure or it isn't. If there's an attack out there that invalidates cert security within 90 days, I don't know about it and it's my frikking job to know that. If there is such a vuln, why are root certs good for 20-30 years and intermediates 2-3 years?
Certs should be valid for up to five years. Authorities can revoke certs with weaknesses through certificate revocation list (CRL) or use the Online Certificate Status Protocol (OCSP) to mark the certificate as revoked. But renewing every five years does not make as much money as one that expires every three months, so you can see the bind they're in.
Moving to one year caused a massive increase in admin given the 300'ish certs we control. Any less and we'll have to hire someone full time just to keep them current. And why? To make cert authorities more cash? Google and Apple can kiss my posterior.
Last time I checked, Let'sEncrypt will discontinue OCSP. (Which of course makes perfect backasswards sense: OCSP staples that I've seen are valid for seven days. Why bother stapling if can force renewal instead? And of course, renewal doesn't fix any issue at all because renewal doesn't need to roll over the private key.)
I've only seen the price of SSL certs going down over the years, even as certificate expirations have gotten shorter.
$4/yr for one site and $39/yr for a wildcard: https://www.ssls.com/
Back in 2009 when certificates were valid for several years, it was $9/yr for one site, and just under $130/yr for a wildcard: https://web.archive.org/web/20091029141332/http://www.cheapssls.com/
Not to mention FREE certificates came along, from Let's Encrypt and other similar projects.
All this will do is force EVERYONE to either use free, automatically issued certificates, or create their own internal CAs and put self-signed certificates (with 10+ year expiration dates) on everything they can't easily automate. And maybe it'll force browser makers to add an option to accept expired certificates, rather than being entirely cut-off from the many websites that'll run into issues.
My organization used to issue its own certs internally (tied to an external public CA), but recently most departments have switched to Let's Encrypt because it's easier to automate. There are always those tricky edge cases, of course, mostly network-connected devices that need certs but don't run a general-purpose OS.
We really need more vendors to get off their duff and start supporting some form of certificate automation.
I've always used ssls.com (namecheap I think?) too, but given the 1yr bollocks I now mostly use letsencrypt, with winacme, and certbot - so ssls.com lost a lot of business from me.
I have private stuff which I used certbot/letsencrypt with cloudflare DNS API rather than http challenge.
At 45 days there is absolutely no way I'll ever buy a cert from a vendor
> All this will do is force EVERYONE to either use free, automatically issued certificates,
Note that there's nothing limiting ACME to free providers. Paid providers can implement it too.
I'm hoping this change pushes more vendors to support ACME. There's no reason certs should have to be manually renewed.
But more to the point, I'd be surprised if it improves security much, being that it's been touted for over a decade the average intrusion is something like 6 months or more before being detected.
from 2022
https://www.cybersecurityintelligence.com/blog/how-long-does-it-take-before-an-attack-is-detected-6602.html
"In fact, the average breach lifecycle takes 287 days, with organisations taking 212 days to initially detect a breach and 75 days to contain it. "
Gives the attacker plenty of time to just get the new certs as they are issued if they are expiring every 45 days..
I assume this expiry time doesn't impact self signed(internal CA) certs, I recall that was the case for the earlier reductions in intervals, and my internal certs I set to expire after about 800 days and have yet to have any browsers complain in the past 5-6 years.
For us, our 3rd party security scanner last time started flagging ANY certificate that did not meet the new certificate validity requirements and worse still ANY certificate that was self-signed. The internal security department then started enforcing these alerts and would not be told that for the specific use case there was no vulnerability (especially with respect to being self-signed, which is entirely valid in certain use cases). Very frustrating and stressful and I fear that the lead will again be taken from this new 'initiative'.
Had this conversation with our 'cyber security' people. My view still remains that if a private CA (i.e. self-signed certs) is being used and the certificates are strictly controlled, it's a damn sight safer than a bunch of certs signed by a public authority, which may or may not be breached or otherwise disavowed.
Most I deal with are 365 days absolute max but one provider will not deal with anyone if certs are over 90 days! So I have to have a special calendar full of reminders in case the cert expiry alerts get missed, else it's "P1 time" first thing in the morning with a bunch of angry devs and biz users. All this just to pay lip-service and security theatre with infosec. Total ballcocks!
This does indeed sound like bollox. It’s just like the requirement to change passwords every 30 days. Why??? Short of someone scanning my brain, why isn’t my old password secure any more?
On another point, which certificates are we talking about anyway? A cert expiry is set when it’s made. What am I missing?
Speaking of advertising, HTTPS has stopped the dickhead ISPs that used to inject ads into your HTTP sessions. That's at least one good side effect.
They still inject ads into DNS misses, but if you're still using your ISP's DNS servers, that's on you.
Edit: I complained to the FCC and some middle manager called me and tried to wear me down over a 3 hour call, saying "everybody does it, it's fine" then reported to the FCC that he'd resolved my concern, which I instantly disagreed with. And there it has sat...
I don't know if they still do, but they used to use an outfit called "Barefruit":
https://www.barefruit.com/
https://uk.linkedin.com/company/barefruit
The reason I don't know is that it has been years since I've used my ISP's DNS.
They obviously think of ISPs' customers as "bare fruiit" waiting to be picked and sold.
Comcrap is hijacking port 53.
Found that out one day when I was trying to figure out why Mailinator was marked as a malware site, and I couldn't figure out how to bypass that. Turned out to be at the DNS level... But I run my own servers, so I whitelisted it, and it still didn't work. But when I remoted out to a site that wasn't on Comcrap, it didn't error at all. A bit more poking and everything I didn't have DNS records for was hitting the Comcrap servers even though I was trying to hit others.
Ended up having to play stupid games with DNS over HTTPS to avoid the Comcrap servers.
Your website is a prime target for interception and man-in-the-middle attacks.
Sure, to you it's just an HTML site. To any ISP or intermediary, it's an opportunity to insert literally anything they like into your page (including, ironically, advertising as some ISPs have been caught doing) because there is no way to check or guarantee if the HTML etc. has been modified en-route.
People went HTTPS everywhere for a reason - because ISPs and governments were inserting rogue Javascript code, trackers, cookies, adverts and even changing content on HTTP sites that people visited without the site-owners being aware.
Ironically, your "no cookies, no tracking, no advertising" stance is precisely why HTTPS is enforced nowadays.
Have a cautious upvote. My static site also has no login, no cookies, and no tracking (Possibly because I'm old). It doesn't use JavaScript, python, etc., either. I did force myself to use one CSS style file. If a user does try to use an http URL, it is converted to https.
Let's shorten the lifespan of certs to 48 hours, so stolen certs will basically expire immediately.
Or why not 12 hours? 2 certs a day should be worth it to stay secure, right?
Then, why not 5 minutes? Would be much more "secure" than 12 hours.
/s in case this wasn't obvious.
Somewhere along the lines I lost the plot on why shorter lifespans are regarded as more secure.
Sure, shortening 8 years to 3 seemed to make sense. 3 years to 1 year? Already questionalble.
But shorter? What's the actual meaning?
If a cert holder cannot be trusted to not spill their production certs for one single year, why trust them at all, you know, with all the rest of our business?
Why so much as 5 minutes, why not every connection. And a public key in a DNS record. I guess it couldn't be because the charlatan CA's (i.e. functionally all of them, in case it needed clarification) couldn't middle man rent money in this approach. It is a detriment to everyone, that it just happens this mess was the mechanism available when (Snowden) suddenly it became fashionable to have a lock in an address bar (but not effect any actual security, on any non-updated CMS on the website, of course).
I'll admit I don't require attention to the whole set of problems SSL was purported to solve. But to paraphrase, at least I'm not paid to not understand a decentralised solution could facilitate encryption between two endpoints.
This unread post continues after I click through the self signed cert warnings with, fire and damnation, for any non-public facing service.
At least these days even the non-LE ones are automatic in the sense I log tickets for someone else to swap. just in time.
In the orwellian world, Everyone will have a hardware security module that signs all of their internet traffic with provable security. Every action and every payment will be recorded forever using elliptic curve cryptography. Clipper wins.
Short-ish lifespan is good because...
Imagine I own a domain and get an SSL certificate for it.
I then sell that domain. The new owner builds a successful business on it.
I could then impersonate that new business with a perfectly valid certificate, simply because it hasn't expired yet.
For this to play out in the real world would take a lot more than 45 or 90 days, but could conceivably happen in a year.
No, the point is there currently is no retroactive proof of control: even if I now own the business.example domain, I cannot revoke the certificate you legitimately got a week ago when you still owned it. (But you still would need to hack the DNS to do anything useful like redirecting traffic that wants to visit me to visit you instead.)
No. The new owner could have a new certificate, but until my old one expires, it would work just as well if I could get some traffic sent my way. As far as the certificate authorities were concerned, the domain is mine until that certificate expires. That someone else owns and operates it now is not part of the certificate system, and they don't coordinate to cancel mine if someone else sets up a server. Maybe they would if they use the same authority that I used, although even then they might not bother, but if we used different ones, then there will just be two certs covering the same domain.
Just been through the relatively simple task of changing the registered owner of a set of domains for a client, from their defunct partner to them. Glad certificates weren’t linked, as then would have to issue new certificates, just because I was doing some housekeeping…
It's not that hard. Although certificate revocation isn't always used, I'd ask the former owners of something I bought to revoke that certificate, indicating either the "affiliation changed" or "cessation of operation" reason codes, then verify them myself. Then I'd consider the domains switched over. True, that would not stop someone who didn't check those lists from getting untrustworthy data, but it's better than assuming and not checking that they did something with their old certs.
This post has been deleted by its author
> Somewhere along the lines I lost the plot on why shorter lifespans are regarded as more secure.
The problem they are trying to solve is certificate revocation. It sucks. It's unreliable since it largely relies on certificate revocation lists, which require larger and larger downloads over time, are cached, and can silently fail to update. The only real alternative to CRLs that got any traction at all was OCSP, which is gradually being phased out because it's both unreliable, and an invasion of privacy, Since since all the current solutions for revocation suck, the browser vendors and most certificate authorities want to replace certificate revocation with certificate expiration, so eventually, they don't have to deal with revocation at all. In the meantime, the shorter periods help keep the CRL lists shorter, since entries can fall off as certificates expire.
Reducing validity down to 90 days or 45 days, or the even shorter periods we'll eventually see, are part of a scheme to cause increasing amounts of pain to gradually force sysadmins to automate, and to pressure vendors into supporting that automation, without being completely debilitating to those that can't yet automate. This in turn eventually gets us down to the magic 7 days or less, at which point CAs and browsers no longer have to implement certificate revocation at all, per the policy adopted in CA/Browser Forum Ballot SC-063.
> The problem they are trying to solve is certificate revocation.
Yes, they solve one of their problems by creating a host of problems for a lot of admins in all other organizations.
Applying full automation to cert changes is a) not possible in every HW/SW/compliance level environment and b) creates its own set of risks and attack vectors.
The CA-based "web of trust" is already broken to a certain extent. As multiple events of fraudulently issued certs showed, a valid CA-issued cert is no guearantee that you are really talking to the partner you think you are talking to. It never really was.
Every single of the hundreds of root CAs is a single point of failure in this web.
Throwing in full automation as a means of a "fix" will multiply the existing problems, not solve them.
This post has been deleted by its author
Once the pain is over it won't matter.
Letsencrypt is 'frequent' to push people to use automated tools, their argument is once it's automated then the time frame isn't really that important, to quote:
The problem here is it's a chicken an egg situation. Manufacturers have no incentive to make certificate changing easy as current lifetimes are generally long. They'd be expending engineering effort to streamline an infrequent process. They don't view the expense as worth the benefit. This means it's always going to be a pain to move to shorter lifetimes. LetsEncrypt have proved the viability of automated renewal and swept up the low hanging fruit, but it needs the push of the big companies to force device makers to have to deal with this. If people stop buying their hardware as it makes IT staff take up pitchforks they'll soon change it.
I do feel sorry for the sysadmins over the next few years though, as they'll have to bear the pain.
Where is the evidence that these shorter cert lifetimes are more secure? We have seen that opening up DNS servers for ACME has resulted in abuse. We have seen many poor implementations of automatically refreshing certs adding security holes. Yet I have yet to see a single case where a shorter lifetime on a cert would have stopped a problem.
Along those lines I don't recall ever seeing news reports of ssl cert hijacking. I have seen reports of CAs improperly issuing certs but of course that is an unrelated issue.
I don't doubt ssl cert hijacking as an issue exists, but it doesn't seem to be prevalent to the point where reducing time to expire as being a useful tool.
Most surprised that Apple of all companies seems to be behind it, as they were behind the last round of reductions.
And I guess everyone gave up on revocation, nice idea in theory but guess almost never gets used.
Also curious if anyone had had experience with ssl cert expiration issues with non web systems. Take email for example, haven't heard of any email clients enforcing such limits on certs, also take server side apps talking to other apps over https. I'm guessing the ssl libraries don't care either, as I've never heard of someone complain about such things.
I'd bd happy to go back to 3 years myself. I've only been on the Internet since 1994, and running Internet facing servers since 1996, so what do I know, apparently nothing. Sigh
This post has been deleted by its author
Also curious if anyone had had experience with ssl cert expiration issues with non web systems.
Happens fairly often in consumer electronics.
A friend has an old LG TV, it has a Plex client, which stopped working years ago, due to the TV lacking up to date CA certs.
They got a new TV, passing the old one off to a family member.
The recipient was really happy with their new TV as it had this Plex app on that gave them access to all this media. (My friend hadn't bothered to sign it out).
A few days later when the TV set it's clock it all stopped working again.
I suspect a lot of stuff becoming 'Unsupported' is due to old CA root stores expiring.
This post has been deleted by its author
What about the Trusted Root CA certificates that are valid for 25 to 30 years? Is this not a problem? There are more than a few that I don't recognize. Perhaps it's time we take a closer look at the Trusted Root CA's also. Since Apple / Google / MS can update CA's using security patches. Maybe change is needed at both sides of the trust chain and CA cert lifetime should be reduced as well. Is 10 years enough for a CA cert? If the trusted root CA's can be easily updated, they don't have much excuse for the 30-year lifetimes. Major pains for CA's every decade at most should be acceptable if I need to make sure my certs are still working every 45 days. I'm not sure if reducing the lifetime is going to help fix the problem if those certificates shouldn't have been issued to begin with.
Very very few mega enterprises (y'know; your banks, credit card processors) have it that automated because they have a dozen different technologies between you and their server (WAFs, load balancers, k8s, whatever).
In an old school enterprise changing a cert may require 3 different teams (WAF team, load balancer team. server team). And this isn't automatable because the server stuff was designed 20+ years ago and is a unique snow flake. (Hell, it might even be on a VMS system, definitely could be mainframe). And the underlying network is a hodge-podge of mergers and NAT that you literally _can't_ get there from here.
Backend processing (eg card transactions) can still survive because "fuck apple"... until they demand this for ApplePay.
45 days won't break the internet, but it _will_ break services we depend on, daily.
"Boy am i glad i.get my first retirement benefits this month. The industry has lost whatever feeble little mind it used to have."
Got my first last week. Alas more beer than champagne but never again having to deal with this shit is worth giving up the grape for the hop.
Have to wonder what the BoFH makes of this nonsense? He couldn't eject the entirety of Apple manglement from his conveniently open window ..... could he?
I also wonder whether one could write a javascript app (served from a conforming site) that would run within Safari, Chrome etc and talk https with non-conforming sites with long life certs and render those pages in Safari's DOM - a browser within a browser?
From memory I suspect automating the frequent replacement of certificates in Dell iDRACs would be a seriously non-trivial exercise. As I think the certs are stored in non-volatile memory (flash?) 45 day rotations would mean that memory would be molested every 30-40 days (9-12 times per year) which might be pushing it for some memory technologies.
Bad enough installing ancient versions (32bit) of Firefox just to talk to web servers embedded in equally old hardware and also need ancient versions of Java for Java web start. Ghastly. It all is. Absolutely Ghastly.
How about restricting the lifetime of cookies too?
Oh no, Apple and Google wouldn't like that, because they would be able to collect so much info about us plebs.
Chucking out all but selected cookies after a day would be a simple solution. DOes anyone know of a browser plug-in that does this?
Call me when iCloud is GDPR-compliant. As in it has a GDPR compliance statement that isn't just "wishful thinking" and no details.
You can't, because iCloud is just Amazon AWS, Google Cloud and Azure instances lumped randomly between regions without any of their regional / processing guarantees passed on.
Google, Microsoft, Amazon gave me cast-iron GDPR assurances months before it became law.
Apple still don't. They make it *sound* like they're compliant but they will never certify such and give a simple statement to that effect.
Not to mention the extra costs of the certs themselves.
SAN cert seems to run about $300 a time, now that's money for old rope, so with renewal every 45 days you'd be up to $2400 a year in theory.
I notice however that Digicert seems to have gone over to a subscription service with 'unlimited issuance / replacement' on one of their options.
I guess they've been reading the tea leaves.
My run teams have to be dragged kicking and screaming at the moment to renew certs and that's only once a year for a small number of servers.
They'd probably start making noises about a 'certificate manager' role if it gets to be as often as this.
Does anyone seriously think that a certificate requiring renewal every 30 days is going to cost less over a 12 month period that the current annual renewal - not a chance in hell. It's a guaranteed certainty that the total annual cost per cert will increase, probably significantly as a direct result of this. That doesn't even begin to address the real cost in terms of administration effort/time required to handle this for all but the most basic of use cases.
For what - at best a (very) marginal increase in security that quite honestly 99% of certificate users don't require and will not benefit from. Those who think it's worthwhile are welcome to rotate their certs ever 30/90 days if they want to, nobody is stopping them.
This is nothing but a cash-grab by interested parties dressed up as a security enhancement. Not wanted, not needed and not welcome.
One of my customers uses sone third party software that is exposed to the outside world based on Tomcat. As a point I avoid anything to do with this software as its a bloated mess that the vendors "engineers" know nothing about, less about systems asnin and only have procedures to follow and cant/wont deviate from script.
Every year there is a week of faffing about trying to get the cert updated, complaints of wrong format, not having private key, moon is on the wrong phase, etc etc. The customer doesnt want me involved with this "specialist" software because the suppliers "engineers" know best. So every single year we do this dance where they have to physically send an engineer out to do it. Im not alone in this as the scumbag multinational company responsible actively preys on customers like mine that need the software for their printing presses.
By going to 45 days I figure the front end will be secure for a few days a year at most.
We already use a separate temporary key for each TLS session, negotiated using DSA or ECDSA. So a stolen key doesn't break the security of past connections, only future ones.
We already have OCSP, which would allow the certificate for a stolen key to be revoked. Although it's not possible to actually use, because it is slow and unreliable, and also a privacy problem. Your browser has to ask the CA if the certificate is still valid every time you visit a site, with the response being kept for a couple of days before your browser has to check again.
We already have OCSP Stapling, which no-one uses, but would fix most of the problems with OCSP, at the cost of requiring every old HTTPS server to be updated to support it. The web server gets the OCSP response from the CA and sends it to the web browser. That fixes the privacy problem, and mostly fixes the performance and reliability problems. The response from the HTTPS server is a bit bigger, so slower. And if the OCSP server ever goes down for more than 2 days that would cause an outage.
Shorter certificate lifetimes can be sold as compatible with existing HTTPS servers. But it actually requires extra automation, so it isn't really. It also adds another reliability issue: If the CA stops issuing certificates then websites will go down. At the moment, people renew certs well before they expire, so have plenty of time to fix any issues. With the proposed changes, they would have much less time.
Also, automated systems that can renew certificates, open up the risk of attacks on those systems to get certificates for the attacker.
If we're going to break most existing HTTPS servers, then I'd rather have OCSP Stapling.
Nope, the choice of browser is entirely in the hands of the user. Who couldn't care less and therefore uses whatever browser comes with the device, which will be Chrome, Edge (aka Chrome), or Safari.
Making your website unavailable to +90% of your customers because of sysadmin complaints is unacceptable to your business.
"sysadmin complaints"
Is it complaints or a matter of feasibility?
Personally I'm pissed off by the multiplicity of sites that want to tell me that I can't use my preferred browsers, mostly, I suspect, because it's the authors of frameworks such as PHP that can't be arsed to remember that the web was supposed to be a universal platform. Clearly the businesses that run such sites don't care provided the user switches to some other browser. If Apple and Google, as browser vendors, get the rough end of this they'll get no sympathy from me.
If the browser your users are using rejects the SSL certificate, then your users can't get to the site to see your "use a different browser" message. They just see a browser provided error page. (Maybe the browser allows the user to click through to the site, but maybe not. And there will be scary warnings from the browser).
Also, all CAs have to follow CAB Forum rules or face expulsion from every major browser. So if CAB Forum approves this, then your CA will just stop offering long lived certificates from their existing Root Certificates.
Theoretically a CA could create a new root, not trusted by the major browsers, and just the alternative browsers could support it. That wouldn't have to follow the CAB Forum rules. But that doesn't sound like a good business plan to me.
Apple is the reason validity was reduced down to 1 year, and why everyone had to bend to Apple's decision lest their users with apple devices couldnt browse their websites anymore. Nothing like the thought of lost revenue to make commerce suck it up and just accept it. Principles are fine in principle, but in reality nobody could take the risk of losing income from their fruity customers
Out of interest I looked-up the CA/B Forum to see if they had any rules that obliged them to consider the impact on certificate users of any changes they might introduce.
Short answer: no. But they do have a nice set of byelaws. There's a whole section on how to respect the wishes of members who don't want to be photographed at meetings but nothing obliging them to respect - or even consider - the wishes of those affected by their policies.
They don't need it in their bylaws, because it's the law.
Just like they don't need "don't murder people" in their bylaws.
Anti-trust laws mean that industry organisations where companies conspire to harm their customers are illegal. However, industry standards are good for consumers. So meeting solely to create a standard that is a benefit to consumers, is allowed under the law.
You want a choice of browsers and CAs.
Server operators are consumers of certificates. They want a choice of competing CAs to buy from. To be a good CA you have to be accepted by most browsers.
So it's good to have a standard for "what a CA needs to do to be accepted into a browser". And it's good that all the browsers agreed to have mostly the same standard (though there are some browser specific bits on top). This is good for competition in CAs
End-users want a choice of browsers. To be a good browser, it has to support the CAs that are used. So a standard that makes it easier for a CA to be in every browser is good for competition in browsers.
So the CAB forum is legally obliged to ensure it's standard provides a benefit to server operators and end users.
However, let's remember that the point of certificates is security. So the rules have to ensure that TLS is actually secure. This is good for both ends users and server operators. It is a clear benefit.
There will always be a tradeoff between security and other factors. And for an Internet wide standard like CAB Forum, it's really hard to come up with a solution that is perfect for everyone. There are compromises.
Is this proposal the right balance? I don't think so. But I mostly respect the people who are mostly trying their best to make the Internet secure.
As Martin Fowler noted "if it hurts, do it more often". Get your firm to get the automation that you need in place.
Early in engagements, I commonly try to get reports on the ages of keys and certs. The ages of some of them can be enough to drive some desire to get this on the risk register. The biggest threat is internal (or ex internal) staff.
This is a root Certificate Authority (CA) proposal, which will be followed through and, effectively, enforced by web browsers, and the majority of browsers are controlled by Google, Apple, Microsoft (sort of, they use Google Chrome) and Mozilla (now a distant last place in browser share). This means that Certificate Authorities will have to enforce that they only issue (sell) certificates with a shorter life requiring more certificates for a given period of time and the expense in deploying these, and web browser controllers will enforce this by rejecting access to sites that do not comply with this new proposal.
Therefore it is not just an Apple centric outcome, it is just that Apple is the key backer behind this proposal.
This sort of reminds me of the trend in retail of check my ID when I buy beer. I'm nearly 50. I'm not sure what purpose this actually serves. You can check my id all you want, but it doesn't stop me from handing off the beer to the teenager waiting outside one bit. (I don't do this... but it all comes down to trust eventually doesn't it?).
TLS is broken, cert longevity has nearly nothing to do with that. It's broken because the CAs don't really do their job either because they are run by MBAs or because they exist to be shady... and due to politics browsers end up trusting a lot of CAs that I don't really want to trust ever. Furthermore, unless you actually use DNSSEC fully the domain I'm connecting too isn't necessarily mapped to an authoritative IP address...which can have a perfectly valid cert from letsencrypt.
This requires either lots of extra after hours work or automation that is a new attack vector (which we then have to monitor). 1 year seemed reasonable as it was often enough we didn't forget the process or service but something we only had to worry about annually. If certs aren't solving the problem they were made to solve why are people purposing making them worse to manage ensuring more screw ups?
45 days might be too short for social reasons. The faster certs expire, the more likely it is for expiration after a system failure. If your certificate lasts for 398 days, you can renew every 350 days with a big comfort zone of 48 days for any problems that may arise. At 45 days you're balancing the costs of too frequent renewal versus the risk of expiration when there's a fault. Maybe you pick 35 days. That's not a very efficient use of the 45 days but it gives you 10 days for fault tolerance. So there is a fault on day 35 of 45. You contact support, you get a new renewal API spec, you update your system, test, and... 18 hours are left. It's time to call in on the customer support contract. Manual renewals will be more frequent, more urgent, and more of a load for customer support. CS doesn't have the time to perform in-depth authentication. They'll just do whatever is asked. Maybe it's a hacker asking.
I know this happens because Morgan Stanley uses a shit 2FA system. It's so common to need to reset, and the timing is so urgent, it that their customer support will do it immediately with few questions asked.
The trouble with the people trying to make these policies is that they live in a world where everything is connected to the internet.
I work in a world where the opposite is true, and policies like this cause massive headaches.
We still have client devices using modern browsers which adopt such policies but then there's legacy infrastructure which in many cases is not possible (or at least not practical) to automate, which typically involves the use of tightly controlled end user devices - even for admins plus jump hosts and all sorts of complexity to gain access and/or transfer files (e.g. updated certs) to the relevant systems.
I deal with a number of certs which are currently replaced annually, and always cause a ball ache so doing it now frequently will only worsen the pain.
It's bad enough dealing with a few external cloud-hosted services which have differing and highly finnicky ideas about TLS such as a private server to server link where the service took away the facility to add custom trust and requires certs from a public CA even though this is unnecessary and arguably less secure; through to another major cloud platform which makes custom trust extremely hard to add but then handles CA chain in a very unique way which requires bodging the server end to present in a way it can cope with.
I don't need any more of these headaches thanks.
And I deal with systems that must operate when the entire system is isolated for months on end - NOTHING has internet access.
Not to mention, ANY update/upgrade goes through a process that takes "more than 45 days", meaning that even when the system can be updated - the updated certs will already have expired. Yes, we are thinking hard about how certs (among a long list of other stuff) are managed long term.
I was wondering what the effect this will have on offline PCs and VMs: Does this mean I will have to fire up VMs every month, just they can have their certificates updated etc.
Plus, I can see MS using this as just another excuse to force update, ie. Due to say EoL W10 not receiving updates, it effectively becomes unable to do anything 45 days after the last update…
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
