back to article Web body mulls halving HTTPS cert lifetimes. That screaming in the distance is HTTPS cert sellers fearing orgs will bail for Let's Encrypt

CA/Browser Forum – an industry body of web browser makers, software developers, and security certificate issuers – is considering slashing the lifetime of HTTPS certs from 27 months to 13 months. The plan, floated at a meeting by Googler Ryan Sleevi earlier this year and still in its draft stages, comes just one year after the …

  1. highdiver_2000

    When the cert expires, I renew it, insert new cert into the web server, close the case. What does this have to do with SSL encryption?

    1. brotherelf
      Boffin

      Nothing indeed. It's not even necessarily a key change (though I can see LE starting to refuse issuing certificates to keys they've seen before, because will nobody think of the children), and it sure as hell doesn't fix any key exfiltration vulns either.

    2. Twanky Bronze badge

      erm. Aren't you supposed to renew/replace _before_ the old cert expires?

    3. Crypto Monad

      > What does this have to do with SSL encryption?

      It's more about SSL authentication. For example, remember when MD5 was broken: people were still issuing MD5-signed certs for a while after that, and then if the final signed cert had a 3-year lifetime, you had to trust MD5 signatures for another 3 years too.

    4. The Man Who Fell To Earth
      FAIL

      Follow the money

      Requiring people to renew twice as often is all about squeezing more money out of them. Nothing more. Look boss, I doubled revenue. You can give me my bonus now.

      1. Drew Scriver

        Re: Follow the money

        Show me a company that actually revokes certs when they're supposed to and I'll buy your argument.

        PCI-DSS requires revocation every time someone who had access to the private key leaves or even changes roles. I've seen only one place where that happened in my entire career.

        Shorter lifespan is better. Three months should be the limit (same as passwords under PCI-DSS).

        For all those who complain, it's 2019. Automate already.

        1. The First Dave Silver badge

          Re: Follow the money

          "it's 2019. Automate already."

          Quite apart from the technical difficulties with automatically renewing certificates for absolutely anything _other_ than a Linux/Unix box, how will that help if the cyphers etc are changing as frequently as the exercise suggests? You're going to have to update your update script every six months.

          1. Mr Humbug

            Re: Follow the money

            I've found that

            https://certifytheweb.com/

            works well on Windows servers. I've only use dthe free version because my servers don't run many sites, but it will even automatically renew and deploy a certificate on an Exchange Server.

            1. The Original Steve

              Re: Follow the money

              Whilst these tools are good for the most common use case scenarios, there's often very many other scenarios that aren't covered. And if I need to remember to do my Exchange, Skype for Business, IIS servers with multiple and complex cert bindings and other servers, the piss easy vanilla IIS boxes are hardly any bother to add to the list.

              Tools to renew certs are all well and good, but generally they only renew the cert in the OS cert store and maybe IIS binding too. They are the vanilla and super easy ones.

              Not forgetting certs that aren't issued by public CA's and devices that don't use Linux and Windows such as iLO/iDRAC, routers/firewalls etc.

              When I was the Infrastructure Architect at a MSP a year or so back where everything was Windows based for our clients (at least that was critical in terms of certs) I ensured that we raised an automated alert when a cert on a box has less than 2 weeks left before it expires.

              Helped prevent certs expiring and also caught the lazy engineers who never deleted the expired one post-renewal too.

              1. eldakka Silver badge

                Re: Follow the money

                Not forgetting certs that aren't issued by public CA's...
                What is proposed is, I believe, a policy change to be followed by CAs on the issuance of certificates, not a change to the X.509 standard itself on what is a valid time to put in the notAfter field.

                If it's a cert not issued by a public CA, you can put whatever expiry you want on it, e.g. 10 years for an internal RnD box that you are only putting certs on so that its configuration is the same as production. RFC5280, S4.1.2.5 :

                To indicate that a certificate has no well-defined expiration date, the notAfter SHOULD be assigned the GeneralizedTime value of 99993121235959Z.
                which equates to 31 December 9999.

                1. e^iπ+1=0

                  equates to 31 December 9999

                  Follow the money ... Y10k bug ftw.

                  1. Michael Wojcik Silver badge

                    Re: equates to 31 December 9999

                    Feature. If we're still using ASN.1 in 9999 we don't deserve TLS.

          2. Loud Speaker

            Re: Follow the money

            If you are not using Linux/Unix for your server, they your probably too late for security anyway. (Apple is Unix).

        2. fwthinks

          Re: Follow the money

          Automation does not solve all the issues - you just move control of the certs from a person to a scheduled task but this process needs permissions to manage your certs and for example perform the LetEncypt challenge.

          I am not saying it cannot be secured, but about understanding whether new risks are being created or existing risks being moved to another part of the process. So moving to a 3 month renewal could increase risks if you are not careful.

        3. LeahroyNake Silver badge

          Re: Follow the money

          I'm all for let's encrypt and use it for a few Linux boxes, it works great.

          Has anyone here managed to get it working with IIS , Exchange or RDP gateway... Then automated it?

          1. Mr Humbug

            Re: Follow the money

            https://certifytheweb.com/

            See above :) (you posted while I was writing)

          2. maffski

            Re: Follow the money

            I've just installed Windows ACME Simple (WACS):

            https://github.com/PKISharp/win-acme

            Worked perfectly with IIS. Haven't tried with exchange etc.

          3. Donn Bly

            Re: Has anyone here managed to get it working with IIS

            I use WACS and it works great for IIS bound sites.

            Over the last year I have converted most of my wildcard certificates to lets-encrypt single hostname certificates, and while most of my stuff is linux based (and was thus painless to implement) that also included having to deal with a couple of IIS servers. Win-Acme works great, just remember to copy it to a folder you can secure before you start evaluating it because it is a real pain to move afterwards.

            Getting it to work for my windows-based SVN server, however, was a bit of a challenge. Ended up with a batch file that runs every week to export the current website certificate into a x509 certificate (using openssl), merge with the key and CA bundle, then compare the result to the file currently in use by Visual SVN. If they don't match, shut down SVN, replace the certificate file, and restart the svn and tomcat services.

            All because there is a website and an SVN server with the same name (just different ports) on the same server and I couldn't get WACS to put the same certificate in multiple places in multiple formats.

    5. Anonymous Coward
      Anonymous Coward

      Some of us have scores of certificates on many different pieces of equipment performing different essential functions, running different operating systems, and having different update methods... not one cert on one web server.

      Having to replace them twice as often would be a major waste of our time and effort. And yes, some of them are primarily used for encryption.

      1. Tikimon Silver badge
        Facepalm

        Let's force frequent password changes too!

        Those who ignore history are DOOMED to repeat it, and be nastily mocked like their idiot predecessors.

        1. fidodogbreath Silver badge
          Devil

          Re: Let's force frequent password changes too!

          "Welcome to Hell. Your https certs expire every 13 months, your cert authority account password expires every 5 months, and your passwords for all 600 servers that you need to update expire every 90 days. Password managers are not allowed, because it's Hell."

      2. Drew Scriver

        I'm quite troubled by the emerging themes here: too much work and not worth the trouble.

        I'm a network/app delivery engineer at a company that runs tens of thousands of servers/instances/containers/network boxes etc. I've been a developer for years, and after that a hosting engineer.

        To cut to the chase: the core question is whether adequate security is a requirement, and if so, what constitutes adequate security.

        I realize that it can be a lot of work, but that shouldn't be the main criterion. And, I dare say, at many companies it's more work than it should be simply because of poor design, architecture, and standards.

        And lack of executive support for it.

        I'll step off my soap box now before I fall off and get hurt.

  2. mbdrake

    Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

    Given the many different types of SSL/TLS certificates out there (as well as their different verification methods) alongside the multitude of devices which take SSL/TLS certs - automation of renewals is going to vary considerably. I think maybe a better approach might be to invest a bit more in the whole certificate transparency/logging system alongside the certificate authority authorisation DNS record to state which CAs can issue certificates for domains.

    1. brotherelf
      Boffin

      Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

      I'll grant them this: CAA is a time-of-issue check done by good-faith actors (with working software – not everybody's is). Once the certificate has been issued by whoever, CAA doesn't mean anything.

      And CT is along the same lines: a public time-of-issue message published by good-faith actors. Yes, doing that might be a pre-requisite for getting into root certificate stores. Do we have technical certitude that $bigCA does not have mechanisms to bypass CT, if a three-letter agency with signed warrants compels them? No. (It would be in their own interest, though, to make it technically impossible.)

      The thing you are looking for is the now-defunct (Chrome dropped support, Edge did not get support so far) HPKP HTTP public key pinning, which did not take off, because it actually forces you to think about what you're doing for two minutes, or otherwise your website will be unreachable for long timeframes if you are unprepared for a key change. (Also, technically it had a TOFU risk.) The hordes of "I click deploy on cloud" have overrun the greybeards.

    2. DrXym Silver badge

      Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

      Or just allow websites to use self-signed or peer signed certs providing they're registered with SSL observatory first. Browsers that encounter a self-signed cert could look it up on the observatory and present the user with a one-time informational checklist of the site's security (yes it encrypts, yes it has been registered, no it hasn't been issued by a CA) without scaring them off.

      1. John Robson Silver badge

        Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

        Or just allow the site to host the public key in their DNS...

        DNSSEC validation of the key required for SSL transactions with the same organisation...

      2. iron Silver badge

        Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

        Because your gran is going to love and understand that checklist and make an informed choice. Oh yes.

        1. mbdrake

          Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

          I was thinking backend rather than frontend - and yeah, users don't care about the backend. But the point of view from site administrators, you want to do your best to reassure users that you give some kind of damn about the transmission of data.

          But I can't think of an easier way of saying to a user "this site is slightly more trustworthy than a non-secure site because it has an SSL/TLS certificate, but the person or organisation behind this site could be as dogdy as hell" if Google keeps changing the display of URLs in the address bar, or removing the likes of the EV status from immediate view. I'd rather still have that info at a glance than hiding it. Clickers are going to click.

        2. DrXym Silver badge

          Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

          Do you think your hypothetical gran understands why a website that has no encryption is waved through by the browser as fine but one which has a cert registered with SSL observatory is somehow worse?

          Do you think your gran remotely understands the existing way browsers present certifcate information?

          Do you think your gran understands what a CA is or why most browsers have HUNDREDS of CAs that they implicitly trust?

          Please understand the point here. A self signed cert provides encryption and is still better than plaintext. But browsers frighten people about them. Why not allow them with a one-time consent if they're registered with SSL observatory.

          Presenting this information to a user in a reasonable way is not insurmountable.

      3. Orv Silver badge

        Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

        How is this any more effective than a CA? It seems like the observatory has exactly the same trust issues a CA does, you're just shifting who happens to be doing the computations to create the cert.

  3. Justin Case
    Windows

    False sense of security

    The greatest and most secure means of transmitting credit card numbers counts for nought if the storage and handling of said details is lacking.

    1. I ain't Spartacus Gold badge
      Happy

      Re: False sense of security

      I send my credit card by carrier pigeon - it's far more secure. I'm only vulnerable to criminals with falconry skills, and there are far fewer of them than script-kiddies.

      1. Alister Silver badge

        Re: False sense of security

        I'm only vulnerable to criminals with falconry skills,

        and also cats... That's not criminals with cats, you understand, just cats...

      2. hammarbtyp Silver badge

        Re: False sense of security

        and air-rifles

        1. pstiles

          Re: False sense of security

          Cats with Air Rifles?

          Now i'm worried.

          Yrs Sncrly,

          Budgie

          1. Zippy´s Sausage Factory

            Re: False sense of security

            That's nothing. In head, there's a cat with an air rifle and a falcon balancing on its other paw.

            I really need to get out more.

            1. The First Dave Silver badge

              Re: False sense of security

              If the cat is holding the rifle with only one paw, then you are fine - they can only shoot straight when they use at least two.

              1. Nifty

                Re: False sense of security

                Nah. it's a blunderbuss

                1. David 132 Silver badge
                  Thumb Up

                  Re: False sense of security

                  Blunderpuss, shurely.

          2. TomPhan

            Re: False sense of security

            The Oatmeal has an appropriate print - https://shop.theoatmeal.com/products/gatling-kitty-signed-print

      3. eldakka Silver badge

        Re: False sense of security

        I'm only vulnerable to criminals with falconry skills...
        Or shotguns, or falcons of the opposite sex (well, it might delay them at least), or eagles (there's always someone bigger/faster/stronger), or Wind Turbines (splat), or air ones (jet engines/planes) for that matter, although in the latter case there probably won't be anything left to extract the CC from, so I guess you could call that safe ;)

  4. Pascal Monett Silver badge

    Money spinner

    The use of that term indicates to me that security is not the primary goal of all this hoopla. Indeed, if it's security that is the issue, then I think LetsEncrypt is doing it right : you got a cert valid for 90 days that can autorenew for free.

    If LetsEncrypt can do that, then why can't DigiCert and the rest of them ? Because they're in it for the money, security is just the cow they milk.

    So here's your solution, DigiCert : go for 90 days auto-renewable, and turn your hefty fee into a yearly subscription without changing the cost to companies. You get your money, web sites get their certs, companies do not pay more, everyone is happy.

    Except your Board, of course, who would have wanted to charge the yearly subscription to the 90-day charge, but you can go screw yourselves.

    1. LDS Silver badge

      I still wait for Let's Authenticate...

      I'm really tired to read certs are for encryption. That's only half of their role. The other half is authentication. And when you can't trust a certificate owner, encryption too becomes quite useless.

      Everybody is dumbing down certificates. Both those who made a business of selling certs to everybody for money without any vetting, and those so obsessed by 'government control' that are just helping it with certificates issued with almost no oversight.

      Soon HTTS will be no safer than plain HTTP - you won't be able to trust any certificate. and soon I bet someone will start to sell some reputation service inside its browser....

      1. John Robson Silver badge

        Re: I still wait for Let's Authenticate...

        In the sense that you know you are talking to the owner of that cert it will always be safer.

        In terms of knowing who own that cert, you are right... But that's where publishing the public key by another mechanism (And Let's Authenticate seems a good enough name to me) comes in.

        HTTP - you don't know who you are talking to.

        1. Charles 9 Silver badge

          Re: I still wait for Let's Authenticate...

          "In the sense that you know you are talking to the owner of that cert it will always be safer."

          Not necessarily. What if the cert was stolen...or made using a stolen identity? Sure, the cert says it was issued to X, but how can you be sure X is X, just as how can you be sure Bob is really Bob and not Eve, Mallory, or Gene who took on Bob's identity?

          1. John Robson Silver badge

            Re: I still wait for Let's Authenticate...

            If you are assuming that people are using stolen certs then there is no authentication either.

            The whole point is that the cert is considered sacrosanct, and it's secrecy protected at all costs - including nuking it (revoking it) if you suspect it has been compromised.

            That's why short cert lifetimes are kinda-sorta useful. they force a refresh which should help in the case of an unknown theft (although of course the key under the doormat will likely still be there)

            If it was made using a stolen identity then I'm still talking to the owner of the cert, even if they are lying about who they are. That's a different problem, and not one that the multiplicity of certificate authorities mitigates at all - in fact it makes it worse...

            DNS based key distribution, with DNSSEC all the way up to the root at least gives you just one or two certs to trust implicitly (those at the DNS root) rather than the hundreds which are installed into every browser/OS by default.

            I pretty much trust the admins of the root domain to do their jobs properly... DNSSEC key management is not difficult, so I can trust each stage - since the private certs are always held by the smaller of the entities we end up with a verifiable chain of trust from the administrators of the web server and DNS systems (yes, they have to talk to each other) to the root cert - which is very well protected indeed.

            We don't need CAs at all any more...

      2. Warm Braw Silver badge

        Re: I still wait for Let's Authenticate...

        The other half is authentication

        In a sense, the only half is authentication - if you can't authenticate, the encryption is useless because you may simply be talking to a MITM or other ne'er-do-well. Unfortunately, certificates are always going to be dumbed down because the trust model requires a manageably-small number of root certificates to be pre-loaded in web browsers and that essentiallly means that either those root authorities are directly issuing certificates to millions of unverifiable entities in far-flung countries or that they're authorising a long chain of unverifiable intermediaries which might or might not end with someone who is sufficiently close to the applicant to be able to verify their legitimacy.

        The price and/or lifetime of the certificates has no bearing on any of this.

        As in so many aspects of computer security, the mathematical proof of correctness depends on a premise that cannot easily be delivered in the real world.

        1. doublelayer Silver badge

          Re: I still wait for Let's Authenticate...

          That's a valid point, but it doesn't really affect the current situation. That is a perfectly valid reason not to allow self-signed certs, but nobody's suggesting that. As long as some degree of authentication is used, certs have a profound benefit to security by providing encryption. Letsencrypt does that; although it's mostly a DNS check to determine that the server in question has access to the domain, that will be enough to prevent MITM attacks. Shorter lifetimes doesn't really impact this either, and comes with some security benefits although those can be overstated.

        2. Michael Wojcik Silver badge

          Re: I still wait for Let's Authenticate...

          In a sense, the only half is authentication - if you can't authenticate, the encryption is useless because you may simply be talking to a MITM or other ne'er-do-well.

          For that matter, now that RSA is deprecated for key exchange by pretty much everyone, and the world is shifting to ECDH and other Kx protocols with forward secrecy, X.509 certificates often don't play any part in encryption regardless. In modern TLS (which is not the only, but by far the most common, use of X.509) certificates are primarily for authentication.

    2. Anonymous Coward
      Anonymous Coward

      Re: Money spinner

      So if I get my hands on a server or other machine that is set up to auto-renew, does that mean it's now my cert?

      And how would anyone else know, especially in a case where the domain name is up for grabs?

      Think about defunct or bankrupt firms... or what you can do with the right burglar.

      1. Orv Silver badge

        Re: Money spinner

        Same's true of most commercial certs; heck, they don't even have to be set to auto-renew for you to get a substantial amount of time (up to two years) to use the cert for whatever you like. When it expires, as long as you can cut them a check you can probably keep going.

      2. doublelayer Silver badge

        Re: Money spinner

        Short answer: not at all.

        Long answer: Not at all, as this is exactly the situation shortened lifetimes is trying to prevent. Well, your first point is. Your second point about a domain having expired isn't at issue, because you are then perfectly within your rights to buy it and get a cert for it, whether your purposes are malicious or not. There's nothing anyone can do about that.

        But back to your first point. Let's postulate two servers, Alice and Bob. Both host an HTTPS server with a certificate. Alice has set hers up using LetsEncrypt or someone else with a 90-day expire time. Bob has set his up with a 39-month cert back when they were still in use. Today, you break into both of them and steal their certificate files. You're planning to impersonate these servers on a compromised connection to get users to trust your fake sites. Having stolen the private keys, there's little you can't do. That's why private keys are protected. But you can only impersonate Alice for at most ninety days unless you can break in again. If Alice improves her security, or if you obtained the file by paying for an attacker to obtain the file for you, it could be much more difficult to get a new one. You couldn't use that cert to renew itself; only the real server can do that because LetsEncrypt uses a DNS check. Meanwhile, you can impersonate Bob for quite a long time. His cert is valid for a little over three years. That gives you a lot more time. If neither fix their security, you have access to impersonate them for as long as it takes them to figure it out. If they do fix their security, Alice is safe much earlier than Bob is, unless they realize that the certs have been compromised, in which case they both revoke them and we're back to the same again.

    3. IGnatius T Foobar !

      Re: Money spinner

      If LetsEncrypt can do that, then why can't DigiCert and the rest of them ? Because they're in it for the money, security is just the cow they milk.

      Actually, the protocol used by LetsEncrypt can be used by DigiCert and the rest of them. It's an open standard and all open source software. There's nothing stopping DigiCert from selling you 5 years of service and then providing unattended, automatic certificate updates every 90 days, using the exact same software.

  5. DrXym Silver badge

    Shakedown time

    CAs are nothing more than a protection racket. I'm sure this has absolutely nothing to do with their profits.

    Services like Let's Encrypt are a blessing but its still an onerous job to make them work. I think most site operators would wish they could have certs that expire after 5 or 10 years.

    1. Twanky Bronze badge
      Pirate

      Re: Shakedown time

      You _can_ have certs which last for 5 or 10 years. Just roll your own CA. The only problem then is getting other people to trust your certs. Those that have some understanding of the issues won't trust them (at least in part) _because_ you issue 10-year certs.

    2. ettery

      Re: Shakedown time

      Good CAs who do the job they are paid for are a foundation of commerce on the internet. How else are you going to trust a website who's owner you don't know?

      And for websites only looking to protect their clients with encryption, Let's Encrypt couldn't be easier (or cheaper). I use Let's Encrypt wherever possible and would happily expire my certs daily if it improved client safety.

      Both are providing an important service.

      1. Anonymous Coward
        Anonymous Coward

        Re: Shakedown time

        "I ..... would happily expire my certs daily if it improved client safety."

        This is not a good general solution for all certs.

        What that would do would be to make systems much more fragile.

        If, for any reason, you can't renew, then stuff starts falling over. In some cases, it's a web site, in some cases it's infrastructure gear.

        Also, this makes the idea of a MITM attack on cert renewals both more appealing and more practical.

      2. DrXym Silver badge

        Re: Shakedown time

        Browsers implicitly trust HUNDREDS of CAs. If you think that green padlock is an assurance of anything but a site's ability to pass some cursory checks then you're sadly mistaken.

        1. Anonymous Coward
          Anonymous Coward

          Re: Shakedown time

          When I install a new browser, I actually spend a full lunchtime going through the CA list and disabling the shit out of it, only leaving the 3-4 big ones plus the small ones I actually use (my country's government CA and so on).

          At a guess, perhaps once a year I get a certificate error due to a disabled authority, so clearly the list of preinstalled CAs could be *a lot* shorter.

          It's a pity that you can't actually import/export the list of disabled CAs, so it's a manual job every time.

          Maybe browsers could also ship with a list of trusted CAs but with most disabled by default, then present the user the choice to enable (bonus: just this certificate / the whole CA) when users start visiting HTTPS sites. After about two weeks you're unlikely to see another prompt for the next year or so.

          1. eldakka Silver badge

            Re: Shakedown time

            It's a pity that you can't actually import/export the list of disabled CAs, so it's a manual job every time.

            Keep a copy of the certs you do trust. When you get a new browser (or it patches, which can update the list), delete all certs, and import your half-dozen saved trusted certs into the empty cert-store.

            You can even save a copy of the entire cert database after you've customised it and just copy that over the top of the database in new installs. At least you could do that, not sure about the most recent versions of FF.

            1. Michael Wojcik Silver badge

              Re: Shakedown time

              You'll miss out on new intermediates (and the rare new root) from CAs you trust. And you may re-import compromised intermediates (or roots) that have been removed by the browser manufacturer.

              Properly maintaining a list of trust anchors is difficult.

  6. MJB7 Silver badge

    IoT

    I have an IoT device - specifically a wood pellet stove which I can control from my phone. Last year I had to upgrade the firmware "because of a change in the certificate". Now, for properly written IoT code (stop laughing at the back there), the firmware will hard code the CA root certificate and the server certificate can be updated as often as required. On the other hand, if you expect to upgrade the firmware every couple of years anyway, it's much easier to hard code the hash of the server cert directly, and just use a long-lived cert. That's not an option if you protect the server with a LetsEncrypt cert that rolls every three months. (On the other other hand, if you are using a hard-coded cert, you can just use a self-signed cert.)

    1. myhandler

      Re: IoT

      Wood pellet stove you can control from your phone? Henry David Thoreau rolls on floor..

      1. DCFusor Silver badge

        Re: IoT

        Just waiting for Dan Tentler to hear about that one -

        Start a building on fire over the internet? Challenge accepted!

        1. Nifty

          Re: IoT

          Been done when a colleague unintentionally flipped a bit on a press PLC control system in a timezone 12 hours from ours. 25 years ago via modem.

      2. Michael Wojcik Silver badge

        Re: IoT

        Look, kid. In my day we had to use wood-burning computers, but we made do.

  7. Anonymous Coward
    Anonymous Coward

    We moved from RapidSSL and it took a few hours

    We had a wildcard SSL certificate from RapidSSL, cost us a £150 per year. Pretty easy to use but still, it cost money.

    We moved to LetsEncrypt, took less than a day for all our servers (> 10) with around a dozen local IP addresses per server, cost one day of time and we never pay again. So it'll take approx one year to pay back and after than thats it. It just renews itself every 80-90 days or so. No fuss.

    But also no cash cow for these certificate companies who do sod all for their money. The business model for Certificate companies is dead.

    1. MJB7 Silver badge

      Re: We moved from RapidSSL and it took a few hours

      You are saying one employee day is worth £150? The usual figure is 200 working days per year, so that's £30,000 / year. Overheads (admin, rent, employer NI, employer pension contributions, etc) is roughly equal to salary, so that an employee being paid £15,000 / year.

      For a full time employee (37.5 hours/week), if I have used the calculator correctly, the national minimum wage is about £16,000.

      It's going to take several years to recoup the cost (still a decent ROI though).

  8. Flywheel Silver badge
    Thumb Down

    Won't somebody think of the meetings ?!

    perceived benefits of shorter certificate lifetimes will be offset by the added costs and headaches companies would encounter by having to renew their paid-for certificates roughly once a year

    FFS .. whenever there's a cert change, I get drawn into meetings galore, and the email server starts to get hot just handing the extra guff that apparently needs to be discussed for a cert update. Right now I can handle this once every couple of years, but every year? Nooooooooo!

    1. Anonymous Coward
      Anonymous Coward

      Re: Won't somebody think of the meetings ?!

      So *automate* certificate renewal. Then *document* it. Then *never think* about it again. Lazy devops are best devops.

      1. eldakka Silver badge

        Re: Won't somebody think of the meetings ?!

        Many organisations won't let you automate expense payments like that, there'd have to be some human in the loop to approve and accept the charge before the certificate could be renewed.

        Painful I know, but f'king bean counters, it costs more to implement their accountability requirements than the benefits accrued from them.

        1. Olivier2553 Silver badge

          Re: Won't somebody think of the meetings ?!

          As it was mentioned, you can also decouple technical and financial part: pay once for a 2 years subscription (finance part) and get as many certificate renewals as needed during that period (technical part).

          You don't even need to inform the manglement about the technical updates every 3 or 12 months, not more than you inform them every time you patch a system.

  9. mark l 2 Silver badge

    The days of these companies being able charge large amounts for certificates when all they are doing is a bit of basic admin is coming to an end.

    The only checks most of these companies are interested in doing on is to ensure the payments clear and they aren't interested in verifying whether the person buying it is legitimate or not, so unless they are going to change the way they do things their business is going to get taken away more and more buy the free certs providers.

    For a large proportion of websites letsencrypt certs are perfectly acceptable or if you use Cloudflare you can also get a free cert from them as well.

  10. RogerWilco

    DV's only

    Don't LetsEncrypt only offer DV certs, because they can't automate the renewal/verification of OV and EV certs?

    That would be a show stopper for us, as nice as an idea as it is.

    1. Crypto Monad

      Re: DV's only

      That's correct. EV certs are dead, since Chrome and Safari stopped displaying them, because users ignored them.

      The *only* thing that an SSL/TLS certificate assures you is that when you make a connection to xyz.com, you you are exchanging data with someone who controls the domain xyz.com - that is, the connection is not subject to DNS spoofing or active man-in-the-middle attack.

      In particular, it does not tell you anything about whether xyz.com is a good or bad actor, e.g. if you enter your credit card details they will be used for evil purposes or not. And it never did.

      1. Anonymous Coward
        Anonymous Coward

        Re: DV's only

        Why can't this be done with a public key attached to the domain record in the DNS, signed by a trusted entity (such as whoever runs the TLD of that particular domain name?)

        1. Frumious Bandersnatch Silver badge

          Re: DV's only

          a public key attached to the domain record in the DNS, signed by a trusted entity

          You know, that kind of sounds like something ... a web cert from a CA.

          1. John Robson Silver badge

            Re: DV's only

            >>a public key attached to the domain record in the DNS, signed by a trusted entity

            >You know, that kind of sounds like something ... a web cert from a CA.

            NO - It sounds like a DNS SEC record.

            With the public key pushed to your standard DNS server - it can be self signed, since the public key is validated by you signing it with your DNS SEC key.

            Which is validated by each subdomain up to the root.

            It absolutely ties a cert to a domain - doesn't prove who owns that domain - but then I can get a cert for <glyph_substituted_bankname>.com quite easily at the moment - so this is no worse than the current situation.

            The DNSSEC keys could be provided with authentication options.

        2. Mike007

          Re: DV's only

          Because the browser vendors didn't want to support the standard. Something about not wanting to include a DNS library in the browser... an argument they stopped using when they actually did want to support a new standard.

          It is commonly used for opportunistic encryption of SMTP transactions.

      2. Anonymous Coward
        Anonymous Coward

        Re: DV's only

        "The *only* thing that an SSL/TLS certificate assures you is that when you make a connection to xyz.com, you you are exchanging data with someone who controls the domain xyz.com - that is, the connection is not subject to DNS spoofing or active man-in-the-middle attack."

        Unfortunately it doesn't even do that in any meaningful sense, because with the possible exception of state actors and perhaps tier 1 backbone providers, no attacker is going to bother with MITM any more. It's so much easier to exploit broken or misconfigured software at the endpoint, which obviates transport security entirely. Once the endpoint software (or OS) is compromised, nothing stops the attackers from viewing all the data being received there, in the clear. So yeah, you're communicating with xyz.com, all right... and also nefarious.ru, who are siphoning it right out the back, but TLS can't tell you that.

        And of course the even more common failure to secure data at rest, which has nothing to do with communication at all. Fake sites still crop up from time to time and steal data from a few of the very most unwary, who ignore the warnings TLS provides them anyway. But these are not the preferred attack vectors any longer, if indeed they ever were. Attacking the endpoint is both far easier and much more lucrative, since you can target exactly what you want and get all the users/customers at once (and often persistently, too) without the immense volume of chaff or finicky per-connection setup hassle.

        1. doublelayer Silver badge

          Re: DV's only

          That's all true, but what's the point? Certs only protect the transport layer, so if they're doing that, they're serving their purpose. Protecting the endpoint is the job of something else.

          1. Anonymous Coward
            Anonymous Coward

            Re: DV's only

            The point it that it has to be All or Nothing. One weak link anywhere will break the whole chain, and an Outside the Envelope attack can pwn you just as easily as a MITM. IOW, you can't focus on any one aspect of the transaction: you need to focus on ALL of them, simultaneous and with equal attention, or the one you overlook becomes the one that gets you.

      3. Michael Wojcik Silver badge

        Re: DV's only

        EV certs are dead, since Chrome and Safari stopped displaying them, because users ignored them

        Possibly overly optimistic. While browser manufacturers scorn EV certs, the CA/BF loves them. Their Code Signing Working Group mandated EV certs for code signing (as if that wouldn't be a fucking nightmare) in their draft spec, and - as some may remember - Microsoft briefly adopted that position, before backing down in the face of ISVs waving torches and pitchforks. It wouldn't surprise me if the CA/BF keeps pushing EV certificates for years to come, even with the browsers ignoring the distinction. And they'll try to wedge them into more non-TLS applications.

        I agree that EV certificates are largely pointless - the additional cost doesn't buy much, considering that CAs have a record of not performing the additional verification properly (or at all, in some cases), and the HSM requirement for key management is not universally enforced and was poorly written in the first place. (FIPS 140-2 L2 security on the HSM isn't worth a damn, and prevents people from using inexpensive hardware with open-source drivers.) But CAs and the CA/BF will try to find ways to keep the EV cash cow alive for a while yet.

    2. Tom 38 Silver badge

      Re: DV's only

      Did you see yesterday that chrome will display EV certs the same as DV certs?

  11. John Lilburne

    An issue of Google's own making ...

    ... I'll have no part of it.

    If you have no SSL cert there cannot be any issue of it being exploited, or having insecure encryption, or being applied to an abandoned site, or of it being stolen.

    My website is like the majority of websites in that it is a persoanl blog that has no user signups, has no comment section, and has no purchase cart. It does not need a SSL cert of any description. Which is just another bit of software to deploy on the site and as such another vector for hackers to exploit. Here we are with a proposal by the SSL scammers and their enablers (Google, Mozilla, et al) to fix a problem of their own making.

    1. MJB7 Silver badge

      Re: An issue of Google's own making ...

      My website is like the majority of websites in that it is a persoanl blog that has no user signups, has no comment section, and has no purchase cart.

      I suspect that your website is in the majority in terms of count of websites. However, in terms of unique views, I suspect it is in a tiny proportion. Nearly all the blogs I visit have comment sections.

      There are still cases for HTTP only websites (and yours is one of them), but I can't teach my mother to distinguish between when HTTP is safe, and when it is a scam. I *can* teach my mother to avoid a website that Chrome (other browsers are available) labels as "INSECURE". Chrome is going to have a hard time distinguishing between those sites which need to be HTTPS, and those that don't; it's not an unreasonable security trade-off to say "just make them all HTTPS".

      1. Crypto Monad

        Re: An issue of Google's own making ...

        > I *can* teach my mother to avoid a website that Chrome (other browsers are available) labels as "INSECURE".

        I think what you mean is, "I can teach my mother to avoid entering her banking details into a site which Chrome etc labels as 'INSECURE'". Even that minor toe-hold goes away when all sites are HTTPS. But it never really helped in the first place.

        The theft of sensitive data by packet-sniffing of unencrypted traffic is only a tiny part of the problem. The main problem is entering data into fake sites which look legitimate. If the web site looks like her bank's website, your mother will use it. It may even proxy to the real site behind the scenes.

        Anyone can register a plausible-looking domain like "halifax-online-services.com" - and could also register a similar-sounding company name if they want an EV cert (but why bother, since 99% of users ignore them anyway?) I expect most users would enter their login details at "halifax-secure-banking.dyndns.org" if the content looked right.

        "Secure" (in the weak sense provided by HTTPS) is very different to "trustworthy".

        1. John Lilburne

          Re: An issue of Google's own making ...

          "Secure" (in the weak sense provided by HTTPS) is very different to "trustworthy".

          Indeed 2 years ago I was doing some online banking from my desktop PC using the Barclay 2 factor device and got a page that was unexpected, some security thing or something. I rarerly do online banking but it looked slightly odd and I was unsure URL seemed OK but still ... went to the online chat with the bank (using the mobile phone) and described exactly what I was seeing and how I'd got there. Person on other end of chat log said "No its OK. Its a genuine Barclays page." "So I can to enter these numbers and press Ok", "Yes its alright." So I pressed Ok and out of the account went some £965. Sudden escalation of support up the system, and Barclays refunded the money about 12hrs later.

      2. John Lilburne

        Re: An issue of Google's own making ...

        "Nearly all the blogs I visit have comment sections."

        They may have but very few have valid comments added to them. When I had anonymous comments enabled it was a full time job deleting the spam, even with spam filters in place. Requiring register to comment was almost as bad, every day one would get 50-100 signups (usually using gmail), which stopforumspam detected as coming from known spam and malware sources. Leave it for a few days and one had 1000s of bogus users and a similar number that were suspect.

    2. Orv Silver badge

      Re: An issue of Google's own making ...

      I think the best argument for HTTPS for casual sites like that is to prevent ad injection by rogue ISPs (which these days is most of them). HTTPS will also prevent casual eavesdropping when people use public WiFi access points. It doesn't help security in this case, but it's good for privacy.

      1. Charles 9 Silver badge

        Re: An issue of Google's own making ...

        Actually, it does help security because it prevents a malware injection in the transport (a la Chinese Cannon). The world of the Internet today pretty much necessitates 100% encrypted transport because you can't be sure ANY unencrypted transport won't be usurped and turned into an attack vector.

        1. Michael Wojcik Silver badge

          Re: An issue of Google's own making ...

          In particular, it's trivial to inject Javascript malware into an HTTP connection. People who run NoScript and the like have some defense against that, but for most users it's a gimme. Everybody using unencrypted WiFi at a coffeeshop or the like is an easy target. Attackers can run cryptomining or try popular CSRF targets, etc.

  12. Alister Silver badge

    perceived benefits of shorter certificate lifetimes will be offset by the added costs and headaches companies would encounter by having to renew their paid-for certificates roughly once a year

    We only ever buy certificates for 1 year anyway, so it's not going to make any impact for us. We currently have 328 domains with certificates on them, with their expiry dates spread throughout the year, so slightly less than one a day has to be renewed - although they are clumped more than that.

    1. disgustedoftunbridgewells Silver badge

      More than one per work day? Surely you automate the process?

      1. Alister Silver badge

        Wherever we can, yes, obviously, but as mentioned above, for EV certs and some other types it's still a manual (and long drawn out) process.

  13. dank_army

    Everyone's happy until...

    When LE start charging for certificates.

    1. matt 83

      Re: Everyone's happy until...

      I'd be happy to pay LE for certs. Their service is far better than any of the pay CAs that I've come across. Much better documented and a very reliable cross platform automatic renewal client.

      How much I'd be happy to pay them is another matter ;)

    2. localzuk

      Re: Everyone's happy until...

      Put it this way, they could charge $1 a year per domain and suddenly they're earning more than $100m a year in income. I don't know of any organisation that would go "hmm, nah, we don't want to pay $1, we'll switch back to the $150 a year company". Hell, make it $10 and most would still pay.

  14. Anonymous Coward
    Anonymous Coward

    SSL/TLS != Websites only

    Worth remembering that SSL/TLS certs aren't only used by websites. While updating a cert on a website is a trivial exercise, once you start securing muti-server enviroments like Exchange, RDS or when signing remote app packages on multiple hosts, then it can become a lot more time consuming (especially when in some cases those operations can't be done without interupting user connections), especially where LetsEncrypt isn't possible / viable. Potential danger I see of decreasing the maximum age is that it may tilt the balance for some people between "let just secure everything" and "Hmmm, so which bits do we NEED to secure".

  15. Stevem278

    Encourages automation, increases security, reduces costs

    This is great news, it will encourage businesses to move to more automated solutions with less user error. We used to use GoDaddy and annual renewal, rekeying etc. was an expensive pain. Now we use LetsEncrypt along with a few scripts and tools it's now free and automatic. So much easier!

    1. Roland6 Silver badge

      Re: Encourages automation, increases security, reduces costs

      Looks like the beginning of Certificates-as-a-Service (CaaS).

      That 90-days seems a bit long, reduce it to 45 days(*), which is more in keeping with monthly subscription payments. Now LetsEncrypt won't remain free, at some point it will need to make money, also they are doing all the work so that businesses (who earn money) can reduce costs, so naturally their backers will see sense and want a slice of that cost saving...

      (*) Remember once-upon-a-time we were supposed to change our passwords every 4~6 weeks as it was supposed to enhance security; until someone did the research...

      1. doublelayer Silver badge

        Re: Encourages automation, increases security, reduces costs

        Everything's possible. However, LE is run by some pretty charitable people with a track record of not being that rent-seeking. In addition, all their code is open and freely-licensed, so someone could copy their system quickly. Of course there'd be some difficulty getting the new system trusted by everybody, but it could eventually happen. I think we'll probably be fine.

        1. Charles 9 Silver badge

          Re: Encourages automation, increases security, reduces costs

          But it's still infrastructure, and infrastructure costs money, both in acquisition and in upkeep. History shows gratis services like this usually can't stay up long-term unless something exceptional happens like a rich-but-charitable backer.

  16. Luke Maslany

    DV can be a painful experience when you don't control the domain. It doesn't matter how well you've automated your side of the equation if you're reliant on a third-party. Lots of hoop jumping and delays to be had when getting DNS changes through a client's IT team...

    1. Orv Silver badge

      Given that the whole point of DV is to ensure you control the domain you're asking for a cert for, I think that's sort of built into the system.

  17. Anonymous Coward
    Anonymous Coward

    One nasty habit Google employees have

    Is assuming that HTTP and browsers are *only* used on the world wide web.

    Intranets also exist. And so do embedded devices with LAN-only HTTP interfaces.

    1. eldakka Silver badge

      Re: One nasty habit Google employees have

      What do HTTP services care about public CA certificate issuing policy changes for?

      What do intranets care about policy changes for public CAs? If you are using certs on intranet devices for HTTPS or TLS in general (or for whatever else you use X.509 certs for internally), you can set up your own internal self-signed private CA and ignore these policies used by public CAs.

      1. Dal90

        Re: One nasty habit Google employees have

        >you can set up your own internal self-signed private CA and ignore these policies used by public CAs.

        This proposal is by the CA/Browser forum.

        They don't write standards that bind any CA public or private.

        They write standards that the Browsers will throw warnings when a cert issued by any CA doesn't meet their standards.

        Have fun with the InfoSec training explaining when end users should accept the security risk and when they shouldn't.

        ===============

        Hey, I'm all over ADCS Autoenrollment (oh wait, our InfoSec group doesn't allow that and require manual requests (which I have scripted) followed by an email (scripted) for them to manually release (which once they do scripts complete the process...))

        And I'm all over Let's Encrypt (same InfoSec group basically blew milk out their nose and scrambled trying to explain how it doesn't meet corporate standards for being a well-reputed commercial CA).

        But even with that automation, I'm still left with situations such as:

        -- Devs who claim their applications can't Intermediate / Root certs to validate and have to pin the public the certs;

        -- Admins who claim likewise (really your six-figure Application Gateways can't possibly deal with certificate chains and need to pin a public cert?)

        -- Federated organizations which don't check for SAML metadata updates and need to manually coordinate updating SAML signing certificates

  18. streaky Silver badge

    Solution looking for a problem.

    Title.

    Also already moved a bunch of personal and corp certs to LE because hassle, think LE has reached the tipping point where there's not much reason not to if you don't really really need EV, code signing certs (which are equally ripe for disruption) and the like.

  19. gnarlymarley Bronze badge

    "Rapidly reducing certificate lifetimes to one year, or even less, has significant costs to many companies which rely on digital certificates to protect their systems," Hollebeek said.

    This also introduces the possibility of human error and the actions need to take place more often then it previous would. Human error appears to be a large part of the problem too.

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

Biting the hand that feeds IT © 1998–2019