System admins irate at Apple's plan for shorter cert lifespans

Posted:
in General Discussion

Apple has proposed for a shortening of validity for security certificates used by websites from 398 days down to just 45 days, a move that system administrators have objected to publicly.

Web browser displaying appleinsider dot com URL and page title, featuring a light to dark gradient background.
SSL/TLS helps keep website secure for users



Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates are used to make sure that a website user's connection to a website is secure in a browser like Safari. As a form of identification for the site, it aids in a cryptographic system that protects the user's data when communicating with the site.

As it stands in October 2024, certificates have a lengthy lifespan of about 13 months. However, in a draft ballot provided by Apple to the Certification Authority Browser Forum (CA/B), it wants to shrink down the amount of time certificates will be valid.

The proposal would decrease the maximum lifespan to 200 days after September 2025, then to 100 days one year later, reports The Register. In April 2027, that period would shrink down to just 45 days.

The lifespan of the certificates has been decreasing over time anyway, going down from about eight years before 2011.

The move makes sense for security, since the shorter lifespans means that online criminals will have less time to exploit any vulnerabilities and older website certificates.

Sysadmins fight back



In responding to the proposal, administrators took to Reddit's r/sysadmin and complained about the potential changes. The comments touch upon the issues of a shorter lifespan, chiefly involving more regular updates to certificates being extra work.

With certificates being a difficult task for many, the prospect of changing them more often can be a headache. Add in the reliance on other vendors who may not be as punctual as their clients, and it can be a recipe for disaster or downtime.

While some may argue that automated updates could be the way forward, others have said that their vendors simply haven't included ways to automate the changes. Some network appliances that require SSL certs may not even be updated to be automated at all.

There is the small hope for sysadmins that the draft ballot will result in a vote against the measure by CA/B Forum members. However, as one user put it, Apple and Google could "just make it policy anyway," forcing more rapid updates.

Apple isn't the only one keen to cut the long-lasting certificates down to size. Google has previously indicated it wants to reduce the lifetime of certificates affecting browsing in Chrome.



Read on AppleInsider

