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

AppleInsiderAppleInsider
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 10
    quakerotisquakerotis Posts: 90member
    I can understand why. This shortening will just increase overhead and not contribute to better security.
    williamlondon
  • Reply 2 of 10
    jimh2jimh2 Posts: 659member
    quakerotis 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.
    williamlondon
  • Reply 3 of 10
    ransonranson Posts: 83member
    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.
    foregoneconclusionwilliamlondon
  • Reply 4 of 10
    ITGUYINSDITGUYINSD Posts: 537member
    jimh2 said:
    quakerotis 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_vanalingam
  • Reply 5 of 10
    commentzillacommentzilla Posts: 767member
    jimh2 said:
    quakerotis 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 10
    XedXed Posts: 2,833member
    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.
    williamlondon
  • Reply 7 of 10
    humbug1873humbug1873 Posts: 161member
    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.
  • Reply 8 of 10
    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. 
  • Reply 9 of 10
    XedXed Posts: 2,833member
    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.
  • Reply 10 of 10
    MarvinMarvin Posts: 15,452moderator
    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.
Sign In or Register to comment.