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 …

[Cheshire Cat]

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 ...)

[sedregj]

You can use a CNAME and another DNS domain, just for ACME.

You don't have to give admin rights. Implement RFC 2136

[Anonymous Coward]

The nodes of my database clusters talk to each other using TLS. That obviously can't use a CNAME.

[talk_is_cheap]

> The nodes of my database clusters talk to each other using TLS. That obviously can't use a CNAME.

Why would your database cluster endpoints care what TTL browsers use for certs?

[Anonymous Coward]

Because for better or for worse, the rules for certificate creation tend to coalesce around what browsers support, because they're the most visible users of TLS.

[anothercynic]

Your clusters should not be talking to each other with certificates issued by a public CA if the traffic is internal. Use an internal CA (Windows has a certificate authority module for that, and Linux you can easily craft one for).

[Roland6]

In principle that should work, but it seems too much stuff these days treats private certificates as insecure and so throw up problems.

Outlook for example just won’t accept and retain one of our mail servers certificate, so every 30 minutes it declares the connection insecure..

[DanAU]

You don't have to use a CNAME for the actual service itself, just for its _acme-challenge subdomain. You could use a DNS server like acme-dns that's designed to only respond to ACME TXT validation requests.

[Brad Ackerman]

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.

[Anonymous Coward]

Follow the money

I am sure the additional revenue generation of having folks renew every 90 days has nothing to do with it.

[Anonymous Coward]

Re: Follow the money

"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.

[brotherelf]

Re: Follow the money

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.)

[Mike Pellatt]

Re: Follow the money

OCSP is being deprecated, thanks to well-documented privacy issues.

CRL lists are hard to trust and potentially a major performance hit.

Reducing cert lifespan is, probably, the only mitigation possible for what is, at its core, a broken infrastructure.

[Anonymous Coward]

Re: Follow the money

OCSP privacy problems are fixed with stapling.

The problem is with the most popular browser, Chrome, not bothering to check CRLs or OCSP at all, for performance reasons.

[Roland6]

Re: Follow the money

So can we expect certificates to be depreciated when the to be expected privacy and security issues are found in the certificate issuing service…

[RAMChYLD]

Re: Follow the money

> To make cert authorities more cash?

To upsell cert renewal automation software. So not really much to the benefit of CAs but cert automation systems.

Which is puzzling given that Certbot is a thing. Oh wait, Certbot doesn't work on Windows anymore...

[Mike Pellatt]

Re: Follow the money

If you're paying money for each certificate regeneration, you're using the wrong certificate supplier.

[Richard 12]

Re: Follow the money

One of the sponsors sells certificate automation.

There's lots of ways to make money off shorter expiry.

[Mike Pellatt]

Re: Follow the money

Whilst describing a task as a "Simple Matter Of Programming" is generally, correctly, taken to be ironic, in the case of certificate generation and installation it is.

Generally.

I'll make an exception for the Java certificate store.

[Roland6]

Re: Follow the money

Yet another single purchase being changed to subscription…

[rcxb]

Re: Follow the money

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.

[Orv]

Re: Follow the money

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.

[carl0s]

Re: Follow the money

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

[Roland6]

Re: Follow the money

> I've only seen the price of SSL certs going down over the years, even as certificate expirations have gotten shorter.

Ripe then for subscription services, which would indicate the optimum life of a certificate will be 31 days….

[DanAU]

Re: Follow the money

> 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.

[DanAU]

Re: Follow the money

Apple is proposing this change, and they're not in the business of selling TLS certs.

[Nate Amsden]

sounds terrible

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.

[DS999]

Re: sounds terrible

Depends on how large/impactful the breach is. If they can get at your private keys that's a lot more serious than the typical breach.

[Anonymous Coward]

Re: sounds terrible

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'.

[anothercynic]

Re: sounds terrible

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.

[Roland6]

Re: sounds terrible

Stop using logic and reason to argue against the security FUD: if it’s done in-house it has to be less secure than a third-party. Next thing people will decide running their own datacentres is more secure than cloud…

[ecofeco]

Wait. What?

Max lifespans of certs have been gradually decreasing over the years in an ongoing effort to boost internet security.

So, it's useless.

More work, offloaded to the end users, for less effectiveness?

Enshitification intensifies.

[Yet Another Anonymous coward]

Re: Wait. What?

>So, it's useless.

So far, but once the lifespan is negative we predict an inflection point in security

[ecofeco]

Re: Wait. What?

LOL! Well played!

[Anonymous Coward]

Re: Wait. What?

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!

[Anonymous Coward]

Re: Wait. What?

Do you not have them monitored?

[Rich 2]

Re: Wait. What?

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?

[ovation1357]

Re: Wait. What?