Comments

  • Reply 1 of 16
    I can understand why. This shortening will just increase overhead and not contribute to better security.
    williamlondongrandact73sedicivalvole
  • Reply 2 of 16
    jimh2jimh2 Posts: 665member
    I can understand why. This shortening will just increase overhead and not contribute to better security.
    Contributing to better security is exactly why Apple (and others) want it done.
    williamlondonOferjbirdiikunwatto_cobra
  • Reply 3 of 16
    As it stands in October 2024, certificates have a lengthy lifespan of about 13 months. 
    The lifespan of TLS certificates can actually be between 1 day and 13 months (or longer if you roll your own Certificate Authority), and it varies from solution to solution. Most places go with exactly 1 year because it is easier to remember the same day every year.

    Anyone using a modern public cloud solution (CloudFlare, AWS, etc.) to operate their web offering will not have any problems with increasing the cadence of TLS renewal and the overhead involved, because the cloud provider handles it automatically behind the scenes. So anyone complaining that it is too much work to renew more frequently has chosen not to use the available public cloud automations for this and has also chosen not to invest in an alternative or homegrown automated certificate renewal solution. Instead, they are manually renewing and loading certificates - in an age where good systems administrators do everything possible to avoid manual deployments and the potential for human error that comes with it.
    foregoneconclusionwilliamlondonOferjas99freeassociate2watto_cobra
  • Reply 4 of 16
    jimh2 said:
    I can understand why. This shortening will just increase overhead and not contribute to better security.
    Contributing to better security is exactly why Apple (and others) want it done.
    Have you ever upgraded a SSL cert on servers?  Some are an outright nightmare.  The problem is there is no standard for installing them.
    muthuk_vanalingamgrandact73watto_cobra
  • Reply 5 of 16
    jimh2 said:
    I can understand why. This shortening will just increase overhead and not contribute to better security.
    Contributing to better security is exactly why Apple (and others) want it done.
    What a pain.
    williamlondon
  • Reply 6 of 16
    XedXed Posts: 2,884member
    ranson said:
    As it stands in October 2024, certificates have a lengthy lifespan of about 13 months. 
    The lifespan of TLS certificates can actually be between 1 day and 13 months (or longer if you roll your own Certificate Authority), and it varies from solution to solution. Most places go with exactly 1 year because it is easier to remember the same day every year.

    Anyone using a modern public cloud solution (CloudFlare, AWS, etc.) to operate their web offering will not have any problems with increasing the cadence of TLS renewal and the overhead involved, because the cloud provider handles it automatically behind the scenes. So anyone complaining that it is too much work to renew more frequently has chosen not to use the available public cloud automations for this and has also chosen not to invest in an alternative or homegrown automated certificate renewal solution. Instead, they are manually renewing and loading certificates - in an age where good systems administrators do everything possible to avoid manual deployments and the potential for human error that comes with it.
    Going from a maximum of 13 months to a maximum of 1.5 months seems like too much of a drop. I can see why they don't want the needle moved so drastically.
    williamlondonOferwatto_cobra
  • Reply 7 of 16
    Just use let's encrypt and you can do this automated, daily and at zero cost. 

    On the other hand, if you need a higher level of security: Stop bitching, safety first.
    appleinsideruserwatto_cobra
  • Reply 8 of 16
    Joer293Joer293 Posts: 31unconfirmed, member
    Ive worked for multiple cloud providers and security red/blue teams. Rotating certs for some systems is entirely hands off and flawless.  Like Microsoft AD and desktops. MS solved the desktop rotation headache decades ago. But, That is not the case for big businesses at all. They cant use lets encrypt or free tools to rotate because those all violate some other security compliance issue for their regulated work loads. certs for business critical apps are labor intensive, the change to 1 year mark for TLS has led to an industry wide increase of outages related to cert rotations. Sacrificing Availability for almost no gain of confidentiality isnt worth it for business.. Sure, changing 1 system is easy. Synchronization of changing certs on 100,000 servers of 100 different functions isnt easy, and automation would need changes every single rotation, making it not as helpful as executives think. Most internet infrastructure requires 30+ day notice for downtime and have dictated maintenance windows per customer contracts. Rotating certs on 24/7 apps requires downtime. Often its kept to a 60 second cut over, but worst case with banks mainframes, dozens of teams, it can be several hours. There are set maintenance windows too. 45 days really means 30 days + 15 grace period. Just like 13 months is 12 months + 1 month grace period. This will be a nightmare for security. Outside of researchers, nobody is breaking certs besides governments. Hackers have 1,000 ways to break in, certs dont even make it on that list of things to try. Like rekeying your front door monthly, when that effort distracts you from closing windows. 
    muthuk_vanalingamwatto_cobra
  • Reply 9 of 16
    XedXed Posts: 2,884member
    Joer293 said:
    Ive worked for multiple cloud providers and security red/blue teams. Rotating certs for some systems is entirely hands off and flawless.  Like Microsoft AD and desktops. MS solved the desktop rotation headache decades ago. But, That is not the case for big businesses at all. They cant use lets encrypt or free tools to rotate because those all violate some other security compliance issue for their regulated work loads. certs for business critical apps are labor intensive, the change to 1 year mark for TLS has led to an industry wide increase of outages related to cert rotations. Sacrificing Availability for almost no gain of confidentiality isnt worth it for business.. Sure, changing 1 system is easy. Synchronization of changing certs on 100,000 servers of 100 different functions isnt easy, and automation would need changes every single rotation, making it not as helpful as executives think. Most internet infrastructure requires 30+ day notice for downtime and have dictated maintenance windows per customer contracts. Rotating certs on 24/7 apps requires downtime. Often its kept to a 60 second cut over, but worst case with banks mainframes, dozens of teams, it can be several hours. There are set maintenance windows too. 45 days really means 30 days + 15 grace period. Just like 13 months is 12 months + 1 month grace period. This will be a nightmare for security. Outside of researchers, nobody is breaking certs besides governments. Hackers have 1,000 ways to break in, certs dont even make it on that list of things to try. Like rekeying your front door monthly, when that effort distracts you from closing windows. 
    Funny. Having to deal with MS support due to backend fuck ups they create is the single most time consuming issue I have.
    danoxwatto_cobra
  • Reply 10 of 16
    MarvinMarvin Posts: 15,486moderator
    Joer293 said:
    Ive worked for multiple cloud providers and security red/blue teams. Rotating certs for some systems is entirely hands off and flawless.  Like Microsoft AD and desktops. MS solved the desktop rotation headache decades ago. But, That is not the case for big businesses at all. They cant use lets encrypt or free tools to rotate because those all violate some other security compliance issue for their regulated work loads. certs for business critical apps are labor intensive, the change to 1 year mark for TLS has led to an industry wide increase of outages related to cert rotations. Sacrificing Availability for almost no gain of confidentiality isnt worth it for business.. Sure, changing 1 system is easy. Synchronization of changing certs on 100,000 servers of 100 different functions isnt easy, and automation would need changes every single rotation, making it not as helpful as executives think. Most internet infrastructure requires 30+ day notice for downtime and have dictated maintenance windows per customer contracts. Rotating certs on 24/7 apps requires downtime. Often its kept to a 60 second cut over, but worst case with banks mainframes, dozens of teams, it can be several hours. There are set maintenance windows too. 45 days really means 30 days + 15 grace period. Just like 13 months is 12 months + 1 month grace period. This will be a nightmare for security. Outside of researchers, nobody is breaking certs besides governments. Hackers have 1,000 ways to break in, certs dont even make it on that list of things to try. Like rekeying your front door monthly, when that effort distracts you from closing windows. 
    For big installations, it can cause a lot of headaches. They usually have teams of people to fix it but hours of downtime can cost millions.


    It feels like there could be a separation of privacy and trust. Encryption could be done ad-hoc at the protocol level and enabled all the time so there's never such a thing as http. Then there would be a separate process for trust.


    Encrypt the connection ad-hoc to ensure the communication is always safe and private.
    Have trust certificates to verify the company is who they claim to be.

    This separates the functionality of the service from the trust of the service and an expired certificate wouldn't matter so much and possibly easier to deploy.

    There should be a habit of renewing trust certificates well in advance of expiry. If the certificates gave internal warnings to sysadmins of expiry 3 months in advance, most would renew them in advance and put the new ones in place for transparently swapping to the new ones.

    Switching to shorter time periods needs the process to be more seamless first.
    watto_cobra
  • Reply 11 of 16
    I'm with THEM on this one. Apple is nuts. Some systems can take a cert. and keep on truckin'. Other systems require a restart. Problem is companies rely on vendors unless they design their systems themselves. NOT everything can be in the "cloud" which is just another data center BTW - due to constraints with getting there (internet), latency requirements, older tech requirements of applications. The company I work for has over 6K servers and untold thousands of devices that require certificates. Yes, we do our own certificates but not all apps work with them. 

    So no - 12-13 months it should remain. 
    muthuk_vanalingamwilliamlondon
  • Reply 12 of 16
    Yes this sounds like a great idea. 

    Not. 

    If you don’t live in the real world and actually deal with certificate rotation across many platforms and systems. 

    Definitely up there for one of the worst ideas to come out of Apple in recent years. 

    Many other issues you could solve Apple that would actually help. Don’t push this, outside of your world Apple this won’t help increase security. Rather the opposite. 
    edited October 16 muthuk_vanalingamwilliamlondon
  • Reply 13 of 16
    netroxnetrox Posts: 1,505member
    I don't get it - CA should be indefinite as long as it's still the same identity. why do they need to renew? If the identity is compromised, CA then just revokes it.

    What changed? 
    williamlondonwatto_cobra
  • Reply 14 of 16
    ITGUYINSD said:
    jimh2 said:
    I can understand why. This shortening will just increase overhead and not contribute to better security.
    Contributing to better security is exactly why Apple (and others) want it done.
    Have you ever upgraded a SSL cert on servers?  Some are an outright nightmare.  The problem is there is no standard for installing them.
    And that’s one good reason not to be using that server. It means there was no (competent) system architect and there are other pitfalls awaiting you. Easily updated certs are a BASIC function. 
    randominternetpersonwatto_cobra
  • Reply 15 of 16
    DAalsethDAalseth Posts: 3,048member
    ITGUYINSD said:
    jimh2 said:
    I can understand why. This shortening will just increase overhead and not contribute to better security.
    Contributing to better security is exactly why Apple (and others) want it done.
    Have you ever upgraded a SSL cert on servers?  Some are an outright nightmare.  The problem is there is no standard for installing them.
    And that’s one good reason not to be using that server. It means there was no (competent) system architect and there are other pitfalls awaiting you. Easily updated certs are a BASIC function. 
    While in theory I agree with you, we are dealing with a lot of legacy shit out there that has not been upgraded. In theory they all should be running on modern systems that are slick as snot to upgrade, in reality there’s a lot that aren’t, including critical systems that Brass has never seen fit to replace because they work and it would cost money.
    OriginalAppleGuywatto_cobra
  • Reply 16 of 16
    danoxdanox Posts: 3,414member
    I’m sure Apple isn’t doing this just to do nothing, they once had an idea to move third-party companies out of the OS kernel few years ago, and then proceeded to do it, this is probably some long range solution to something that they are working on behind the scenes, particularly if they get into in house servers, Apple being Apple isn’t gonna just stop at using a Ultra M2 servers and leaving it at that, what comes later as they progress to M4, M5 or M6 Ultras or Mac Pro solutions down the road there is some reason behind it, those who have been working in the field for a very long time must know of some good reasons, why it would be to your advantage to shorten/optimize/cleanup certificate times.

    Apple also is known for moving forward and not hanging onto legacy because they control the OS and the hardware and almost certainly would want to use that advantage to optimize.
    watto_cobra
Sign In or Register to comment.