back to article Mozilla, EFF, Cisco back free-as-in-FREE-BEER SSL cert authority

A new certificate authority – backed by big names on the internet including Mozilla, Cisco and Akamai – plans to offer SSL certs at no charge starting next year. The move will make it even more easier for people to run encrypted, secure HTTPS websites. Let’s Encrypt aims to provide an easier way to obtain and use a digital …

  1. Dave Pickles

    Not sure I want a certificate management agent footling with my server.

    1. Velv
      Pirate

      Then don't use the service and either:

      A) Manually configure and maintain your own certificates; or

      B) Keep running unencrypted.

      For the millions of website admins out there who haven't got a clue, this will be a good thing.

      1. Anonymous Coward
        Anonymous Coward

        For the millions of website admins out there who haven't got a clue, this will be a good thing.

        .. provided they accept being beholden to a 3rd party for certifying a link as correct in origin, and as it's free, the business has to come from somewhere else. Sorry, but I've seriously cynical about all the wonderful "good motives" that are flying around, especially since this is a US effort - if they are so bloody concerned about keeping us all safe, then why are they using Google for email?

        On the plus side, the companies that have been growing fat on selling you slices of a PKI will be forced to do something about their prices which are sometimes nothing short of insulting.

    2. crackerjacks12345

      Nobody needs to touch your server for this. Internet domain name records are public information and they just verify your the real owner/administrator of the domain the encryption keys are for. They don't need access to your servers to do that. For most keys they just send a verification email to the registered owner of the domain name to verify you. They also only need your Public key, not your Private key. Without the Private key someone can't decrypt stuff encrypted with your Public key. Hopefully someone isn't paying you to manage a server if you don't know how SSL/TLS keys are setup.

      On your computer/server you generate a Private RSA key. Then you generate a certificate signing request for the Private key. You send the CSR to the certificate authority you are using. Then they verify the information in the CSR like your domain name and that your authorized to issue it. Then they digitally sign your Public certificate with their Private certificate and send you the signed Public certificate. Then you simply setup your web server to use SSL/TLS with your Private Certificate and your signed Public Certificate. Then you just setup your server with your Private Certificate and your Public Certificate signed by the CA. If the CA is one of the trusted Root CAs your browser uses, then it will work normally without warning you.

      With RSA you have a Public and a Private key. Anything encrypted with the Public key can only be decrypted with its Private key. Anything digitally signed with the Private key can be verified with its Public key. Certificate Authorities are like a public notary, they use their Private key to sign a websites Public key after verifying who they are. Computers have a database of the Public keys for trusted CAs. When you connect to a secure website they send you their public key and then you send them another temporary encryption key for just this session encrypted with the public key they sent you, because only the site has their private key, only the site can decrypt the session key you sent them to start the connection. You would verify you got the real sites public key and not someone hijacking the connection because it would be signed by a trusted CAs private key, so you use your database with the public keys of trusted CAs and check that the signature is valid. Without trusted CAs it would be like without trusted public notaries, you would have to personally verify the peoples identities and then have them verify the correct encryption keys. I suppose you could have sites like FaceBook, Google, and others call, fax, or mail you their public encryption keys so you can verify the connection but that would be much more time consuming then just having the site pay a company to verify them for you.

      1. Kiwi

        @ crackerjacks12345

        Nobody needs to touch your server for this.

        From the article and the linked pitch (https://www.letsencrypt.org/howitworks/), "enabling HTTPS for your site will be as easy as installing a small piece of certificate management software on the server:"

        Their software manages all sorts of stuff - the certificates (providing them, replacing them when they're due to expire, configuring your system to handle them...)

        From their site :

        The Let’s Encrypt management software will:

        Automatically prove to the Let’s Encrypt CA that you control the website

        Obtain a browser-trusted certificate and set it up on your web server

        Keep track of when your certificate is going to expire, and automatically renew it

        Help you revoke the certificate if that ever becomes necessary.

        On your computer/server you generate a Private RSA key. Then you generate a certificate signing request for the Private key. You send the CSR to the certificate authority you are using. Then they verify the information in the CSR like your domain name and that your authorized to issue it. Then they digitally sign your Public certificate with their Private certificate and send you the signed Public certificate.

        And your earlier line of For most keys they just send a verification email to the registered owner of the domain name to verify you.

        From them : No validation emails, no complicated configuration editing,

        This is a program that will supposedly manage the lot for you. You install the program and run the command "lets-encrypt example.com" (again, from their site) and it's done. It does the key management and generation, it does the server config, manages getting the key signed.. It does it all.

        For someone who wants to get a "proper" cert but lacks the funds, very tempting. But I sadly see "USA" and a couple of other parties I tend to flag as "untrusted" involved, so doubt I'd be willing to risk them.

        Oh, can someone tell me how to get some preceeding whitespace/tabs in front of lines in Reg comments? I've tried various tricks without luck.

        1. Havin_it
          Boffin

          Re: @ crackerjacks12345

          . . . I think this is

          . . . the best you're going to get

          . . . (without a badge, anyway).

  2. This post has been deleted by its author

    1. Alan Birtles

      Re: A major obstacle to encrypting everything

      SNI is fairly well supported now so SSL virtual hosting is possible http://en.wikipedia.org/wiki/Server_Name_Indication

    2. Ken Hagan Gold badge

      Re: A major obstacle to encrypting everything

      So the killer application for IPv6 is "keepng the spooks at bay".

      Excellent. Yet another reason to seek out 21st century ISPs rather than bottom-feeders.

    3. Gordon 11

      Re: A major obstacle to encrypting everything

      In order to provide SSL to a server, it needs its own IP address

      No, it doesn't. It needs it's own DNS name.

      (I have self-signed certificates with not an address in sight anywhere.)

      1. Anonymous Coward
        Anonymous Coward

        Re: A major obstacle to encrypting everything

        Yes it does, or as said SNI enabled.

        A site using SSL needs its own IP address (or port) if SNI isn't enabled or the client doesnt support it. As the server will not know which private key to use to decrypt it as the URL is encrypted, its only coming in on an IP address and port. A site doesn't need DNS if using SSL, a certificate can be assigned to an IP also. Without SNI or an IP address assigned to a specific certificate, the server has no way of knowing which private key is to be used to decrypt the incoming data.

        1. streaky

          Re: A major obstacle to encrypting everything

          "if SNI isn't enabled or the client doesnt support it"

          Ther are no browsers in active support that don't support SNI. The end of SSLv3 was the end of no SNI support - therefore not a problem.

          No seriously, SNI.

          1. o p

            Re: A major obstacle to encrypting everything

            No, TLS is a requirement for SNI support, but it is not enough by itself. There are clients which support TLS but not SNI.

            1. streaky

              Re: A major obstacle to encrypting everything

              "There are clients which support TLS but not SNI"

              Whilst this is strictly true, the reality is SSLv3 being broken removed all the remaining browsers/stacks (anything on windows xp) that don't support SNI from the equation, therefore no problem. Anything that doesn't support it is out of support (again, anything on XP) with a seriously compromised stack.

              Per wikipedia SNI support:

              Internet Explorer 7 or later, on Windows Vista or higher. No support for any Internet Explorer version on Windows XP because SNI depends on the SChannel system component shipped with Windows Vista.

              Mozilla Firefox 2.0 or later

              Opera 8.0 (2005) or later (the TLS 1.1 protocol must be enabled)

              Opera Mobile at least version 10.1 beta on Android

              Google Chrome (Vista or higher. XP on Chrome 6 or newer. OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)

              Safari 3.0 or later (Mac OS X 10.5.6 or higher and Windows Vista or higher)

              Konqueror/KDE 4.7 or later

              MobileSafari in Apple iOS 4.0 or later

              Android default browser on Honeycomb (v3.x) or newer

              BlackBerry 10 and BlackBerry Tablet OS default browser

              Windows Phone 7 or later

              MicroB on Maemo

              Odyssey on MorphOS

              Even if you're on XP (for reasons passing understanding) third party browsers will generally cover you via NSS.

  3. Yet Another Anonymous coward Silver badge

    Do I understand this?

    To improve security everyone and their dog and its pet Nigerian prince can now get a certificate for the little green padlock that I have trained my grandmother, dog and CEO to look for before entering any details?

    1. Stephen W Harris

      Re: Do I understand this?

      SSL certs are already free, from places like StartSSL; the green padlock doesn't really prove much. It's definitely not proof of identity.

      1. Anonymous Coward
        Anonymous Coward

        Re: Do I understand this?

        StartSSL is not free, just ask all those stung by Heartbleed.

      2. Tom 13

        Re: It's definitely not proof of identity.

        While that is true, it is also true that for the last 10 years security spooks have been training people to look for the padlock. And when your typical punter sees the lock he thinks it is safe.

      3. Anonymous Coward
        Anonymous Coward

        Re: Do I understand this?

        NO - the real idea behind a CA is the CA is responsible to ensure a certificare is issued after a proof of identity. Certificates are designed to provide both authentication and encryption.

        If you start to issue certificates without a proof of identity, you get encryption, but you lose authentication.

        Self-signed certificates are useful only to provide encryption because there's no way to athenticate them, and they correctly trigger a warning because they can't provide authentication.

        If such a CA is ever be adopted in the systems I manage, I will remove it and put it in the untrusted list.

    2. Ken Hagan Gold badge

      Re: Do I understand this?

      They always could. This is basically a self-signed certificate. Browsers that warn about self-signed certificates will warn about these ones, too. (Won't they?) I don't personally understand the point of the proposed service, unless they think that generating a self-signed certificate is currently "too complicated" and needs to be reduced to some button pushing on a web-site.

      1. True Thug

        Re: Do I understand this?

        I assume these will be signed. This will ensure that every site has encrypted communications. +1

      2. Tom Chiverton 1

        Re: Do I understand this?

        I've seen nothing to suggest it wont be signed by a CA included in $popularBrowserOfTheWeek

      3. Anonymous Coward
        Anonymous Coward

        Re: Do I understand this?

        > This is basically a self-signed certificate.

        No it isn't. It will be signed by a CA controlled by someone other than the receiver of the certificate, and therefore, as long as said CA is recognised by all browsers in common use...

        > Browsers that warn about self-signed certificates will warn about these ones, too. (Won't they?)

        ...they will not warn about these.

        [ Unless you're a sad bastard like me, who has disabled almost every single CA in Firefox. But that's another story. ]

      4. streaky

        Re: Do I understand this?

        "This is basically a self-signed certificate"

        No, no it isn't. They're clearly getting a CA certificate that's well supported in the browser trust chain. It costs money, but not that much money,

        1. Anonymous Coward
          Anonymous Coward

          Re: Do I understand this?

          This provides no better authentication than self signed certs. If Mozilla and Google want encryption everywhere, authentication be damned, they could just tweak their browsers to quit bitching about self signed certs.

        2. Ken Hagan Gold badge

          Re: Do I understand this?

          "It costs money, but not that much money,"

          So the free-as-in-beer part of the article's claim isn't true?

          If it costs nothing to get the certificate, the certificate should be treated by browsers as worth no more than a self-signed one. After all, a bad guy mis-using that certificate has nothing to lose.

    3. Irongut

      Re: Do I understand this?

      The little green padlock only appears on sites with extended validation certificates. These involve actual checks to ensure the purchaser is who they say they are so cost more than a basic certificate. The article only mentions basic certificates and since they are going to be free I would doubt they will supply ev certs.

      1. daftdave

        Re: Do I understand this?

        No the green padlock appears on any https connection provided that the browser recognises the CA and everything else is OK with the certificate.

        EV sites have the green padlock plus some green text with the name of the validated organisation (see mozilla.org for instance)

        Just because someone is having an encrypted with you doesn't mean that you can trust them, but for years the masses have been educated into "green padlock == safety"

  4. Anonymous Coward
    Anonymous Coward

    The object here...

    ... is to get more traffic encrypted by default thus raising the bar on our surveillance state's always monitored by default communications. Still, it won't raise the bar very high as the who-where-when (none of what was said) metadata will still be available which may be just enough to keep the spooks and the elites they serve happy. And we'll almost certainly, down-votes-welcome, going to have to live with that. "They" are most worried about being able to trace the nodes of a conspiracy once detected, not the particulars of what was said. especially where it hits them personally. (And all of this is all about that existential threat, not protecting the citizenry.)

  5. AndyFl

    ElReg

    Maybe at last TheRegister will be able to afford a SSL certificate :)

  6. petur

    "It usually costs money"

    Yup, a single domain is usually quite affordable or even free, but if you want a wildcard for subdomains, oh dear, of dear.... sometimes it feals like you're dealing with the maffia...

  7. John Robson Silver badge

    Sideload the certs already...

    DNSSEC and then the cert can sit in a defined DNS txt record.

    Single point of trust (DNS root, and those guys have proved themselves worthy of trust in the past) allows anyone to provide their own certs, no problem.

    There is no need to have yet another set of trusted keys automatically loaded to every computer from here to kingdom come... ready to be abused by whichever state/company can crack the lowest security one around.

    1. Charles 9

      Re: Sideload the certs already...

      "Single point of trust (DNS root, and those guys have proved themselves worthy of trust in the past) allows anyone to provide their own certs, no problem."

      And if this trust gets betrayed? What if we really go into "Trust No-One" mode?

      1. John Robson Silver badge

        Re: Sideload the certs already...

        At the moment we are mostly forced to explicitly trust (goes to count on this system)...

        Heck 21 certs from 10 organisations that start with the letter A alone, about 100 organisations in total (so about 200 certs, although I did notice that a handful of certs were labelled untrusted).

        ANY one of those could be betrayed/hacked and I'm screwed, until ${authority} admits it, ${browser} gets updated by ${company} and I get the opportunity to upgrade.

        If the DNS root trust is broken then it would need to be reestablished, but DMV servers already exist for that purpose already, whenever that chain of trust is broken (generally because of a middle level domain not supporting DNSSEC nowadays).

        I also suspect that it would make the news, globally. Not just a "some Iranian cert authority is suspected to be hacked" item tacked onto a slow news day in southern Spain.

        The people who run the root DNS servers have proved themselves capable of keeping such systems alive and (afaict) secure - I certainly trust them more than I trust some random ${geographical/political} authority I've never heard of.

        Add a couple of DMV services (which you can use *if* you trust that organisation) and you're away. I'd suggest that each browser company might want to run their own DMV, after all you already implicitly trust them directly, so for the average user it's probably a good compromise to have that installed and ready to go if/when the root anchor is broken...

    2. Anonymous Coward
      Anonymous Coward

      Re: Sideload the certs already...

      This is called DANE and it does not require any cert authority at all.

      The side effect of a cert authority is that it can be made to cooperate and issue certs to allow a MIM. With DANE - not so much, you have to break DNS-SEC top to bottom and inject your own answers into DNS to achieve a similar result.

      I see this as a step backwards. Mozilla should instead of that stop w***ing and implement DANE fully for opportunistic encryption.

  8. Anonymous Coward
    Anonymous Coward

    Be nice if you could get multipart certificates

    Do you trust that these guys aren't feeding the keys to the feds? Or that they aren't being unknowingly hacked? Not a problem if you set a simple site to make your vacation pictures and grandma's recipes available, but you probably didn't need to encrypt that in the first place...

    If there were several authorities like these that offered free or cheap certificates, in different countries that probably don't cooperate for spying (say US, Russia/China, India) that could be combined into a single extended certificate that worked transparent for client browsers, assurance of security could be greatly improved.

    1. Anonymous Coward
      Anonymous Coward

      Re: Be nice if you could get multipart certificates

      > Do you trust that these guys aren't feeding the keys to the feds?

      You mean your cert's private key? That should never be known to them in the first place. A CA only needs your CSR to sign the certificate.

      Of course that doesn't stop them signing a CSR from someone else claiming to be you, if they so wish, but your secret key will not be compromised by that (and newer versions of browsers tend to remember the certificate's fingerprint after they first see it, so this attack is somewhat mitigated).

      1. Kiwi

        Re: Be nice if you could get multipart certificates

        > Do you trust that these guys aren't feeding the keys to the feds?

        You mean your cert's private key? That should never be known to them in the first place. A CA only needs your CSR to sign the certificate.

        The problem here is, this software does it all for you with one command, from generating the private key on (at least as far as it appears in their text). And if it has enough access to your system to configure your web browser for you, it sure as hell has enough access to siphon off your privates.

  9. o p

    Sni limitations.

    SNI is not supported by ie 8 / win xp ( which supports tls ). It can make up significant percentage of your audience

    So if you have a merchant site for example, this is not always something acceptable. Note that you can use a single certificate with multiple alternate subjects, but it is not practical for mutualised hosting.

    If these certificates are not signed by an authority already installed in more than 98% of Web clients, the whole thing is pointless.

    1. Anonymous Coward
      Anonymous Coward

      Re: Sni limitations.

      Yes, but SNI is supported on IE7+ for all versions of windows later than XP (and in case you missed the news, Microsoft has discontinued support for XP).

      So unless your target audience is in China, the potential audience you're excluding is very small (and there are numerous SNI capable browsers available for XP. for example, both firefox 2+ and safari 3+ both work).

      1. o p

        Re: Sni limitations.

        I manage several sites with audience in europe, us and latin america, ie8 / winxp traffic is still something can you can hardly discard because "they should upgrade".

        I suppose it would be even much more the case if we had customers in China. And I would like very much to have customers in China, and I would certainly not prevent them to pay for content because their browser is not sni capable.

      2. Kiwi

        Re: Sni limitations.

        Yes, but SNI is supported on IE7+ for all versions of windows later than XP (and in case you missed the news, Microsoft has discontinued support for XP).

        MS has discontinued support. Yet XP use still outweighs Fista and H8 (and H8.1) combined. Somewhere about 20% (or one in 5) of all desktop installs IIRC.

        Dropping out 20% of your audience is something few companies could afford to do.

  10. Anonymous Coward
    Anonymous Coward

    Sni limitations

    Hence Mozillia's place among the sponsors. No doubt Google will follow shortly, as will Apple, since they'd have to be completely clueless not to support kind of effort in the public interest. Microsoft is another matter, but then they always have been.

  11. Anonymous Coward
    Anonymous Coward

    So how will this work?

    Let's Encrypt: Yay! Certs for all!

    GCHQ/NSA: Give us your keys.

    LE: Err, no.

    GCHQ: Give us the keys or we will kindnap and torture you. And don't tell anyone abut this.

    LE: Eek! Here are the keys...

    1. Justin Pasher

      Re: So how will this work?

      What does this have to do with keys? They wouldn't have the private keys to decrypt the data. Only you would have those (installed on the server). All they are doing is signing a certificate to let others know it can be trusted (assuming the CA is included in the browser). They only get a CSR signed by your private key, not your actual private key. It's the whole point of asymmetrical encryption (e.g. public-key cryptography).

      1. Anonymous Coward
        Anonymous Coward

        Re: So how will this work?

        "All they are doing is signing a certificate to let others know it can be trusted (assuming the CA is included in the browser)."

        Because with the CA's keys they could do a perfect MITM attack.

        1. Justin Pasher

          Re: So how will this work?

          That's not how a typical SSL MITM attack works.

          Normally, a nefarious system will try to intercept the end user's traffic secretly. It would do this by jumping in between the two end points of the connection. To make it seamless, the bad guy would need to decrypt an already encrypted session, which is theoretically difficult (although the practicality of it changes over time). If the bad guy doesn't have the server's private key, it has to rely on exploits or weaknesses in the encryption.

          Now pretend the private keys of the CA were compromised. This allows someone to sign their own certificates that browsers will automatically trust. It doesn't involve breaking or compromising the encryption of the two end points. In essence, the MITM attack becomes more of a reverse proxy.

          Ultimately, that's no different than any other CA getting their private keys compromised. It still has nothing to do with the private keys of the original server providing the SSL connection.

        2. Flat Phillip

          Re: So how will this work?

          The way it works now if ANY CA keys are compromised then any certificate can be faked. Leaving browser caching (remembering if you like) keys its seen before aside, if having this CA spooks you and you say you are not going to use it won't make your website any safer as there is no "hard link" between a specific server certificate and the CA one. It would be lovely to be able to independently say that my server uses a certificate from this specific CA so reject any signed certs from anyone else but that doesn't exist.

          Someone else said that they'd be worried about the daemon having some evil mode. It looks like it will be open source (there is some code on github) which should at least remove any intentional nasties.

    2. Anonymous Coward
      Anonymous Coward

      Re: So how will this work?

      It doesn't really matter if the feds have the CA's private key. They still will not have *your* private key, so long as you are able to keep it private.

      When you request a certificate, the CA does not get a copy of your private key. All the CA does is certify that the certificate request that was used to issue the certificate was valid - according to the CA's definition of valid. Some CA's require quote a lot of documentation, and sometimes lots of money too; others take the ability to respond to an email to "webmaster@your.domain" to be sufficient proof.

      If the feds have your CA's private keys they will be able to generate certificates of their own, which will look like yours (so they can pretend to be you) but they will not be able to steal your cat pictures.

      1. o p

        Re: So how will this work?

        Yes but we don't have the details of how it will work.

        They say : "enabling HTTPS for your site will be as easy as installing a small piece of certificate management software on the server" .

        If this means that a daemon runs on your server, generates private key + csr and send it to a CA, it is very likely that the "management software" will be exploited, sooner or later.

        Let's assume it updates itself automatically - a "best practice" nowadays - it will be out of the control of the admin of the server.

        You can argue this is already the case with many components on the client and server side, so maybe one more will not make a huge difference. But from the paranoid point of view you can't accept it as really secure solution.

      2. dajames
        Black Helicopters

        Re: So how will this work?

        It doesn't really matter if the feds have the CA's private key. They still will not have *your* private key, so long as you are able to keep it private.

        ... but if the feds have the CA's private key they can generate a new keyset and issue a verifiable but bogus certificate that associates it with your identity.

        Then they can impersonate you, and ask your friends and associates to send them encrypted data using the public key in the bogus certifiacte -- and they will be able to read the data (but you won't, because you haven't got the relevant key).

        Then they can accuse you of collaborating with $TERRORIST and demand that you hand over your keys so that they can read your data and you won't be able to, because you haven't got the relevant key ... and they will lock you up and throw away the, er, key.

        Of course, the CA will know that they didn't issue the certificate ... but if they admit it they will be admitting that their root key is compromised, so they may choose not to.

  12. Anonymous Coward
    Anonymous Coward

    I think I paid £3 for my last pukka cert, so it's hardly a king's ransom to pay for it the old fashioned way.

  13. Andraž 'ruskie' Levstik

    cacert says hi

    Randoms: Hey look we're doing this thing...

    cacert.org: Hey look we've been doing this for years - with the added benefit that we are actually thinking how to get better at verify the user identity and how to handle if we can't

    Frankly CAs are way way overrated - it's basicalyl I claim I am such and such and I have money to prove it...

    1. Andrew Meredith

      Re: cacert says hi

      CACert is all well and very good, but their root CA certificate is not included in the majority of browsers, so you are almost as well sorting yourself out a self signed root CA certificate and then signing your own host and email certs.

      NB this is not the same as a self signed certs, your root signs your host/email cert. All root certificates are self signed ... if they weren't they would not, by definition, be root certs.

  14. Velv

    FFS people, this is not meant to be a panacea for all situations, it's a way to encourage the simple configurations on a large number of simple websites to switch on encryption. It's as much about educating world+dog on making communication secured as it is about the actual securing of those channels.

    There are always going to be more complex configurations that will still require you to get your certs from the existing CAs.

  15. This post has been deleted by its author

  16. Sgt_Oddball

    but what about....

    After having a nosy on the site and its easy set up guide I noticed something. No mention of what server platform you could set it up on (with just lines of code) just sudo commands. Not everyone runs apache servers.. (and yes I know how easy it is set up on an iis box but that's besides the point).

    It also worries me alot since alot of nasty traffic I've seen comes from hacked WordPress sites. What happens when certs get added to them? What then

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