back to article Apple drops a bomb on long-life HTTPS certificates: Safari to snub new security certs valid for more than 13 months

Safari will, later this year, no longer accept new HTTPS certificates that expire more than 13 months from their creation date. That means websites using long-life SSL/TLS certs issued after the cut-off point will throw up privacy errors in Apple's browser. The policy was unveiled by the iGiant at a Certification Authority …

  1. JohnFen

    I understand

    I get why they're doing this, but it's such a huge pain in the ass. The 90 day lifetime of LE certs are the primary reason why I don't use LE certs. Apple's restriction isn't quite that draconian, but it's still painful. If this trend worsens, I may have to consider whether or not it's actually worth running public-facing websites.

    1. Jamie Jones Silver badge

      Re: I understand

      I too can see the good behind this, but I'm concerned that this is basically being forced on everyone due to Apples whim.

      Same with google. Whatever either decides to do, others are forced to follow. Couldn't they at least pretend to get it to go through a standardisation process like Google does?

      As for lets-encrypt - I set it up for someone almost a year ago, and haven't had to get involved since. The renewals are automated.

      1. DougMac

        Re: I understand

        >> As for lets-encrypt - I set it up for someone almost a year ago, and haven't had to get involved since. The renewals are automated.

        Unless you routinely update your code packages (ie. installed the package from a PPA or make sure to go get the newest code from their github), the certbot client from two years ago isn't going to work after this summer when they disable ACME v1 as well.

        So, not quite plug and forget.

        1. Hoe

          Re: I understand

          There is that then there is also the fact you have to leave Port 80 and Port 443 open for it to negotiate the renewal which is so fustrating, I renew, close 80 wait for the notice, open 80 renew manually then close Port 80 again.

          Why O Why can they not just renew it through Only Port 443?!

          1. Anonymous Coward
            Anonymous Coward

            Re: I understand

            Yes this is also why I still do the LE renewal manually.

            I leave 80 off in my firewall which is on a different machine and thus can't be temporarily opened by the VM with the server running certbot. They make this needlessly complex.

            1. Crypto Monad

              Re: I understand

              You don't need to open anything in your firewall if you use the DNS-01 challenge for renewal. Instead, you need to dynamically add a temporary TXT record to your DNS domain, and remove it afterwards.

              This can be done using an outbound "push" to your DNS provider. There are many Letsencrypt agents which can do this, which integrate with many different DNS service providers.

              1. foliovision
                Thumb Up

                Re: I understand

                Thanks for the tip on an alternative method. Very helpful.

            2. cbars

              Re: I understand

              Sure it can.

              I leave 80 open at the firewall and block at the machine level so my bash script can flip it open while renewing, but it's quite trivial to set up an ssh user on your firewall box that your web server can use to log in, open the port, then close it again (even ensure the user can only do that one command pair). Also, set a cron job up on your firewall to check and close the port every hour in case anything goes wrong.

              This is SSL for FREEEE, business case for the effort required is easy

              1. Gerhard Mack

                Re: I understand

                You don't even need to flip it. Just provide public access to .well-known and restrict access for the actual website.

          2. Berny Stapleton

            Re: I understand

            You could of course renew it at less than 30 days which would mean your existing authentication token would still be valid and you could renew without having to open port 80....

          3. gerdesj Silver badge

            Re: I understand

            "Why O Why can they not just renew it through Only Port 443?!"

            You can use https if you wish but it wont make any security related difference that I can think of and I spend quite a lot of my time worrying about IT security. For starters the authentication URL only exists for the duration of the exchange and that's about five seconds or less.

            Try defining a redirect or protocol change on your web server or whatever from http to https and note that it still works. You will still need port 80 open to initiate the redirect but that is all.

        2. Jamie Jones Silver badge
          Thumb Up

          Re: I understand

          Thanks.. I don't even recall which version it's running... Maybe I should check sometime!

      2. JohnFen

        Re: I understand

        > As for lets-encrypt - I set it up for someone almost a year ago, and haven't had to get involved since. The renewals are automated.

        Yes, I'm aware that renewals can be automated, but due to oddities about how my websites operate, implementing that automation is a bit of a project for me. It's much easier to simply not use LE instead.

      3. JohnFen

        Re: I understand

        > Couldn't they at least pretend to get it to go through a standardisation process like Google does?

        In fairness to Apple, this would be unnecessary. What they're doing is in line with the existing standards, after all, so no changes there are needed. Google goes through the RFC process when they want to actually change what the standard says.

      4. Anonymous Coward
        Anonymous Coward

        Re: I understand

        You know why google have proposed this? Because chrome is a security problem for certificates, it doesn't check the revocation of a certificate (slows the browser down). Go check chrome is ok, vivaldi, firefox etc, its not its revoked (might not be now, i notified hpe of it).

      5. BillG

        Re: I understand

        Just wait until users start complaining Safari is rejecting certificates of popular sites. Then we'll see if Apple sticks to this plan.

    2. SJA


      How is automatic renewal a pain? I've been using LE since it was available for beta. Meanwhile I just use DNS-01 because that allows me to get wildcard certs and cerst also for (sub-)domains that aren't reachable from the internet.

      And as LE recommends, they get renewed every 60 days, so there's a grace period of 30 days and LE also sends out friendly reminders if your certs are to expire soon and you haven't requested new ones yet.

      1. brotherelf

        Re: PITA?

        How is it a pain? Don't ask me, ask the people running or mozilla add-on update servers, those being two examples that come to my mind of sites that ran around with expired LE certs for quite a while.

        It's a fun sport if you're so inclined: compare the certificates in use with the public ledger of issued certificates. If the auto-renew doesn't work, who knows what else doesn't work on those servers.

        1. Anonymous Coward
          Anonymous Coward

          Re: PITA?

          How about systems that are not publicly available for LE to call back?

      2. LDS Silver badge

        "How is automatic renewal a pain?"

        Try it on some network and embedded devices, where renewing certificates has to be done manually and it's a quite slow process.

        Once again, they say "certificate" and mean "social/online stores". Just that's the more visible part of the internet - but it's just a relatively small part of the whole world networking.

        1. Anonymous Coward
          Anonymous Coward

          Re: "How is automatic renewal a pain?"

          "Try it on some network and embedded devices, where renewing certificates has to be done manually and it's a quite slow process."

          So, shouldn't you first be taking that out on the network and embedded device manufacturers for not providing a way of automating it?

          (PS: I sympathise though - same boat :-(

          1. LDS Silver badge

            Re: "How is automatic renewal a pain?"

            As written elsewhere, those devices may not have internet connectivity at all, and may get certificates from a private CA, and you may want specific certificate features not available otherwise.

            Let's encrypt was designed for different needs, and its renewal protocol is not a standard. For example Active Directory uses its own to distribute certificates. Others CA may have otjers. How many you have to code into firmware?

            Moreover all we know how much support we get for 'older' devices when supplier all wish you buy new ones to fatten their revenues. Maybe Apple sits on a huge pile of gold and can replace everything once a year, others may not.

      3. JohnFen

        Re: PITA?

        > How is automatic renewal a pain?

        Because setting it up is pain for my hosting arrangement, that's all. That puts the cost/benefit ratio for me using LE well above other solutions.

        Automated renewals are probably great for most, but they aren't anything like a great solution for everybody.

    3. Anonymous Coward
      Anonymous Coward

      RE: I understand

      John; LE has an auto-renew feature. Out of the box, I think most LE clients offer the option to auto-renew with a crontab at any point past 30 days or so, meaning you never have to touch it, again... Got over 1300 domains/devices running it and never had a problem with any!

      1. JohnFen

        Re: RE: I understand

        Yes, I'm very familiar with how LE works.

    4. Danny 14

      Re: I understand

      I use certify the web for my LE renewals on windows servers. Works fine for exchange, IIS, ADFS (with triggered scripts for the WAP) and vpn.

      1. David Austin

        Re: I understand

        Have you got full automation with Certify The Web working for wildcard certificates?

        having a play with that at the moment, and looks like I can't make it work unless I change DNS provider, but happy to be proved wrong.

        I do wish IIS wasn't a second class citizen of the let's Encrypt Ecosystem; Full native support direct from MS is high on my Windows Server wish list.

        1. katrinab Silver badge

          Re: I understand

          I have it working, using OVH as my DNS provider, everywhere except for ADFS/WAP because there I have to same private key on two different servers.

    5. big_D Silver badge

      Re: I understand

      And don't forget that Google and Firefox are dropping Extended Validation certs in Chrome (you know, ones where the cert authority actually check out the applicant in the real world, to ensure they are who they say they are).

      It is making a mockery of the whole process.

      1. Chris Warrick

        Re: I understand

        The EV system is completely broken. Someone managed to get EV certs for "Stripe, Inc." (even though they were not the payment processor) and "Identity Verified" (because they registered a company with that name).

        At the same time, users didn't notice the extra text added by EV certs, so its security value was zero.

        1. katrinab Silver badge

          Re: I understand

          "Stripe Inc Limited" formerly located at Ground Floor Flat, 120 West Green Road, London, N15 5AA, has been disolved because they didn't file any accounts or annual returns.

          Someone else could register it now, and use it for all sorts of purposes. Having a company registered in one jurisdiction doesn't prevent someone else registering a company with the same name elsewhere, and both companies are equally valid.

          1. JohnFen

            Re: I understand

            Right, which is exactly what makes EV certs pointless.

            1. LDS Silver badge

              Re: I understand

              That's what also makes LE certificates pointless but for encryption. I would never trust LE authenticate anything.

    6. Mike007

      Re: I understand

      LE certs are meant to be automated, so renewals are not an issue. In theory a 1 day validity period could work however for practical reasons they need to be a little longer.

      If you are manually installing a LE cert then the problem is that you are doing it wrong. Sitiations where automatic provisioning and renewal isn't practical is where other CAs fill the gap, as they can manually verify legitimacy and issue a certificate that can be manually installed on for example a non-internet-reachable device. I agree that in these situations a 2 or 3 year cert should be allowable, however as there is no distinction between automated validation and manual this is hard to differentiate at a technical level. Perhaps this is where EV certificates could see a use, with the assumption that EV was deliberate and intentional and verified whilst a non-EV cert can be assumed to have been automated at some point and therefore have a lower trust level?

      In case anyone is wondering, LE wanted the shortest validity time to reduce risks with temporary hijacks or expired/sold domains but compromised on 60 day renewals to reduce load, with a 30 day grace period to allow for temporary outages and other intermittent failures.

      It is also beneficial for automated renewals if it breaks sooner rather than later, because if your renewal script is broken then finding out sooner is far better than finding out after 12 months when everyone involved has either moved on or forgotten about the project. You also get an email if renewals fail before the cert actually expires to give you time to rectify the fault, which is only useful BECAUSE you do not get email notifications unless something is broken. In an ideal world a LE cert would be valid for say 1 week when first issued to pick up on problems sooner, with a renewal on say day 5 which then gives you a normal 3 month cert. But, this increases technical complexity.

      1. JohnFen

        Re: I understand

        > LE certs are meant to be automated

        I know. That LE leans so hard on automation to be useful is what makes it less than useful to me.

        1. Jamie Jones Silver badge

          Re: I understand

          Fair enough.

          You're right, we can't assume everyones requirements can fit into the usage-model presented.

          Still, no-one said that setting up your secret base under an old extinct volcano would be easy! Anyway, how are the world-domination plans going? Do I still get Europe, as agreed?

      2. Jamie Jones Silver badge

        Re: I understand

        It is also beneficial for automated renewals if it breaks sooner rather than later, because if your renewal script is broken then finding out sooner is far better than finding out after 12 months when everyone involved has either moved on or forgotten about the project.

        Off topic, but when I started my last job, every few months or so, some weird cron script would run unexpectedly, and usually mess something up (or not be noticed), and no-one would have any idea what it was about.

        It turned out, the staff had always been taught "If putting in a one off cron job, don't just set the hour and minute start time, because it will run again the next day if you don't have a chance to cancel it in time. Also, set the day of month and month of year fields so that you have plenty of time to revert the change".

        Of course, the thing you describe inevitably happened regularly.

        I soon got that changed.

        1. Orv

          Re: I understand

          ...aren't one-off jobs why we have "at"?

      3. Hugh McIntyre

        Re: I understand

        RE: "LE wanted the shortest validity time to reduce risks with temporary hijacks or expired/sold domains but compromised on 60 day renewals to reduce load, with a 30 day grace period to allow for temporary outages and other intermittent failures."

        This is nice (and I use LE). But I can't help noticing that the Let's Encrypt Authority X3 signing certificate is valid from March 17 2016-2021, i.e. 5 years.

        Not sure if this new 1 year limit from Apple will only apply to the leaf certificate or also all signing certificates up the chain? The latter is potentially more painful.

    7. The Man Who Fell To Earth Silver badge

      Re: I understand

      Why do I doubt this will be revenue neutral between the cert authorities & their customers?

    8. Michael Wojcik Silver badge

      Re: I understand

      Personally, I'm not concerned if Safari rejects my certificates. Safari can fuck right off.

      Where this sort of thing (like much of what the CA/BF does) is really a hassle is with certificates issued by private, intra-organizational CAs, for internal systems and testing and so on. It's just one more unnecessary failure mode.

  2. This post has been deleted by its author

    1. This post has been deleted by its author

  3. markrand

    Have they issued an RFC? What's its number?

    1. schafdog

      A google proposal at CA/B

      It was a google proposal that fell in august. Apple have decided to implement it anyway. I can’t see a big problem. It has gone from 3 to 2 and now 1. If you embedded that cannot be upgraded you would still have a problem. The root cause is not the cert lifetime

    2. Michael Wojcik Silver badge

      The CA/BF doesn't use the RFC process. The cabal periodically gathers to moot new requirements, and sometimes members make changes unilaterally, as in this case.

  4. Gene Cash Silver badge

    It's optional

    You can always say "fuck you, Apple" and use a 2-year certificate. Tell people who complain "don't use Safari"

    1. Tim99 Silver badge

      Re: It's optional

      True, but a (significant?) portion of them who may well have money will still use Safari and go somewhere else...

      1. find users who cut cat tail

        Re: It's optional

        Depending on your target audience, that may be a good thing.

      2. JohnFen

        Re: It's optional

        None of my websites are in any way related to revenue creation, so the wealth of my users isn't important to me.

    2. Nate Amsden Silver badge

      Re: It's optional

      This will just encourage Google and firefox to do the same. Everyone knows they want to. Such a pain in the ass. As usual this will impact internal cert authorities as well. The internet continues to go down the toilet. Sigh

      1. Zippy´s Sausage Factory

        Re: It's optional

        I suspect it was something people agreed on but nobody wants to go first. Apple looked left, looked right, saw nobody else was going to do it and decided to jump first.

        CAs will love this, of course, because now they can charge more for a one-year certificate than a two-year used to cost. Which, naturally, they will say is to cover increased costs, and not to make higher profit margins because nobody in the security industry thinks like that, how dare you even suggest it?

        (Plot twist: next week, Apple launches a takeover of Verisign...)

        Cynical, moi? Of course I am!

        1. Nate Amsden Silver badge

          Re: It's optional

          CAs don't love this they were fighting against the earlier proposals to reduce cert times.

          App vulnerabilities are so much more of an issue than ssl problems. This really does little to improve security. It does a lot to frustrate operators though.

        2. talk_is_cheap

          Re: It's optional

          The CAs are more worried about losing business from this change - If you have to keep updating your certs you are more likely to look at an automated solution and if you start to research that you end up moving to The choice of CAs in most large companies is historc - remember all the marketing from Versign in the past and it was aimed at business people not techies. This change will allow the techies to put forward alternatives.

          1. JohnFen

            Re: It's optional

            > If you have to keep updating your certs you are more likely to look at an automated solution and if you start to research that you end up moving to

            Not everyone. LE's automation is not well-suited to my use. What I'm more likely to do is wait until someone else can support (or provide) automation that works for me, and go with them.

    3. FordPrefect

      Re: It's optional

      Which is fine if you don't want customers who have ipads and iphones to access your content. Even people with macs would have to download an alternate browser or be continually pestered about insecure web pages. Not a great look for your company. Granted its good practice to regularly replace your certs but its a bit more of a pain if you are intercepting TLS on a load balancer/firewall/IPS or similar as they don't all support automatic certificate re-enrolment. Even if they do, you don't necessarily want to hand over your CA credentials to another organisation that is running your network/security devices if you aren't running them in house.

      1. Michael Wojcik Silver badge

        Re: It's optional

        Which is fine if you don't want customers who have ipads and iphones to access your content.

        Eh, I'm OK with that.

    4. JohnFen

      Re: It's optional

      Indeed! I may simply ignore the new Safari restriction altogether, since I have a low percentage of Safari users. I haven't decided yet.

    5. MidgetOfDoom

      Re: It's optional

      A problem that comes up is corporations and iDevices. Unless they limit it to just safari. ActiveSync will potentially be an issue.

  5. Anonymous Coward
    Anonymous Coward

    I've got some cheese in my fridge, it went off about a years ago and you aren't protected anymore but please feel free to consume it. I had an apple in there once, big mistake, the door wouldn't shut so they took away the hinges and the shelf life of everything in there just died.

    1. Michael Strorm

      That's nice, but what does it have to do with the price of eggs?

      1. Anonymous Coward
        Anonymous Coward

        I think it's a comment on the shelf life of certificates being too long, so fresher cerficates are better.

        Either that, or £1.50

  6. -v(o.o)v-

    I for one do NOT see this as being reasonable.

    I have hundreds of certificates on different embedded-like endpoints. They get certificates with very long lifetime from the internal PKI. They are (currently) secure and changing them cannot be automated.

    If other browser makers follow suit I'm forced to just start living with certificate errors - there's no way these will be changed yearly.

    It seems idiotic, the browser could test if the certificate is weak instead of just blindly warning on lifetime!

    1. Danny 14

      This is what I was thinking. We run internal long life certs for all sorts of internal things. My solution will be replace the ipads with android. Sure google may follow suite but its cheaper for me to scrap the ipads than replace the system. That also being said, those ipads are airgapped anyway so wont get the update.

      1. JohnFen

        Why not run your own CA to sign your internal certs? This is what I do, and it's very easy.

        1. -v(o.o)v-

          Woosh... Went right over you right?

          1. JohnFen

            Yes, apparently so!

      2. This post has been deleted by its author

    2. Mike 137 Silver badge

      "I for one do NOT see this as being reasonable"

      I entirely agree. All this "enforced security" by browser vendors has done so far is to spawn a massive increase in use of unverifiable cheap self-signed certificates that consequently validate nothing. I strongly suspect that it's primarily another attempt at enforced churn rather than a genuine concern for our security.

      1. Cuddles Silver badge

        Re: "I for one do NOT see this as being reasonable"

        "I strongly suspect that it's primarily another attempt at enforced churn rather than a genuine concern for our security."

        It's the same as requiring passwords to be changed regularly, while also having rules that prevent strong passwords. It's more important to be seen to be doing something than it is to actually be secure.

    3. Charlie Clark Silver badge

      It seems idiotic, the browser could test if the certificate is weak instead of just blindly warning on lifetime!

      It's not whether they're weak but whether they've been compromised. Not sure what kind of leeway they allow admins for internal networks but I think there is an underlying problem with not being able to update embedded devices easily, because that makes them potentially the choiciest attack vector.

      1. big_D Silver badge

        And if they've been compromised after 1 week? They are still going to be accepted for the next year or so as valid...

        That is why there are revoke lists, which most of the browsers seem to ignore.

        There are mechanisms in place for this sort of thing, but it is easier to ignore it and push the work on the site administrators.

        1. Charlie Clark Silver badge

          Right, I was also not pretending that the current system is perfect. But if you cannot update certificates on embedded devices, what hope have you re. passwords, software exploits.

        2. Michael Wojcik Silver badge

          Forcing shorter renewal cycles is only useful if the CA verifies the key pair has been changed, too. And that the customer isn't just cycling between a couple of key pairs, and so on.

          The PKIX revocation mechanisms (CRLs and OCSP) are hopelessly broken, so that's no help either.

          The fact is PKIX, and X.509 PKIs in general, are a best-effort authentication mechanism, and "best" in this case is not very good. CT has helped somewhat. Google has actually helped somewhat, by using their market position to punish bad CAs. But we're still looking at a system that fails often enough that it's not even particularly remarkable when it does.

          Personally, I'd really like to see Chrome and Firefox hold the line on this one, leaving Apple the odd vendor out. I'm not holding my breath, though.

          1. big_D Silver badge

            CA verifies the key pair has been changed, too. And that the customer isn't just cycling between a couple of key pairs, and so on.

            That is all in place now and well defined by RFCs. Just it is too much like hard work, so most browsers just ignore the process completely, pushing responsibility on the end user to manually double check the certificates haven't expired (ain't gonna happen).

    4. Nate Amsden Silver badge

      One can perhaps "hope" it is a certificate error. Having gone through a similar thing with chrome recently where it refuses to use certs beyond 897 days i think it is, it's not a simple error. it cannot be bypassed by the user(unlike say a self signed cert). Which is even more madening. There at least should be means to disable this check for internal CAs. Some flag in the CA cert itself or something. I'm less upset about commercial internet certs of which I manage about 100.

    5. Richard 31
      Paris Hilton


      If you have an internal PKI you probably have control over the full creation of the certs. Just set them all to have a start date of 31 Aug 2020 or whenever and extend the end whenever. Or just make them expire in 2099 or whenever.

  7. cjcox

    And if you run your own CA? Tough rocks I suppose. Apple === clueless about computing.

  8. A Non e-mouse Silver badge

    Commercial Products

    The problem with this is going to be the commerical products/appliances which use SSL certificates. Many of these don't support Let's Encrypt and the steps for replacing certificates are very manual with no way to automate.

    I foresee a world of pain for administrators.

    1. Adam JC

      Re: Commercial Products

      Who knows.. maybe it'll force a lot of software dev's to implement support for LetsEncrypt? There may even be some benefit to come out of all this bollocks.

      1. John Sager

        Re: Commercial Products

        Ok, LE does a good job, but if everyone uses it it's a single point of failure.

      2. LDS Silver badge

        "to implement support for LetsEncrypt?"

        It requires internet access - and there are many good reasons for devices not accessing the internet and having certificates issued by a local CA.

      3. big_D Silver badge

        Re: Commercial Products

        How can you implement Let's Encrypt for a device which isn't visible from the Internet?

        1. Dr. Mouse

          Re: Commercial Products

          Isn't visible from the internet: Use DNS-based challenge

          Cannot connect to the internet: have fun...

        2. This post has been deleted by its author

          1. big_D Silver badge

            Re: Commercial Products

            We are talking switches, routers, internal-only firewalls, ICS devices etc.

    2. DuncanLarge

      Re: Commercial Products

      TBH those have been an issue for a long time before this. I have a HMC for our AS400 that rarely need to be accessed. When it is however its a right PITA to connect to. It supports HTTPS but a version that chrome and firefox refuse to connect to. So, I should use IE?? Nope, even IE says NO WAY!. Only Edge works funnily enough. Then the actual login process and interface that is loaded is not HTML with CSS, but Java. So I have to convince the browsers to load Java 8 and run the thing which requires me to add exceptions to Java also because the Java being loaded isnt signed.

      Its a right PITA to do on a saturday morning over a VPN and all you want to to is reboot the AS400 into a restricted state so you can manually initiate a full system save to tape. And all of this can be avoided by connecting to the HMC using the AS400 terminal client but IBM's new terminal client, that is Java based, does not support HMC's yet so you have to use the older System Navigator client which would work just fine if only the new VPN that you were asked to test was not blocking the ports.

  9. Robert Grant Silver badge

    Super slowmo

    Apple clearly wants to avoid an ecosystem that cannot quickly respond to major certificate-related threats

    Not that clear - if there's a major certificate-based threat then 1 year is absurdly long.

    1. brotherelf

      Re: Super slowmo

      >> Apple clearly wants to avoid an ecosystem that cannot quickly respond to major certificate-related threats

      > Not that clear - if there's a major certificate-based threat then 1 year is absurdly long.

      They have a point, in a very roundabout way – remember the joke about the clock flashing on your microwave because you just can't be arsed to read up how to set it and you forgot from the last time around and you think it's really not that important? That's what certificate hygiene is. Wait till it fails, tell the customer to click ok, find out the guy who did it the last time retired, and then find out how to do it yourself, and forget until next time. Until it's frequent enough for you to actually learn (or automate away).

      1. Robert Grant Silver badge

        Re: Super slowmo

        It might fix that (although stuff like LetsEncrypt is what will actually fix it), but that's not exactly a major certificate-related threat. More of an internal company process thing, which I doubt Apple cares about in the slightest.

        1. big_D Silver badge

          Re: Super slowmo

          Except Let's Encrypt can't see isolated devices behind a firewall to issue the certificates.

      2. big_D Silver badge

        Re: Super slowmo

        Most of our kit can't be automated. We have to manually issue certificates from our cert server and manually install them.

    2. big_D Silver badge

      Re: Super slowmo

      Exactly. Or you could just revoke the certificate(s), but the browsers ignore revoked lists.

      1. Orv

        Re: Super slowmo

        Revoked lists have their own issues. The server with the revocation list becomes a single point of failure. If it's down, do you block *all* https access until it comes back up? If not, DNS spoofing can override the whole system.

    3. Terje

      Re: Super slowmo

      Last time I checked certificates can be revoked and as such should throw a warning if they are known to be compromised. And the required time for a CA to revoke a compromised certificate is waaaay shorter then one year. To me this smells like yet another poorly thought out idea that apple will try to force down everyones throat.

      1. Michael Wojcik Silver badge

        Re: Super slowmo

        Revocation is broken.

        Revocation only helps if the CA enforces a new key pair for the new certificate. Considering how many CAs can get other basic requirements right, I'm not going to bet on all of them managing this one, either.

        CRLs are a delayed mechanism, and they expire, which when combined with timestamped signatures make CRLs largely useless for some purposes (e.g. code signing). CRLs require the user agent (or whatever in the stack is responsible for fetching CRLs) periodically contact the CA to get the current list or a delta; that process is fragile. CRLs can be attacked out-of-band as part of an exploit chain.

        OCSP is fundamentally broken - it fails unsafe. So an active attacker who can interfere with OCSP traffic can nullify it. OCSP adds significant latency, which makes client developers and users reluctant to enable it.

  10. This post has been deleted by its author

  11. AlexV

    What's the benefit?

    I'm really unsure as to what the point of this is. If you have a 1 year cert, and it's stolen or compromised or something in such a way that it can't be immediately revoked or fixed, then that's on average around 6 months worth of un-fixable vulnerability. Which, you would think, would be plenty. It doesn't really matter whether the vulnerability would stick around for another 12 months after the initial 6 or not, if it isn't fixed within days then it's already too late.

    If you do have a mechanism which can immediately revoke or fix the problematic certificate, then it *also* doesn't matter if it was a 1 year or a 100 year certificate, it's dead now and no longer a problem.

    1. DuncanLarge

      Re: What's the benefit?

      They would have to steal your hopfully protected private key...

      Or steal a CA signing cert. And if that happens, there are bigger problems.

      1. brotherelf

        Re: What's the benefit?

        > They would have to steal your hopfully protected private key...

        Well yes. The certificate is public anyway, the common parlance of "compromised certificate" can be a bit misleading there. (And no, a new certificate does not mean it must be a new private key.)

        The extent to which you can protect the private key can be limited on servers you want to restart without human interaction.

  12. Dwarf

    There is a way around compromised certificates

    It’s called a certificate revocation list (CRL) and it works just fine.

    Just use the technology that already exists to handle this and stop screwing around with the internet.

    If you think you can do it better, then submit an RFC and allow it to be reviewed and discussed by others that understand this. Then, and only then implement the change.

    I agree with other posters that there are a good chunk of device that will struggle to get certs updated frequently.

    Even many large corporates struggle to get certs renewed properly and in time.

    1. DuncanLarge

      Re: There is a way around compromised certificates

      > It’s called a certificate revocation list (CRL) and it works just fine.

      Unless you are using Chrome, which ignores certificate revocation instead relying on a built in list. Everyone else uses a standard method of checking for revocation but chrome removed support.

      So if you dont (or cant) update chrome, youre stuffed.

      1. big_D Silver badge

        Re: There is a way around compromised certificates

        Then don't use Chrome, because it isn't safe...

        CRLs are there for a reasons, use them! It's not rocket science. But these companies can't be bothered doing it the standards compliant way, so everybody else has to suffer.

        1. DuncanLarge

          Re: There is a way around compromised certificates

          I dont use chrome

    2. Nate Amsden Silver badge

      Re: There is a way around compromised certificates

      Not even 1 month ago

    3. Michael Wojcik Silver badge

      Re: There is a way around compromised certificates

      It’s called a certificate revocation list (CRL) and it works just fine.

      For exceedingly small values of "just fine", yes.

  13. Anonymous Coward
    Anonymous Coward

    Apple forgets that a lot of B2B communication happens using certificates, if CAs follow suit and just start to only allow 12 month certificates that doubles the yearly certificate chance burden and increases the risk of breaking important B2B comms in critical industries. The issue that others highlight about networking devices is also a valid potential issue but only if other browser makers follow suit, I don’t know anyone that really uses safari in production for accessing networking devices.

  14. DuncanLarge


    Who the hell uses Safari? The internet explorer of apple products?

    I doubt anyone will care to renew their certs this frequently till Google and Firefox join in. Users who complain that Safari is popping up warnings will be told:

    "Our website is secure and designed to work with modern browsers like Chrome, Firefox and Edge. Sorry to inform you that we do not specifically support Safari".

    1. IGotOut Silver badge

      Re: Okay

      Who uses Safari?

      Several hundred million people I should think.

    2. The First Dave

      Re: Okay

      In a related question, how many people use an iPhone regularly?

    3. Carpet Deal 'em

      Re: Okay

      Anybody who uses any web browser on an iPhone uses Safari. All the others on the appstore are just skins since Apple won't allow anything more.

      1. Ken Hagan Gold badge

        Re: Okay

        ...which is a reason not to use an iPhone. Maybe not a clincher but certainly a mark against Apple. Once you've factored in the price, you might reckon you are better off with the Swiss cheese of Android.

        1. Anonymous Coward
          Anonymous Coward

          Re: Okay

          Android is even worse than Swiss cheese with holes: it also has maggots which live in the holes and who are watching and listening to everything you do online...

  15. DrXym Silver badge


    Why does it matter if a cert expires 100 years into the future? Does it compromise the validity or security of the cert with a spiffy hash, key length and signature chain today??? Of course not.

    Since certs have a start and end date it would make more sense to look at how *old* the cert is (ie. now - start date) in combination with the key length, hash and other particulars to determine whether to accept it. For example a 5 year old cert using SHA-2 256 might be considered fine but not if its using SHA-1 since the viability of collisions.

    But that more depends on the key length and hash being obsolete and honestly, even if the key were brand new but deficient it should be rejected any way. In other words I don't see cert age even being a cause for concern.

    1. DuncanLarge

      Re: Ludicrous

      Totally agree. If you want to keep the pool of certs out there strong detect the ones that are weak and target those.

      Whats next? "Oh this wikipedia page about glass blowing has not been updated in over a year, thus all the information about an activity that is as old as the hills is now out of date?"


      "That program that was written in the 80's with the last update in the late 90's is too old to be used. Even though its well documented, does not do anything that needs modern encryption (lets say its a compressor like gzip, not saying gzip is unmaintained lol). Even though the source is available and it runs just fine on our system even without recompiling its too old. The bits must have rusted and the bytes values have changed over time that will probably cause errors in DRAM."

      "Wait what? you're running it on a system that uses DDR3? My god man, DDR4 is out, DDR3 is a terrible ancient danger to life now that its several years out of date!"

  16. hammarbtyp

    Just as well we don't use Safari for industrial control devices.

    Normally these are local access, do not have remote access and are only updated on long term maintenance contracts (5 year usually)

    Often certificates are given 20 years lifetimes because a safety critical system should not go down because a certificate has not been updated in the last year.

    Biggest worry would be if Chrome etc follow suit

    1. DuncanLarge

      > maintenance contracts

      You get an upvite for having maintenance contracts .

      I work in a brewery and the number of times the production teams have asked IT for help only for us to ask normal questions like "who has the maintenance contract" and "when was the last update" and "what company provided this"? Only to be given confused shrugs to the first two questions and the third question is answered by a long waffle on about some now long defunct company that was based in the next town where there now are bulldozers reclaiming a brownfield site.

      And when the company still does exist in the next town over, offers a more upto date and totally "drop in replacement" product that will replace the 20-30 year old version with little to no operational changes other than offering support for USB printers and PC control along with all the features the 20 year old unit offered via its buttons and LCD screen you get told: "its too expensive!" and you reply "but this unit blew up after 20 years of not being serviced, £3000 for a fully compatible direct replacement from the same company seems a good investment for the next 20 years" and they replay "we are taking this to the top! Bloody IT!"

      That actually happened.

  17. msknight

    Office 365 is 2 years

    That'll cause a nice piece of trouble.

    1. Matthew 3

      Re: Office 365 is 2 years

      Fortunately it was renewed last September, so it'll be Sep 2021 before it's an issue, if I understand correctly what is being said here about existing before-the-deadline certs..

  18. big_D Silver badge


    You can revoke certificates that are no longer required, have been technologically supeceded or have escaped into the open... But, wait, Google and Apple ignore the revoked lists, so it is up to the site owners to not only revoke certificates, which is essentially pointless these days, but to renew their certificates twice as often as they used to, because the devs are lazy.

    I hope that the one year certificates only cost half as much, or can we provide Apple with a bill for the extra cost of the certificates, plus the increased labour in having to replace the certs twice as often?

    What with Google and Firefox ignoring extended validation - something every critical site, like banking, cloud services etc. should have - and Apple reducing the life expectancy of certificates, they are making a mockery of the whole idea of secure sites. Why don't we do away with "proper" certificates altogether and just use Let's Encrypt, which requires no validation, other than you have access to the website...

  19. Jean Le PHARMACIEN

    Thanks Apple for that

    My home camera system requires a browser which will ignore local unsafe connections (i.e. my home network) to use control panel. Alternative is build/use my own private certs (to avoid all the red "Danger" flags/pop-ups). Clearly LE is a bit ott for local network and it's a PITA doing own certs but worth it if you can create long lived private ones

    This just kills value of self signing for local network use. All I need now is for Chrome based browsers to withdraw the local_unsafe_sites flag (or whatever correct name is).

  20. Anonymous Coward
    Anonymous Coward

    'or risk breaking pages on a billion-plus devices and computers'

    To be fair, a substantial chunk of those users will be using another browser, so probably not thatbig an impact.

  21. bobdylan123

    But most browsers have a more rigid CA system now. e.g. look at the fallout from the google cert error with diginotar

    There's not a valid reason for this expiry - provided the list of CA's are appropriately secured and the mechanisms are robust. If either of these aren't true, then the expiry limit being 1 day or 1000 days will make no difference.

  22. Mage

    Taking lessons in arrogance from Google?

    ^^^ See title.

    1. JohnFen

      Re: Taking lessons in arrogance from Google?

      Apple has been like this from before Google was a thing.

  23. Richard Lloyd

    Dubious change...

    Let's Encrypt certs and their 90 day expiry work well because you are effectively forced to automate the renewals (and preferably have some of your own expiry date monitoring in place in case things go wrong, though LE will e-mail with decent number of days to go to the cert expiry). Once you have automation in place, the ongoing cost in terms of admin and the certs themselves is effectively zero.

    Paid certs, however, are the complete opposite. They are often a horrendously bureaucratic manual process that can get held up if the cert provider decides to do a "manual security review" (i.e. actually involve a human at their end in the process). I've often been forced to go onto their live chat and beg for expediting of a reviewed cert - if i don't do that, it can sit in limbo for *days*. Having a manual process get cut ever-shorter (used to be 5 years max, then 3, now 2 - with Apple changing this to 13 months) means that the admin cost per year rises - and it's individuals/companies that will have to absorb that, not Apple.

    I knew that they'd claim that possible changes in ciphers/protocols would be their official excuse for this reduction in the maximum cert life, but what is the average time between the introduction of a new cipher/protocol? Wikipedia says: SHA-0 = 1993, SHA-1 = 1995, SHA-2 = 2001, SHA-3 = 2015, so how does Apple justify less than 2 years for the max cert life? You wonder if the next step is for Apple to set itself up as a certificate authority and rake even more cash in (with certs <=13 months lifetime of course).

  24. Packet

    I can appreciate the security aspect, but...

    Things have dependencies - be they software or hardware.

    And upgrading them costs time and money - sometimes rendering such a mandated cert upgrade unfeasible.

    Case in point, a couple of years ago, client was running older version of Oracle Application Server that could not take the new 2048 bit certs.

    Had to stick the afore-mentioned HAProxy in front to do a front-end 'new' cert and then pass traffic to the old ora servers.

    Upgrade everything and make it work? In a perfect world, absolutely.

    Everywhere else - find kludges and tricks.

    1. Rockets

      Re: I can appreciate the security aspect, but...

      Been there, done that and have the t-shirt too for the a Oracle application server. The Base OS version OEL openssl didn't support TLS1.2, the app server wasn't officially supported on the next OEL version that did support support TLS1.2. A newer version of the application server wasn't compatible with another application server that was part of our suite. Ah the delights that is Oracle E-Business suite with various bolt on products and customisations of the core ERP product.

  25. Anonymous Coward
    Anonymous Coward


    Considering how often Microsoft screws up their certs, I can see this move by Apple bringing us years of chuckles (or sighs) as the MS minions screw up their annual cert renewals.

  26. Version 1.0 Silver badge

    And tomorrows hack will be?

    Our web site host recently switched to LE and renewed all of our website certificates without even once asking for a verification - absolutely nothing so I do not trust LE at all. Sure the certificate may be good but who actually owns it? There's no way to know.

    This change simply swaps one problem for another.

    1. heyrick Silver badge

      Re: And tomorrows hack will be?

      "Sure the certificate may be good but who actually owns it? There's no way to know."

      Probably a fallout from the over paranoid "everybody needs https right now" attitude from the likes of Google, meaning that sites that serve mostly static data and don't collect user information will be penalised for not being https when they don't really need to be.

      And yes, I know the man in the middle issue. However if somebody or something is MITMing your connection, you have bigger problems to worry about.

      So I use LE. My site is https. It just "gets on with it" automatically in the background and Google's bullying antics can fuck right off.

    2. heyrick Silver badge

      Re: And tomorrows hack will be?

      Thinking about it more... Back in the early days, encrypted sites were shown with a green background or a blue one (I think MSIE 6 or something?) because there were two classes of certificate. Anybody ordinary, and verified establishments (banks and the like).

      Is it not still like this? I wouldn't be too worried about an unverified certificate on somebody's blog (thinking they probably have it for much the same reason as I do), but there's no way in hell I'd want to see that on a bank or government agency or any company that expects me to hand over personal data.

    3. Orv

      Re: And tomorrows hack will be?

      LE's checks are mostly just about whether the person requesting the certificate also controls the server (and thus the DNS.) It's not great, but it's equivalent to other budget certs I've gotten. I think in the early days I had to submit a photo of my driver's license, but realistically what's that going to prove? That I could come up with a plausible-looking image of a driver's license?

      "Who owns it" is what EV certs were supposed to prove, but it turns out that it's hard to determine if the "Foobar, Inc." asking for the cert is the well-known "Foobar, Inc." or some other corporation that happens to have the same name in a different state.

  27. heyrick Silver badge

    or risk breaking pages on a billion-plus devices

    In my experience, plenty of things upset/crash/mess up on Safari (on iOS), so this won't exactly be anything new...

  28. Rombizio

    Looks like Apple is buying GoDaddy...

    ....that would be my guess.

  29. Tom Paine

    I'm not sure there's enough popcorn in the world...

  30. John Savard

    Captive Audience

    And, of course, on an iPhone or iPad, you can't simply load another browser that conforms to Internet standards. But you should be able to still do so on a Macintosh, unless there's something I've missed.

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