You can set any date you like on a cert for expiry but there is also a valid from date and the client system can choose to reject it based on any arbitrary length of time :-(

[david 12]

The solution...

The solution is to use a non-advertising-supported browser that doesn't enforce use of HTTPS.

Of course, I don't have any control of what my clients use, so my static http website (no login, no cookies, no tracking) is being forced over to HTTPS between now and Christmas.

[Gene Cash]

Re: The solution...

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...

[ITMA]

Re: The solution...

"They still inject ads into DNS misses, but if you're still using your ISP's DNS servers, that's on you"

Absolutely! And YES we're talking about YOU TalkTalk....

[ITMA]

Re: The solution...

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.

[VicMortimer]

Re: The solution...

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.

[Lee D]

Re: The solution...

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.

[Nintendo1889]

Re: The solution...

http only sites had no issue with heart bleed.

[Orv]

Re: The solution...

That's true, but only because no one needs to exploit a vulnerability to impersonate an HTTP site.

[InsaneGeek]

Re: The solution...

I'm with you on one hand but I've also got to admit a compromised host I've lost control over that anyone can modify is significantly worse than someone impersonating a non-commerce website like a blog, etc. bank, amazon, facebook, etc sure but those already needed SSL

[Tim99]

Re: The solution...

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.

[Anonymous Coward]

Re: The solution...

If only HTTPS were the only use case of TLS :D

[EricM]

OK, then let's focus on really strict security

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?

[tip pc]

Re: OK, then let's focus on really strict security

Then, why not 5 minutes? Would be much more "secure" than 12 hours.

how about a new cert per connection?

looks like an excuse for the TLA's to ensure compromised certs are refreshed often, thereby crowding out their competitors.

[exovert]

Re: OK, then let's focus on really strict security

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.

[Nintendo1889]

Re: OK, then let's focus on really strict security

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.

[Anonymous Coward]

Re: OK, then let's focus on really strict security

The problem becomes that as the expiry horizon shortens the need to automate the replacement increases and that mass automation will provide an avenue for an attack itself - especially for 5-eyes agencies.

[Strahd Ivarius]

Re: OK, then let's focus on really strict security

You forgot to note that it is Apple asking for this, the promoter of Safari browser...

[Anonymous Coward]

Re: OK, then let's focus on really strict security

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.

[John Brown (no body)]

Re: OK, then let's focus on really strict security

Isn't that the fault of the new owner for not replacing the cert with a new one of their own? That's like buying a bricks and mortar business and not changing the locks and assuming that all keyholders have returned their keys.

[brotherelf]

Re: OK, then let's focus on really strict security

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.)

[doublelayer]

Re: OK, then let's focus on really strict security

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.

[Roland6]

Re: OK, then let's focus on really strict security

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…

[doublelayer]

Re: OK, then let's focus on really strict security

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.

[Nintendo1889]

Re: OK, then let's focus on really strict security

I say the same thing about password breaches. What's the point of resetting a password if the site has been proven to be insecure and run by inept administrators, other than to regain access.

[find users who cut cat tail]

Re: OK, then let's focus on really strict security

Please shorten it to 45 µs. Make it *literally impossible* to implement the policy.

Then finally everyone stops chasing nonsense and we'll figure out a better way of doing this.

[sdaugherty]

Re: OK, then let's focus on really strict security

> 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.

[EricM]

Re: OK, then let's focus on really strict security

> 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.

[cjcox]

Real reason

It's not that you are sloppy with regards to your private keys, it's that the signers are all incredibly stupid. Simply put, criminals wanting more money.

[Michael Hoffmann]

Couldn't they at least have settled for LetsEncrypt's 90 days? I mean, people use them in droves and live with the restriction.

[Brad Ackerman]

I'm wondering about GRC. A lot of large organizations' systems flag certificates that expire in less than 90 days, which would make those findings less than useless with those.

[FIA]

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:

"Once automated renewal tools are widely deployed and working well, we may consider even shorter lifetimes."

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.

[Sudosu]

I thought I had read that letsencrypt was in danger of being removed as a trusted cert issuer.

Maybe I am mixing them up with someone else though.

[-tim]

Evidence?

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.

[Nate Amsden]

Re: Evidence?

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

[FIA]

Re: Evidence?

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.

[jake]

I believe the expression we are all looking for is ...

... fuck off, Apple. Just fuck off, you useless fucking fucks.

[Evilgoat76]

Re: I believe the expression we are all looking for is ...

Does that feel better? ;)

[seven of five]

Re: I believe the expression we are all looking for is ...

Some things just have to be said, feelings nonewithstanding.

[Leedos]

What about CA certs?

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.

[Anonymous Coward]

Re: What about CA certs?

What about the shear number of "trusted" root CAs?

It's a joke.

[sweh]

Automation don't work this way

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.

[Doctor Syntax]

Re: Automation don't work this way

"45 days won't break the internet, but it _will_ break services we depend on, daily"

Alternatively it might break Safari as a browser for internet banking and all those other services.

[VicMortimer]

Re: Automation don't work this way

Scroogle is apparently pushing for it too.

[Groo The Wanderer]

Boy am i glad i.get my first retirement benefits this month. The industry has lost whatever feeble little mind it used to have.

