Let's Encrypt: How It Works | Hacker News Reader

Let's Encrypt: How It Works

letsencrypt.org

408 pointsespadrine121 comments

Which browsers will trust Let's Encrypt certificates out of the box? There may be a major backwards compatibility gap here.

I'm not sure why you've been downvoted. This is a very reasonable concern and one that should be addressed.

We'll have very broad compatibility from day one via cross-signing by IdenTrust.

Great, thanks -- I'm looking forward to your release.

Great project to smooth out the really painful process at present for acquiring certs. How about an FAQ page or a few clarifications?

Things I wanted to know which were not immediately apparent:

Will it be broadly accepted from day one? Yes, apparently, though see the identrust issue below.

Will it generate a keypair but keep the private key on your server? Yes.

Will it work without having to babysit an interactive prompt? Yes.

Will it just let you generate key,csr,crt and do your own config changes? Yes.

Questions I still don't know the answer to:

Will it provide wildcard certs? No idea. I'd love it to be true as this is the part of current CA's which really irks me - the price gouging over something which costs them nothing more to provide. Can't see anything on the website about it.

How does it auto-renew, does it have to run all the time?

Why is the cert for identrustssl not trusted in Chrome or Safari? That doesn't inspire confidence : https://www.identrustssl.com/

Can every CA support issuing certs this way please? :)

We're working on an FAQ. This thread has been really helpful in clarifying which Qs are FA :)

With regard to your questions:

> Will it provide wildcard certs?

Not initially, but possibly in a future iteration.

Note that having an automatic CA addresses some of the use cases for wildcard certs. Namely, if you're using a wildcard cert just to avoid having to manage individual certs for foo-1.example.com through foo-N.example.com, you can just have them each automatically get a specific cert.

> How does it auto-renew, does it have to run all the time?

That will depend on the software running on the web server. The current "node-acme" and "lets-encrypt-preview" implementations in the Github repo are examples. Ultimately, in addition to these tools, it would be great to have ACME / LE support built into web server platforms, which are already running all the time.

> Why is the cert for identrustssl not trusted in Chrome or Safari? That doesn't inspire confidence : https://www.identrustssl.com/

I don't know what the story is with that site, but I believe the Let's Encrypt CA will be cross-signed under the same IdenTrust CA that issued the cert for https://letsencrypt.org/. So Let's Encrypt certificates should work wherever that site works (which includes Chrome and Safari, at least on my MacBook).

> Can every CA support issuing certs this way please? :)

I can't speak for other CAs, but we are definitely open to other CAs re-using technologies from Let's Encrypt to automate their operations. It would be even better for them to collaborate in developing the protocol. That's why we wrote ACME up using the IETF's document format, so that it can be developed in the IETF's open process with many stakeholders involved.

Not initially, but possibly in a future iteration.

OK, good to know.

Ultimately, in addition to these tools, it would be great to have ACME / LE support built into web server platforms, which are already running all the time.

I see, thanks, hence the emphasis on protocol not product. Great idea, let's hope it takes off, it'd be really nice to be able to just add a config for ssl_on and let the server deal with the rest. I suppose it's early days for discussions with server providers?

I don't know what the story is with that site

It's weird how old and busted CA sites are, almost without exception, I guess I shouldn't be surprised that a place selling certs doesn't even use them properly, but as you point out, they've issued letsencrypt.org, and that works fine. Good to know.

So Let's Encrypt certificates should work wherever that site works

This would be a great line for your how it works, rather than browser-trusted, which could mean anything really.

Thanks again for this great idea, looking forward to trying it out.

> I don't know what the story is with that site

Turns out they had the wrong certificate chain provisioned. Seems to be fixed now.

https://www.identrustssl.com/ authenticates fine for me in both Firefox and Chrome, and the certificate issuers for both that site and https://letsencrypt.org/ is in fact the same. I did notice that the IdentTrustSSL certificate has been issued yesterday, so this might be an issue of wrong clocks on your end.

They fixed it a few hours after my comment

What kind of impact is Let's Encrypt going to have on the CA industry? I'm not that familiar with the current state of the CA companies, nor do I understand this industry well enough to know if this is going to be a major hit to them or not.

Is there any reason why a company would prefer a CA other than Let's Encrypt?

Insurance, guarantees, EV certs, doing business with a big trusted company. All reasons to stay with your regular CA.

