back to article Remember when we warned in February Apple will crack down on long-life HTTPS certs? It's happening: Chrome, Firefox ready to join in, too

From September 1, Apple software, from Safari to macOS to iOS, will reject new HTTPS and other SSL/TLS certificates that are valid for more than 398 days, plus or minus some caveats. If that sounds familiar, it's because we told you so in February before the iGiant even formally announced the policy. A month later, it revealed …

  1. Lyle Dietz

    That kinda sucks...

    I guess that's the end of me renewing my certs 3 months before expiry...

    1. Steve Davies 3 Silver badge

      Re: That kinda sucks...

      Not really. 398 days is over a year. 13months or there abouts. So your once a year on a certain date just becomes once a year on a rolling 12 months.

      OR

      You could invest in some automation that renews them, replaces the old cert and emails you to say 'Job done and here are the results'.

      It isn't all doom and gloom. If shorter cert lives stops a load of bots then isn't that a good thing?

      1. Anonymous Coward
        Anonymous Coward

        Re: That kinda sucks...

        Why would it stop bots? When a cert if found to be miss used it can be revoked and would not be usable again, oh, wait, Apple and also chrome doesn't check for certificate revocation by default so it loads websites faster. Maybe they should turn that on first to increase security.

      2. DevOpsTimothyC

        Re: That kinda sucks...

        No. The CA would be issuing a cert with a 15 month life or about 455 days. 3 months left on the existing + 12 months for the renewal. That would then breach the 398 days

  2. EricM

    Is there any advantage left by using commercial certs?

    Or can all commercial websites now just migrate to let's encrypt?

    1. NikNakk

      Re: Is there any advantage left by using commercial certs?

      Great though Let’s Encrypt is, it does not offer Organization Validated or Extended Validation certificated. Commercial organisations that want to have those (particularly the latter which shows up differently in many browsers) will need to keep buying commercial certificates. For the rest of us, Let’s Encrypt seems to work really well and makes configuring HTTPS on supported web servers pretty painless.

      1. chroot

        Re: Is there any advantage left by using commercial certs?

        In what browser do EV certificates still show up differently?

        1. Kientha

          Re: Is there any advantage left by using commercial certs?

          Also, even when they did show up differently when was that remotely useful to the end user? Especially when many sites had a different name in their EV certificate than their website was actually called

      2. DrXym

        Re: Is there any advantage left by using commercial certs?

        It also doesn't work well at all with some providers like GoDaddy.

      3. Phil W

        Re: Is there any advantage left by using commercial certs?

        LetsEncrypt doesn't provide CRL DPs in their certs which are required for some things.

      4. RichardBarrell

        Re: Is there any advantage left by using commercial certs?

        As chroot mentions in the other comment, browser vendors eliminated the visual differences between EV and non-EV certificates a while back.

        Empirical experiments were run & demonstrated pretty conclusively that nobody was checking for (or cared about) the extra UI widgets browsers used to put in the address bar for EV certs. In general, people do notice negative security indicators ("not secure", red bars, etc) but they don't notice the absence of positive security indicators (like https markers).

        (When I say "nobody", I mean really, nobody. Not just lay audiences: people in IT, programming and information security too.)

        1. Jim Mitchell
          Unhappy

          Re: Is there any advantage left by using commercial certs?

          Hey, *I* was checking for the extra UI widgets!

      5. Anonymous Coward
        Anonymous Coward

        Re: Is there any advantage left by using commercial certs?

        EV certificates are dead https://www.troyhunt.com/extended-validation-certificates-are-really-really-dead/

    2. Anonymous Coward
      Anonymous Coward

      Re: Is there any advantage left by using commercial certs?

      Single point of failure?

      1. Allonymous Coward

        Re: Is there any advantage left by using commercial certs?

        I've been told Buypass supports the ACME protocol and issues free certificates. Not tried it myself, but in theory that provides a backup to Let's Encrypt.

        https://www.buypass.com/ssl/resources/go-ssl-technical-specification

    3. Pascal Monett Silver badge
      Trollface

      Re: Is there any advantage left by using commercial certs?

      I think they should. That way other cert sellers will have all the time they want to get with the program.

      I'm sure Telia will be relieved.

    4. DevOpsTimothyC

      Re: Is there any advantage left by using commercial certs?

      Anyone who can hijack the DNS can get a lets encrypt cert.

      It then prompts the question of why not just admit that SSL has nothing to do with trust and it is there solely to confirm that the data hasn't been tampered with in transit.

  3. DCdave
    FAIL

    Some sense for the web, disaster for internal

    I can see why it might be a good idea for certificates used over the web (with some caveats), but this is now a pain for internal-use certificates e.g my reporting website, because even if there's no problem having longer expiry date, people now start frothing at the mouth, because their browser tells them it's a problem. Worse, the vulnerability scanner is reporting it as a vulnerability and the security people are frothing at the mouth that we need to fix this problem. Although to be honest it's only https in the first place because they started frothing at the mouth that it wasn't encrypted.

    1. Steve K

      Re: Some sense for the web, disaster for internal

      this policy applies to certificates issued ultimately from root CAs known to Apple's operating systems, not user or administrator-added CAs.

      I don't think it will matter for internal-only CA's

      1. DevOpsTimothyC

        Re: Some sense for the web, disaster for internal

        I've worked at a number of places that purchased the cheapest (trusted) wildcard cert they could find to secure internal servers,. It was cheaper to buy a real cert than manage an internal CA

    2. James 139

      Re: Some sense for the web, disaster for internal

      I feel your pain on the last point. It's like people never heard of "mitigating factors" or "it's entirely unnecessary", they just see a "red mark" on some automated scanner and start frothing.

      More often than not they have also over paid someone to run the report, and who is conveniently offering to offer paid advice on it.

  4. 9Rune5

    Time's up

    "We can manage with the changes but we think that it is an unnecessary burden to our community and we should give more time to them to build their SSL automation, perhaps two more years."

    Let's encrypt has been around for quite some time now. Just how long do these jokers need to get their --it together?

    1. Anonymous Coward
      Anonymous Coward

      Re: Time's up

      IPv6 has been out for longer. What was your point & why are they asking for only two years?

  5. A random security guy

    Will this be a problem for embedded device certs?

    If we have have an embedded device which has a tiny web server (e.g. router, temp monitor, etc.) and it supports TLS, then do they expect the embedded server to renew its certificates every year or so?

    For that to happen automatically, they need to be connected to the internet. However, many of these devices should never be connected to the internet.

    1. Hawkeye Pierce

      Re: Will this be a problem for embedded device certs?

      Well you either had a mechanism already in place for updating the certificate every 27 months, so you just need to do this twice as frequently as you previously did, or you've spun up your own CA/certificate in which case as the article states, the new lifetime doesn't apply.

      1. Duncan Macdonald

        Re: Will this be a problem for embedded device certs?

        Many embedded devices have their own server and certificate baked in at the manufacturing stage and can not be updated by the end user. They will be broken by this change to the browsers.

        Browsers at a minimum need to have a setting that allows long lifetime certificates to be used.

        1. Mike 137 Silver badge

          Re: Will this be a problem for embedded device certs?

          "Browsers at a minimum need to have a setting that allows long lifetime certificates to be used."

          Perfectly valid comment - in fact browsers should have a setting that allows the user to decide which certificates (and indeed which TLS versions) to accept. I'm getting utterly frustrated with browser vendors making these decisions for me - I should be allowed to be in charge of my own security.

          By all means have such measures enabled by default, but we should be able to turn them off if we want. In our lab, we're stuck with using some "unsupported" browsers due to compatibility issues, and are finding that increasing numbers of perfectly safe sites are no longer accessible due to certification "advances".

        2. EnviableOne

          Re: Will this be a problem for embedded device certs?

          a "here be dragons warning" and a little "click here" if this is ok and "are you sure?" should be enough faffing around to stop the casual user going there, or allow a one time lifetime exception

    2. IGotOut Silver badge

      Re: Will this be a problem for embedded device certs?

      The article clearly states internal certs are NOT affected.

      1. J. Cook Silver badge

        Re: Will this be a problem for embedded device certs?

        Chromes throws it's toys out of the pram with any cert that it can't validate, or ones that are not in the computer's trusted store, so business as usual.

    3. Sven Coenye

      Re: Will this be a problem for embedded device certs?

      You do what Samsung likely did on June 19 and have all such devices enter a boot loop. Problem fixed.

    4. DevOpsTimothyC

      Re: Will this be a problem for embedded device certs?

      I think you've hit the issue, just in the wrong way.

      Many of the devices you are talking about will NOT support the latest TLS standards. They are precisely the sort of devices that this is trying to remove

  6. DrXym

    Shake down time

    it doesn't even make sense. It should be the weakness / strength of the key length, cipher and hash that determines how long a key is acceptable for, not some arbitrary period of time.

    A five year old cert generated with the same settings as a cert generated yesterday is no less secure in 99.9999% of use cases. Perhaps if I were a bank, NGO or government I might want to renew keys more frequently. But if I'm some guy maintaining a gardening website or small business then now I have 5x the work to keep my site secure for no benefit at all.

    1. Anonymous Coward
      Anonymous Coward

      Re: Shake down time

      This is a fair view, but you have to remember they're looking in aggregate at all certificates, not the security of any one certificate. When you're asking questions like "How do we limit the impact of breaches against every cert we see?" you get different answers to the question "How do I limit the impact of breaches against the one cert I manage?". They're doing risk management at scale, not point-solution infosec. A 12 month lifetime is already common practice in financial services, for example, for exactly this reason.

      >Now I have 5x the work to keep my site secure for no benefit at all.

      I don't buy this. Mr Gardening Chap's website is almost certainly run by an external provider, who can trivially automate this and probably already has. Now instead of running renew-certs.sh every 24 months they're going to do it every 6 or 12 months. That isn't any more work - it's a change to your crontab and calendar reminder. If Mr Gardening Chap hasn't outsourced the running of his website, then he is probably more than competent enough to just use Let's Encrypt and get the same outcome.

      1. DrXym

        Re: Shake down time

        If a 12 month cert is common practice in those that need it then why does it need to be enforced, even in aggregate? If the argument is that certain keylengths or hashes are weak, then deprecate those certs, don't impose blanket rule that even a strong cert needs to be replaced.

        As for random gardening website (or the gazillion small websites) , they aren't going to be attacked by state actors using hash collisions. And perhaps some hosting providers do make it easy to renew keys. Many don't. And many that do charge money for it. Even free services like Let's Encrypt don't integrate with some providers and have a cost associated with setting them up. There is always a cost to this and it yields nothing to these sites.

        Browser makers have it in their power to simplify this. They want sites to use encryption but they make the process more onerous.

        1. IGotOut Silver badge

          Re: Shake down time

          If your provider charges for Let's Encrypt, move provider.

          I'm with TSO host, formally something else and before that something again and no part of Go Daddy, and they do it for free. It' about 5 clicks to set up.

          Oh and then you can always sign up, for free, to Cloudflare, and use their free service.

          1. DrXym

            Re: Shake down time

            So your solution to certificates becoming a pain in the ass is to suffer more pain by moving provider in order to alleviate some of the other pain. But for something the website didn't need in the first place.

      2. ChillyHellion

        Re: Shake down time

        You missed the "for no benefit at all" part of the complaint. There's little difference between a hacker compromising a cert for 12 months vs 24 momths; that's still a huge window to operate in. The solution is for each browser to do its own revocation checking, but no browser wants to incur the .0001 ms delay it would take per-page to run the check. So they pull unilateral stunts like this to push the solution in a direction that impacts browsers the least, even when it doesn't actually address the problem.

        And let's not pretend like let's encrypt will be the solution in every case. Plenty of up-to-date software still doesn't support certificate automation, and some software has horribly complex certificate renewal procedures. You may not run any of these services in your shop, but that doesn't mean your fellow industry professionals should suffer for zero added security benefit to the industry.

    2. pmb00cs

      Re: Shake down time

      Well Actually.....

      So a Cert Issued five years ago with a secure algorithm is theoretically less secure than a cert issued yesterday, not because the certificate itself is more vulnerable, but because the private key has had more time to leak, or be compromised. If you never rotate the private key, then absolutely, renewing the certificate isn't actually more secure, and your statement holds. And I know that it is easy to renew a certificate with the same private key using some of the comercial certificate providers (I've done it more than once in the past).

      Of course generating new keys is also fraught with caveats and gotchas, so in theory generating a new private key every time you get a new certificate is more secure, in practise there are circumstances where that may not be true.

      Or in other words, it's complicated.

      In general automating certificate renewal in a process that generates a new key each time is more secure, and less error prone, than having manually generated csr's and certificate rotations.

  7. Povl H. Pedersen

    Everybody follows the minority player

    Again, everybody follows the small marketshare player Apple.

    They sell less than 15% of all smart-phones, yet considered a monopoly. I guess they redefined what monopoly means :-)

    Now, when will we get warnings in Windows about clipboard snooping ? Something Apple will warn about in next gen OS-X and iOS.

  8. Steven Raith

    Shame that some one year certs....

    .....are actually two year certs that presumably get revoked if you don't renew, it seems.

    Welp, that makes things a bit more annoying.

    Steven R

  9. JavaJester

    Microsoft Doesn't Matter at This Point

    Chrome, Safari, and Fire Fox account for over 80% of browser market share according to StatCounter Global Stats. If you operate a public facing website, the shorter cert expiry is a done deal. The only thing left for Microsoft is to decide if they want to be consistent with the other browser makers.

    1. A.P. Veening Silver badge

      Re: Microsoft Doesn't Matter at This Point

      The only thing left for Microsoft is to decide if they want to be consistent with the other browser makers.

      Microsoft will, eventually (but don't hold your breath).

      1. keith_w

        Re: Microsoft Doesn't Matter at This Point

        Microsoft's Edge is a Chromium based browser, since Google has committed the change to the browser source code, so Edge will probably be implementing it sooner rather than later.

    2. MOH

      Re: Microsoft Doesn't Matter at This Point

      Well they've a great track record on that front

  10. tip pc Silver badge

    2 year cert valid for 390 more days in sep 1st?

    So what happens if my 2 year feet is still valid for 390 more days by sept 1st? Is it still valid as it was valid from before sept 1st?

    What happens if on sept 2nd I create a very valid for 400 days, will the browsers accept the feet as valid on sept 10th as it’ll be well within the 398 days it will it be rejected as it’s validity is greater than 398 days.

    1. AMBxx Silver badge

      Re: 2 year cert valid for 390 more days in sep 1st?

      Read the article. It's not from 1st September, it's for certificates issued after 1st September.

    2. Danny 14

      Re: 2 year cert valid for 390 more days in sep 1st?

      Buy a 5 year cert before 1st sept. I imagine the browser looks at both start and end date for cert check.

      1. DougMac

        Re: 2 year cert valid for 390 more days in sep 1st?

        5 year certs haven't existed for xx number of years. The longest you've been able to get is 2 year certs since March 1st 2018.

        1. Anonymous Coward
          Anonymous Coward

          Re: 2 year cert valid for 390 more days in sep 1st?

          3 year certificates definitely exist. I renewed one a couple of months ago. Not sure if my registrar issues 5 year certs as I have no reason to buy those.

  11. Maelstorm Bronze badge
    Flame

    What the?

    So when did Apple start to dictate to the end user about website certifications and how long they are supposed to be? The length of time should be a matter of administration, not being shoved down people's throats. This, and other reasons, are why I do not purchase Apple products. Apple caused this, they should bear the burden of their actions. But they won't, so the rest of us has to deal with the fallout of their decisions.

    1. Danny 14

      Re: What the?

      They code safari, they can do as they like. They can drop support for html5 if they want to. It will be the end users who voice their complaints. But if chrome and Firefox do the same then there goes the standard way of doing things.

      1. A.P. Veening Silver badge

        Re: What the?

        But if chrome and Firefox do the same then there goes the standard way of doing things a new standard is in rapid development.

        FTFY.

    2. Anonymous Coward
      Anonymous Coward

      Re: What the?

      When the developers of most major browsers agree with them.

  12. ChillyHellion

    Browser makers shifting the burden to local IT

    Browser makers could easily add in a certificate revocation check that would solve this problem far better than just shortening the cert lifespan. There's a standard for this already. But no browser wants to incur the .00001 ms delay it would take to check a revocation server, when they can push the burden to your local IT department instead (even when that doesn't solve the problem nearly as well). Browser makers held a ballot, the ballot failed, and so they made this unilateral move to address the problem in the laziest way possible that impacts them the least.

    There are plenty of self-hosted services that don't play well with Lets Encrypt and can't yet be automated. Hell, Atlassian products don't even officially support SSL certs; you have to go through some murderous third-party hack in order to get the cert installed on each server every few years (now every year I guess).

    The worth thing about this "solution" is that 12 months is still plenty of time for a malicious actor to retain your cert and do some serious long-term damage, so this move doesn't even address the problem. A robust certificate revocation system is the best way to solve this problem, and the browser makers are worried that the technical public will figure that out.

    1. Anonymous Coward
      Anonymous Coward

      Re: Browser makers shifting the burden to local IT

      There is already a revocation check, most browsers will periodically a download revocation list. It can also be done relatively quickly on the fly if a server supports OSCP stapling.

  13. bobblestiltskin

    The Fall?

    Now all eyes are on Microsoft, which is expected to make a decision on the issue by the Fall.

    I have not heard that one - and The Fall are one of my favourite bands.

    R.I.P M.E.S

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like