[Bebu]

Good-bye to all that

"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.

[andy the pessimist]

Re: Good-bye to all that

If it is using flash....Flash has a typical life of 100,000 write cycles.

It's going to damage the flash devices quickly.

[Spamfast]

Re: Good-bye to all that

If it is using flash....Flash has a typical life of 100,000 write cycles.

Flash? It was still running on set top boxes a while back but it's definitely well past its life cycle now.

(I'll get my coat ...)

[ecofeco]

Lucky bastard.

Have one on me!---------------------------------->>>

[Roland6]

If/when this comes into effect, don’t be surprised if subsequent cheques get delayed, as the system hiccup more frequently due to certificate errors…

[Dr Paul Taylor]

Cookies too?

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?

[Lee D]

Re: Cookies too?

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.

[Zippy´s Sausage Factory]

Re: Cookies too?

At first I read that as "Apple may sound like they're competent". Honestly, I feel it's interchangeable.

[Alan J. Wylie]

Re: Cookies too?

Cookie-AutoDelete may be what you are looking for

[DrXym]

Okay

So how many sites have been compromised because their certificate was getting old?

[John Brown (no body)]

Re: Okay

None AFAIK, but they do start to look a bit tatty around the edges, getting creased and torn, covered in grubby fingerprints etc. Not a good look for a Fortune 500. Something must be done!

[gryphon]

Certificate Costs

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.

[ChipsforBreakfast]

Follow the money

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.

[Evilgoat76]

Dear lord no

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.

[Spamfast]

Re: Dear lord no

based on Tomcat

A chill runs down my spine.

I avoid anything to do with

Wise decision. I have a list. Amost all of the server-side stuff on there has Java in it. JBoss is another hideous example.

[Jon 37]

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.

[Tubz]

They will just have to agree a balance, 90 days isn't too much to ask surely for improved security?

[VicMortimer]

Yes. Yes it is.

1 year is too much to ask. I want 5 year certs back.

[Doctor Syntax]

""may not pass the CABF ballot, but then Google or Apple will just make it policy anyway…"

So if that happens how about the web sites telling Safari and Chrome users to try a different browser? That's a power that's in the sysadmins' hands if they choose to use it.

[storner]

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.

[Doctor Syntax]

"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.

[Jon 37]

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.

[Orv]

In the case of iPhones and iPads that would be "try a different device," because all iOS browsers are just reskins of Safari.

[Nintendo1889]

Easy fix, don't update macos and don't buy new Apple hw.

[john wayne]

Except apple have previous for this

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

[Steve Davies 3]

What happens if...?

the proposal is adopted and everyone else does the same.

Are you going to stop using computers entirely?

Please let us know how you are going to proceed.

Remember, this is a proposal at the moment.

[Orv]

Re: What happens if...?

Honestly that cabin in the mountains looks better every year.

(I'll get my coat 'cause it gets chilly there at night.)

[Trigun]

I've often wondered if this is as much about a greedy industry (certs cost, after all) as security? I.e. two birds with one stone?

[Vulture@C64]

Pointless. Won't make any difference except we'll waste more time updating certs and that's where they are stolen, admins getting sloppy because the task is so brain numbing.

[Anonymous Coward]

... a vote among Certification Authority Browser Forum (CA/B Forum) members

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.

[Jon 37]

Re: ... a vote among Certification Authority Browser Forum (CA/B Forum) members

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.

[MTimC]

(lack of) credential rolling is, imho, a big risk

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.

[sabroni]

The more often you do something

the easier it becomes.

That's why we run the build pipeline every time we commit now instead of scheduling them to run overnight.

I know it's not how your dad used to do it. His version control system was a drawer full of floppy disks.

[Roland6]

Re: The more often you do something

Depends…

The change from build when you have a complete set of modules ready, to build every commit required some not insignificant changes. Obviously, as build every commit is normal, people overlook the additional efforts needed to make it happen.

[Tron]

Websites not working on Safari?

No problem. I'm sure fans of Apple will be happy to keep buying their kit for its ornamental value.

[Rich 2]

Can someone explain please!!??

I don’t understand the story

A cert lifespan is set when it’s created. So unless you get apple to make your certs, what’s the issue?

Which SSL certs are we talking about?

[Irongut]

Re: Can someone explain please!!??

Go back to Ars Technica, that's more your lack of technical level.

[Nick Ryan]

Re: Can someone explain please!!??

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.

[Joe Dietz]

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.

[Grogan]

Companies like Apple, Google and Microsoft generally LOVE things like this, because it's a barrier to entry. Only the big boys should be able to play.

[Auror]

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?

[Kevin McMurtrie]

More social hacking

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.

[Anonymous Coward]

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.

[Anonymous Coward]

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.

[Dwarf]

What about the rest

What about the rest of the certificates used for things like signing software, or others that are used inside the OS. Presumably this will make older hardware more difficult to keep going for a longer period.

[Roland6]

Re: What about the rest

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…