(Personally I don't care about any of those reasons - I just want my website to be SSL powered with an official cert and modern cipher configuration.)

The impact depends largely on their ability to get their root certificate into all of the browsers. It'll be interesting to see what happens with older versions of browsers as well, since if they start with a brand new root certificate then I'm not sure what happens with the older browsers.

If they can get their certificate into all of the browsers then it's possible they could achieve broad adoption for domain-verified certificates. There will still be a market for other validation types (organization validated and extended validation, for example) though.

> since if they start with a brand new root certificate then I'm not sure what happens with the older browsers.

IdenTrust will cross-sign Let's Encrypt root cert. I imagine they will keep it cross-signed, for backwards compatibility, once LE has their root cert in all the browsers.

You can't exactly undo cross signing without creating a new root CA - at some point they'll probably stop sending their root CA with the handshake (which is required when cross signing).

It will cost existing CAs a lot of business. We already had free certs from StartSSL, but they were for non-commercial purposes only.

I imagine a lot of shared hosting companies who currently resell SSL certs to their own customers will be switching to this next year.

I will certainly use them, and will only recommend them and nobody else. The only reason I'd ever look at one of the old CAs now, is for EV certs. But 99% of the time, people don't need an EV cert.

It's very, very hard for traditional CAs to compete with free, trusted in all major platforms and with dead simple set up. Hopefully this sort of scheme, combined with the added trust of Certificate Transparency, can kill off most traditional CAs.

The only reason I would still buy 1 certificate is for wildcard support.

Wait. Where can I get free certs today? Or did you mean once this service goes live?

I've used StartSSL, but somehow messed up the process and can't issue a new cert unless I pay to revoke the current. Even then their free certs expire in a year.

The only other free cert I found was from Comodo, but it expires after 90 days.

So, I wouldn't exactly say the only reason to pay for a cert is for wildcard support.

Yes, I was saying once this service goes live. But currently I've had 0 issues with StartSSL including renewals and getting multiple certs for a single domain. You do not need to revoke to get more certs from it in my experience at least. Paying for certs is just generally pointless right now even.

You can use a different dummy subdomain as the first entry to issue another cert, adding the subdomains you really want as secondaries. See https://kuix.de/blog/index.php?entry=entry140827-231120

Sorry for the newbie question....

So if I have apache running http://example.com on port 80 and I follow the instructions ($ lets-encrypt example.com)

Will Apache now be correctly serving encrypted traffic on port 443 with a cert for https://example.com ?

That's the idea. It assumes you are using an OS with a package manager, and letting it manage your software and (to some extent) config files.

And if you don't, or if you don't want to, it is easy to configure Apache or any web server manually.

All you really need are three things:

* the letsencrypt command line tool that will do the API dance to request the certificate

* a file in your web site root with a ownership verification token or a DNS record with said token

* a configuration file snippet for your server

I'm sure all of this will be documented very well.

Nice, thanks. (I'm running on Ubuntu, so should be good)

The ultimate vision is to make it even easier than that -- you set the "turn on HTTPS" option, and the platform auto-configures HTTPS with a certificate and appropriate ciphers. That will require upgrades to apache, nginx, IIS, etc., though, so in the meantime, we have the "lets-encrypt" script to semi-automate things.

So going from a single command to a different single command? How much simpler could it get?

Great project! Please also provide a yum repository and instructions (and any others you feel are popular enough). You may want to look at the way SSLMate does it, with an operating system drop down selection (Debian, Ubuntu, RedHat, Arch, Mac, Other).

We are actually hoping to have packages shipping from the official OS repositories, so you won't even have to get the package from us. (If anyone wants to help with this aspect, please get in touch.)

Is it possible to get new packages into Jessie post-freeze?

Generally not into the Debian repos, though it's possible the release manage could approve it.

You can pin other releases for specific packages, though, and if this is well-designed it should have minimal other dependencies. Ideally it's simply requesting and installing a key.

I don't think it would make sense to start shipping this package in operating systems before public cert issuance starts, which is currently expected to be around next summer. It would be fairly confusing to web developers to be encouraged by the OS to run the client, only to have it immediately inform them that there are no CAs yet able to issue certs to them!

Does this kill the business model for normal CAs, or is there something worth going to another CA for?

Also, how trivial/hard will it be for a state agent to generate its own certificate-signing traffic and use the Let's Encrypt CA to sign arbitrary domains of their choosing?

I'm thinking someone could spoof a DNS entry for the signing server and prove that they own any domain they want, is that prevented somehow?

If an attacker can spoof DNS, they can just create A records that point to their own server, and MITM from that.

Public key pinning would protect against that class of attacks: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...

Whose DNS layer? If they own the user's, no. If they own the server's, maybe, if they could convince the CA to sign a certificate they control. Otherwise, they couldn't really do anything.

It doesn't issue EV certs, so the business model for traditional CAs will be those.

I don't think EV SSL certificates have been a big success (though that's just a personal opinion rather something backed with specific data)

For me the differentiation in the browser presentation of EV against ordinary SSL doesn't provide much additional security. Most users don't notice the difference and even if they do, wouldn't remember which sites had an EV certificate, such that they would notice it changing back to non-EV

I wouldn't login to my bank's website if it didn't present me with green EV url bar. Same with paypal, amazon and basically anything to do with money has to have EV for me. I might be slightly paranoid, but I thought the point of ssl was EV.

Amazon doesn't have an EV cert.

CA also offer more expensive tiers of certificates, that include EV, or a warranty for commercial transactions.

I've never used those, and I don't know how relevant these are for companies, though.

Can someone clarify whether LE will check if there is already a signed SSL cert for the domain, and it contains the same information? For example, via the SSL Observatory?

Doing this would prevent a point in time vulnerability in DNS (temporary mitm showing a different IP for the domain) or direct mitm of the connection to the webserver. Otherwise the attacker could get a signed cert for https://peacenik.org, and then present that to activists that it mitms.

Yes, we plan to apply a few mitigations of this type. Part of the idea of the "Proof of Possession of a Prior Key" challenge is so that if a web server requests a cert for a domain with an existing certificate, we can ask them to prove that they hold that certificate.

https://github.com/letsencrypt/acme-spec/blob/master/draft-b...

This is a horrible idea... I have numerous certs for my domain and collecting them all to prove to you I own them is not going to be fun.

You wouldn't be in a very good position to revoke them then, would you? For example, if we had another heartbleed.

I have access to manage them, however the private keys are either in various services or non exportable with AWS...

Also, it seems possible that large scale DOS could be performed by applying for domains (via DNS hijack) before the owners do, causing significant administrative burden to recover from. I would suggest allowing simpler revocations within some multiple of the DNS TTL value for the domain.

I can also envision unscrupulous registrars pre-applying for LE certs for a fee, like $5.99 per month, and being very tardy and uncooperative about relinquishing control.

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

If something could "just" prove identity without worrying about MITM we would not need the whole RSA stuff.

I had a hard time un-packing this for a minute so I want to try and clarify.

The part about proving to Let's Encrypt is problematic for sites that do not already have TLS on the example.com domain. Any plain HTTP request that Let's Encrypt makes to example.com to validate that you've put up some content on the server is susceptible to a MITM attack. I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership.

The MITM problem with requests to example.com doesn't exist if example.com is already set up for HTTPS, which is probably why the examples on the technical description show requests for https://example.com/8303. I was confused about that at first because Let's Encrypt is largely targeted towards people without any TLS encryption yet.

> I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership.

FYI, CAs do this already (HTTP validation), but an easy fix is to generate a self signed cert and pass the fingerprint of it to the CA.

Not sure how the self-signed cert would make things better. Couldn't an MITM attacker do the exact same thing? Presumably, the MITM attacker would already be the party making the (fraudulent) request to the CA, so they could submit their own fingerprint.

I suppose you're correct, I wasn't thinking that the attacker would also submit the request. I guess if you're MITMing CA requests you're screwed anyhow.

You are positing a MITM on the CA though, which is a bit trickier than MITM'g a user, I would have thought?

I don't see how using TLS would prevent MITM in this case. TLS only prevents MITM if you know public key or if it's been signed by a CA, but neither is the case here.

Why can DNS not be spoofed when HTTP can? It seems to me that you need one to spoof the other...

Why caring at all about OCSP/CRL revocations that don't work anyway (https://www.imperialviolet.org/2014/04/29/revocationagain.ht...)? If you have an agent running on the webserver, you're 99% close to simply use short-lived certs. Just issue 1-week certs and be done with.

Getting to short-lived certificates is a goal, but the reality for now is that OCSP and CRLs are what implementations require, and what the CABF Baseline Requirements require. So we'll need to start with those.

I really like this and I am excited by the sponsor list. The self-signed cert notification in browsers is becoming more obnoxious every year.

How is this not really bad?

Suppose I somehow get control of a machine on the same network as a server that doesn't use Let's Encrypt. I can probably ARP spoof it pretty easily. If it has a signed certificate from a different CA, I can't MITM it without people noticing. Or I couldn't, until now! Because I can now "control" the server's responses, I can easily get Let's Encrypt to authorize a new key pair giving my control over that domain. I can now generate valid certs for my MITM keys.

If the server were already using Let's Encrypt, I couldn't create a new controlling key pair. The "How It Works" doesn't talk about that, but search the RFC for "recovery token". But if the server isn't using Let's Encrypt, what would stop me from doing this?

Of course, I'm actually on the other end of it. To project myself, do I really have to at least register a controlling key pair with Let's Encrypt and any other browser-supported CAs that adopt this protocol?

Will using a certificate from letsencrypt.org require any kind of agreement on the part of web site administrators or visitors to their web sites?

The CA's I've looked at have these agreements. I'd like to avoid binding myself or the visitors to my website to any legal requirements from a third party.

Note to self: Donate to EFF

Why leave for tomorrow what you can do today?

https://supporters.eff.org/donate