
Let's Encrypt: How It Works - espadrine
https://letsencrypt.org/howitworks/
======
dale386
Which browsers will trust Let's Encrypt certificates out of the box? There may
be a major backwards compatibility gap here.

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

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

------
grey-area
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/](https://www.identrustssl.com/)

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

~~~
bifurcation
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/](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/](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.

~~~
grey-area
_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.

~~~
bifurcation
> 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.

------
Simucal
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?

~~~
aeden
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.

~~~
Supermighty
> 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.

~~~
iancarroll
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).

------
grecy
Sorry for the newbie question....

So if I have apache running [http://example.com](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](https://example.com) ?

~~~
haroldp
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.

~~~
st3fan
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.

------
schizoidboy
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).

~~~
schoen
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.)

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

~~~
schoen
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!

------
drostie
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?

~~~
StavrosK
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?

~~~
sbierwagen
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...](https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning)

~~~
StavrosK
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.

------
angry_octet
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](https://peacenik.org), and then present that to
activists that it mitms.

~~~
bifurcation
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...](https://github.com/letsencrypt/acme-
spec/blob/master/draft-barnes-acme.md)

~~~
iancarroll
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.

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

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

------
venomsnake
> 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.

~~~
cakeface
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](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.

~~~
iancarroll
> 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.

~~~
organsnyder
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.

~~~
iancarroll
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.

------
giovannibajo1
Why caring at all about OCSP/CRL revocations that don't work anyway
([https://www.imperialviolet.org/2014/04/29/revocationagain.ht...](https://www.imperialviolet.org/2014/04/29/revocationagain.html))?
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.

~~~
bifurcation
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.

------
debacle
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.

------
adamtj
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?

------
interested2
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.

------
don_draper
Note to self: Donate to EFF

~~~
higherpurpose
Why leave for tomorrow what you can do today?

[https://supporters.eff.org/donate](https://supporters.eff.org/donate)

~~~
bifurcation
See also:

[https://sendto.mozilla.org/](https://sendto.mozilla.org/)

------
freerk
Apparently they will use the same certs as implemented on letsencrypt.org, so
the free certs will work without error on every client which trusts the "DST
Root CA X3" CA. Can we collect a definitive list of clients which include this
CA certificate? Similar to the list for StartSSL
([https://forum.startcom.org/viewtopic.php?f=15&t=1802](https://forum.startcom.org/viewtopic.php?f=15&t=1802)).

Firefox: Mozilla added the certificate in NSS 3.11.9 on 2008-01-31, see
[http://www-archive.mozilla.org/projects/security/pki/nss/nss...](http://www-
archive.mozilla.org/projects/security/pki/nss/nss-3.11.9/nss-3.11.9-release-
notes.html) and
[https://bugzilla.mozilla.org/show_bug.cgi?id=411299](https://bugzilla.mozilla.org/show_bug.cgi?id=411299)
So Firefox starting with 3.0 works

Chrome: When the first Chrome came out it used Mozilla NSS which already
included the certificate. Now Chrome uses the OS key store:
[http://www.chromium.org/Home/chromium-security/root-ca-
polic...](http://www.chromium.org/Home/chromium-security/root-ca-policy)

Microsoft: The certificate is trusted by default since at least IE8
([http://www.herongyang.com/PKI/HTTPS-IE-8-Trusted-Root-CA-
Cer...](http://www.herongyang.com/PKI/HTTPS-IE-8-Trusted-Root-CA-Certificate-
Authorities.html)) and Windows automatically updates the certificates, see
[http://technet.microsoft.com/en-
us/library/cc751157.aspx](http://technet.microsoft.com/en-
us/library/cc751157.aspx)

Apple: Since iOS 2 (2008-07-11) ([http://support.apple.com/en-
us/HT2185](http://support.apple.com/en-us/HT2185)) and at least since OS X
Mavericks ([http://support.apple.com/en-
us/HT203120](http://support.apple.com/en-us/HT203120)), but probably way
earlier.

Java: Yes:
[https://gist.github.com/saltlakeryan/8479238](https://gist.github.com/saltlakeryan/8479238)

~~~
iancarroll
Chrome does not use NSS. It uses the underlying OS root store.

~~~
freerk
Sure, fixed it. Thanks!

------
tedunangst
Unfortunate choice of wording. From the web page:

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

From the "RFC" on github:

> In the background, the web server contacts the CA and uses ACME to request
> that a certificate be issued for the intended domain name(s).

> Once the CA is satisfied, the certificate is issued and the web server
> automatically downloads and installs it, potentially notifying the operator
> via e-mail, SMS, etc.

This really sounds like they are generating the key pair, not just signing it.
I think (hope) that's not the case, but clarity on this issue is pretty
important.

~~~
adamtj
They're generating the certificate, not the keys. Those are different things.
You can probably think of the certificate as the computer equivalent of photo
ID for the server.

They both show who you are (Driver's License: your name, cert: hostname), what
you look like (DL: photo of you, cert: the key's fingerprint) and provide
proof that they are genuine (DL: difficult and illegal fake, cert: practically
impossible to do the math to forge a signature).

Note that they mention certificate singing requests. If the CA generated the
keys, it wouldn't also need a CSR. It could just generate and send you the
public and private keys and the signed certificate for them. However, it does
need some information about the keys it's signing. You provide that
information in the form of a CSR.

~~~
grey-area
Looks to me like it generates the keys locally OR you can specify the keys if
you like. But since the private key doesn't leave your server, it doesn't
really matter either way.

[https://github.com/letsencrypt/lets-encrypt-
preview/blob/mas...](https://github.com/letsencrypt/lets-encrypt-
preview/blob/master/letsencrypt/client/client.py)

------
amatix
Does it deal with the case of SaaS apps for customer domains? Eg. Customer
example.com rocks up to my SaaS app and wants to use myapp.example.com -
currently creating

~~~
duskwuff
Yes. As the service provider, you can create a DNS record to verify
"myapp.example.com", which is sufficient to get a certificate issued for it.

For a setup like this, you may still be better off getting a single wildcard
certificate for "*.example.com", which (as far as we know currently), isn't
possible through Let's Encrypt. But it's certainly possible to get these
certificates through Let's Encrypt.

------
stormbrew
Here's a question I haven't seen anyone ask: What about email servers
(SMTP/IMAP)? I need a good cert for that more than I do for https, personally.
I could obviously have a web server up _just_ to succeed at the
challenge/response and get a certificate, but I actually just try to avoid
running webservers at all these days, to be honest. I'm also not 100% that
certificate would work.

~~~
yuriks
The technical overview mentions that there can be various different kinds of
challenges, so presumably you could use a DNS based one or even an email based
one if it's implemented.

~~~
bifurcation
That's correct. Also, if you've got an A/AAAA record for the domain name in
question, you could run an ACME client on that box that spins up a temporary
web server. That's what the node-acme demo client does.

[https://github.com/letsencrypt/node-
acme/blob/master/lib/acm...](https://github.com/letsencrypt/node-
acme/blob/master/lib/acme.js#L174)

------
radiospiel
I am somewhat excited about letsencrypt, but isn't ownership verification via
DNS not a bit, hmm, strange? After all, a proper certificate should defend
against MITM attacks; so if an attacker would be able to take control over the
target's DNS, he could easily create a certificate, which looks legit for all
intended purposes. Or do I miss something in that regard?

~~~
Wilya
Ownership verification is already done via DNS by existing CAs. If an attacker
has full control over your DNS, he can already change the DNS records and
trick a CA into delivering him a genuine certificate.

This isn't really a MITM attack.

~~~
mappu
What existing CA's offer this?

The ones i've used (godaddy, startssl, namecheap/ssls.com
rapidssl/positivessl) all wanted email verification iirc.

EDIT: of course that's equivalent to verifying the MX. Never mind!

~~~
Wilya
Gandi offers three validation methods:

* DNS: you need to add a specific record to your DNS zone * File: you need to add a specific file to the root of a HTTP server listening on the domain name * Email: they send an email to admin@ on the domain

All three are pretty much ways to check that you are the person in control of
the associated DNS.

------
nnnnni
The problem with their "howto" is that it completely ignores the fact that
things like NAT and PAT need to be set up. Sure, the public IP's port 80 could
be PAT-ed to the internal IP's port 80, but running "lets-encrypt example.com"
can't magically PAT port 443 straight out of the package manager like that.

Still, this is a great idea...

------
dewey
Is this a wildcard certificate and will it cover subdomains that way? Couldn't
find anything on the site clarifying that.

------
smilepet_26
This is super awesome. It will help drive a better and secure web. Hats off to
LetsEncrypt team.

------
rcthompson
So is this something I can use in place of an auto-generated self-signed
certificate for that headless linux box that I have running in the back of my
closet and which I optimistically refer to as "my web server"?

~~~
zanny
You can use startssl for that right now. They provide one year free
noncommercial certs. By the time that one expires letsencrypt will be live.

------
z3t4
Wouldn't it be much easier if lets-encrypt just created the .crt .key files!?
Rather then set it up automagically.

You could have it run once a year via crontab.

I would like to keep the control of my .conf files.

~~~
jdkasten
That will be an option.

Also, the current implementation only changes the SSLCertificateFile directive
if you provide your own --key, --csr and already have an SSL vhost for the
domain. (This one change is logged.)

------
haroldp
It seems like the one thing this doesn't/can't address is the IP shortage.
Does help much if example.com is virtual hosted on the same IP address as 100
other sites?

~~~
cmwright
The SNI stuff
([http://en.wikipedia.org/wiki/Server_Name_Indication](http://en.wikipedia.org/wiki/Server_Name_Indication))
helps with this if you can do without XP support.

~~~
sp332
It's not really XP that's the problem, but IE6. Firefox and Chrome support SNI
even if you run them on XP.

~~~
icebraining
All IE versions on XP, alas.

------
Tepix
Can it be used with tor to sign .onion hidden sites?

------
GordyMD
Really excited about this!

------
Animats
_Keep track of when your certificate is going to expire, and automatically
renew it._

Or, all you have to do is let this new piece of software run periodically on
your secure server. What could possibly go wrong?

~~~
jeffreyrogers
I take it you've read the source code of Apache and Nginx then and confirmed
that they aren't doing anything malicious as well? :)

In any practical security system you are always going to have to trust that
certain components are doing what they say they're doing. Fortunately, Let's
Encrypt is from a reputable group, and sponsored by organizations with good
reputations (Mozilla, EFF, etc.), which is about as good as you can hope for.

~~~
tedunangst
Many people draw a line between one time trust and continuous trust. If this
thing can update the certs on my server whenever it likes, that's
substantially more trust than permitting it to install a cert exactly once.
If, for example, it has a bug that permits a malicious upstream to overwrite
arbitrary files, the window of vulnerability expands from "the CA is pwned
this instant" to "the CA will at any future time ever be pwned".

~~~
organsnyder
Easy fix: Run the tool as its own user, give write permission to cert & key
files to that user. If you're really paranoid, run it in a jail that only has
access to those files. No different than proper security for any other system
process.

