
Let's Encrypt Overview - baby
http://www.cryptologie.net/article/274/lets-encrypt-overview/
======
diafygi
FYI, if you don't want to install the official Let's Encrypt client on your
production server, I created a simple python script that will automate the
ACME process for you. It doesn't have to run on your server, and it doesn't
ask for your private keys.

[https://github.com/diafygi/letsencrypt-
nosudo](https://github.com/diafygi/letsencrypt-nosudo)

The only thing that has to be run as sudo on your production server is a
simple python one-liner that temporarily serves the required file. The script
prints out this one-liner so you can copy and paste it into your server's
terminal, then kill it when the challenge is done.

~~~
garrettr_
How is this different from/superior to Let's Encrypt's built-in "standalone
authenticator"? [0]

[0] [https://github.com/letsencrypt/lets-encrypt-
preview/blob/mas...](https://github.com/letsencrypt/lets-encrypt-
preview/blob/master/letsencrypt/plugins/standalone/authenticator.py)

~~~
diafygi
The standalone authenticator still requires (1) installing/running the
letsencrypt client on your production server, (2) letting it run as root, and
(3) letting it access your private keys. My script requires none of these
things.

------
schoen
This is a lovely and very clear summary!

Two notes, which I also sent to the author:

* Renewal does work already, it's just not documented anywhere. There is a script that can check when your cert is a specified amount of time from expiry, get a new cert, and subsequently deploy the new cert by updating symlinks. This mechanism works now, if the script is run from cron.

* You can use the client on a machine that doesn't have Nginx or Apache, it just won't be able to _install_ the resulting cert. But the client's standalone mode can obtain the cert and save the associated files in the current directory. (In this case, they also won't be enrolled for automated renewal by the renewer script.)

~~~
hencq
How would it work on for instance App Engine, where you can't really run a
script on the server? I guess you'd have to manually do the validation step,
but will it do any of the other steps automatically still?

~~~
schoen
Depending on the nature of the control that you have over the site, you might
need to get the hosting provider to do it for you (some of them are probably
going to integrate Let's Encrypt) or you might be able to make the changes
manually to prove control of the domain.

If people think of useful integration features for particular platforms, we
can take patches, or those platform developers can write their own clients.
:-)

------
ikeboy
>One of the common one is to upload a certain file at a certain address of
that domain.

I wonder if this can be socially engineered/tricked to gain a certificate for
someone else's domain. Like, I've seen at least one service (Majestic Seo)
that asks you to upload a document to your domain to get certain services. Now
that this (will soon) exist, any such service that someone uses can generate a
cert and MITM the site.

Also, if they're verifying over http, couldn't _anyone_ just mitm the verify
connection? Well, anyone with access to any computer along the route between
Let's Encrypt and whatever domain they want.

~~~
gandarojin
I guess that’s why they will probably not use HTTP for the verification. Why
would they? The client already generated a certificate and sent it to Let’s
Encrypt, they can already use TLS.

~~~
ikeboy
But you don't know that this is the client. If all you're trusting is the cert
they already generated, how do you know it's not an attacker?

~~~
gandarojin
You’re right, I did not think this through…

------
derefr
Question: is the X.509 system set up in such a way that one of these issuers
could give me a _free_ code-signing cert, or a _free_ CA cert for signing
client certificates?

Because, as far as I understand, the answer is no: signing certs have no sense
of signing "for an origin". If a CA issued me a CA cert, I could use it to
create a signed cert for microsoft.com. Which seems nonsensical.

All I want is to get issued a CA cert that lets me sign arbitrary things
_within my domain 's scope_. Basically, the X.509 equivalent of a DNS NS
record, delegating responsibility for making assertions about that domain (and
only that domain) to "my" CA. Why is that so hard?

~~~
mike_hearn
_> Why is that so hard?_

It's hard because for the longest time (e.g. between 1995 and about 2010)
nobody really cared about SSL. It was a box you ticked when implementing a
login form or a credit card purchase page. So the infrastructure was
neglected, progress was lethargic and generally everything bitrotted.

This can be seen quite clearly in the state of OpenSSL, in the number of
exploits in TLS stacks that started appearing in recent years once academic
attention was focused on them, etc.

The feature you want is called name constraints and for the longest time was
not really implemented anywhere. So that's why CAs don't do it. Also: this
would be a highly niche feature and CAs, like any businesses, weigh up
implementation cost vs potential market size and risk when choosing what to
support.

That doesn't mean it will never happen. It could, now there's a lot more focus
on the SSL infrastructure in the wake of Snowden.

~~~
what_the_diffie
Also, openssl didn't (or doesn't) appear to care about high-reliability
software engineering and the IETF TLS Working Group didn't care about
producing a minimum-featured spec that is not overly difficult to implement,
maintain and support in the real world. Instead, TLS has become a kitchen-
sink, feature-hoarding, experiment-in-production jambalaya.

------
jokr004
I love that the author of this article actually got out a pen and paper, drew
out that diagram and photographed it. Great summary, looking forward to using
this service!

~~~
what_the_diffie
Give it a few minutes, someone will make an OCR to ASCII art app.

------
StavrosK
Does anyone know when exactly it will be released? It says Mid-2015, and it's
almost past that.

~~~
ohitsdom
I'm really excited about this project, but a lack of steady updates and
communication on release date are really hurting it. Hopefully they release
soon and make this a moot point.

~~~
baby
They just released a blog post about generating the certs. That means they are
getting their. From looking at the code they have most of it in place, they
just lack a few features, and testing. IMO it shouldn't take too long now. The
first commits date from october of last year.

------
davidgerard
We are desperately looking forward to this being available so we can SSL all
our dev sites and still be able to test them on our phones (which are a bit
hard to get one's own CA cert onto).

~~~
michaelt
It sounds like Lets Encrypt is going to require a site to be publicly
available for them to give out a cert for it. They'll tell you to put a
certain file at a certain location to demonstrate that you control the domain.

So unfortunately it'll only help with your dev sites if they're available on
the public internet.

~~~
teddyh
No, that is only one of the _four_ methods of proving domain ownership; see
the ACME protocol specification:

[https://letsencrypt.github.io/acme-
spec/#rfc.section.6](https://letsencrypt.github.io/acme-spec/#rfc.section.6)

~~~
schoen
However, the methods described there that don't involve a domain validation
step all specify prior ACME usage; that is to say that at least the first time
you get a cert from an ACME CA with policies akin to those described here, you
must always complete a DV step with DVSNI or Simple HTTP (which do require a
publicly-visible server with a publicly-visible domain name).

~~~
teddyh
What about the method in section 6.4: DNS? That certainly does _not_ require
either a prior ACME usage or a publicly-visible server.

~~~
schoen
That's a good point.

I don't expect the Let's Encrypt CA will be willing to help keep servers (or
certs issued to them) a secret -- for example, the certs are likely to be
published in Certificate Transparency! -- but you're right that the ACME DNS
challenge doesn't require the server to be publicly accessible and doesn't
even require the underlying subject name to exist in the publicly-visible DNS.

------
BinaryIdiot
Interesting but will there be a way to generate the certs and download them
myself versus running an application as root on my servers? I would much
prefer not to run their application as root on my servers :)

~~~
StavrosK
Alternatively, it could have a non-sudo mode that would give you the certs and
configs in a directory and tell you where to copy them (or generate a simple,
five-line bash script to copy them).

~~~
baby
[https://github.com/diafygi/letsencrypt-
nosudo](https://github.com/diafygi/letsencrypt-nosudo)

~~~
StavrosK
Very nice!

------
kstenerud
I'm a bit confused on the issue of certs because I've heard that they don't
work for subdomains, so can anyone tell me:

If I get a cert from someone like letsencrypt for a domain I control, for
example "xyz.com", will that same cert also work for "wiki.xyz.com",
"blog.xyz.com", "someotherthing.deepdomain.xyz.com" and so on?

I'm interested because I use jwilder/nginx-proxy and then have a docker
container for each of my webapps, each connected to a different subdomain
(video, music, rss, vm, desktop, files, etc).

~~~
garrettr_
There are several ways to resolve this issue:

1\. Get a separate certificate for each subdomain. Let's Encrypt makes this
feasible since the certs are free and require a minimum of human overhead to
obtain.

2\. Get a single certificate that covers each subdomain by using Subject
Alternative Names, which are currently supported by Let's Encrypt.

3\. Get a wildcard certificate for "*.xyz.com". Let's Encrypt does not support
this and I do not think it plans to, at least not in the initial release.

The main question is - is the set of subdomains known before-hand, or is it
highly dynamic? If it is fairly stable, then options 1 or 2 will work well for
you; otherwise, you probably want option 3.

Choosing between option 1 and 2 usually depends on the details of your
infrastructure and your threat model. For example, are all these subdomains
served from the same server or different servers? If it's the same server, you
might be more inclined to use 1 cert for all of them (option 2) since it will
be easier to manage. Do all the domains have the same threat model? For
example, what if you run blog.xyz.com on one server and billing.xyz.com on a
separate, hardened server. In that case, you would want option 1 because if
you used the same cert on both servers, obtaining the private key from the
less-secured blog.xyz.com server could be used to attack traffic for
billing.xyz.com.

~~~
kstenerud
This is just for my home system, so that I can access everything via https
without that annoying ssl cert warning. It's all run from a single server in
the closet. I have an nginx instance facing outside, with http redirecting to
https, and then each individual app accessed based on what subdomain you used
(rss.xyz.com to get to my rss reader, vm.xyz.com to access my virtual machine
management console, etc). At the moment I have 7 webapps running, and am in
the process of adding an 8th.

The subdomains are somewhat dynamic, since I'll add more whenever I add a new
webapp to the server.

~~~
garrettr_
In that case, sounds like you probably want a wildcard. Also, if this is just
your home system and you are the only person who needs access to these
machines, why not use a VPN instead? Makes more logical sense, easier to
configure, and you can do more than just webapps.

~~~
kstenerud
Oh I have a VPN set up already. This is mostly so that I can access certain
things from, say, a friend's media center or computer.

------
ohitsdom
I saw in an earlier thread that wildcard certs won't be supported at first,
but possibly in the future. An additional comment was made that wildcard certs
wouldn't be necessary once the cert issuing/renewal process is automated.

My question is: wouldn't wildcard certs be faster if the behavior on your site
skipped around different subdomains? One certificate for all vs individual
certs for each subdomain. I may be way off, I'm a novice when it comes to
SSL/TLS handshake so please correct my ignorance.

~~~
derefr
Maybe the question is wildcard vs SAN certs. With automated cert
issuing/renewal, they could theoretically talk to e.g. Cloudflare's API to get
your DNS records, if you're with them, and then regenerate a new SAN cert
containing exactly the subdomains you really have whenever that list of
subdomains changes. Which is _probably_ more secure in some way I don't
understand.

You're right about the "just using a bunch of separate certs" solution being
slower, though, especially with HTTP/2 (which, because of origin combining,
uses exactly one real socket _per TLS cert_.)

------
lebrad
This is a really useful breakdown of Let's Encrypt and its scripted process
for procuring certificates. It's ironic though that cryptologie.net is not run
over https! They should use Let's Encrypt.

~~~
ikeboy
[https://www.cryptologie.net/article/274/lets-encrypt-
overvie...](https://www.cryptologie.net/article/274/lets-encrypt-overview/)

They should use HSTS and redirects, though.

------
stephenr
It would be nice if they offered certificates for S/MIME signing + encryption
too.

Edit: sed "s#g/e#g + e#g"

~~~
TazeTSchnitzel
It took me a moment to realise that wasn't a sed command replacing "MIME
signing"(???) with "encryption".

~~~
stephenr
Ha! I didn't even notice that as I was typing!

------
ohitsdom
Good question from the page's comments- will this work for different sites run
on one server? I'm thinking of all my side projects that have sites up,
they're all run off the same $9/month Apache server. Can I get individual
certs for each domain run off the server?

~~~
bifurcation
Yep, that should work fine. You'll just need to do the validation process for
each domain.

------
lurkinggrue
Does anybody know how this handles multiple domains and multiple domains on
one IP?

~~~
schoen
You can get certs that are valid for multiple domains, using subjectAltName
(SAN). The client can request multiple names at once and the resulting cert
will be valid for each.

------
kyledrake
Has anyone tried a ruby client library implementation yet? I've looked at the
spec and it's pretty complicated. I'm not sure I'll have the time to devote to
it unfortunately.

~~~
StavrosK
Why rewrite it? What's wrong with the current implementation?

~~~
kyledrake
The current implementation is fine for people running nginx servers with a
single domain, but for anyone trying to engineer this via a web application
for more than one domain, this is not sufficient for proper tooling.

~~~
StavrosK
Oh, you mean an actual gem? I see. I hope the current implementation is
importable from Python, as well.

~~~
kyledrake
This python script is informative:

[https://github.com/diafygi/letsencrypt-
nosudo/blob/master/si...](https://github.com/diafygi/letsencrypt-
nosudo/blob/master/sign_csr.py)

A good start for trying to figure out the workflow.

------
hueving
Can someone explain why the CSR is exchanged over https? The whole point of a
CSR is that an adversary can't fake it and get a key that works for you and
the adversary.

~~~
dadrian
The CSR is signed by the key that is going to be used for HTTPS on the website
requesting a certificate. If the CSR wasn't transmitted over HTTPS, since the
Let's Encrypt CA has no idea what your key is, a network adversary could
replace your CSR with one containing an attacker-controlled key.

------
makmanalp
So now that you can even get EV certs for free, what does this mean for the
SSL Cert industry? Are they quaking at the knees or do they not care?

~~~
hrbrtglm
This github issue explains why they won't deliver EV certs :
[https://github.com/letsencrypt/lets-encrypt-
preview/issues/3...](https://github.com/letsencrypt/lets-encrypt-
preview/issues/342)

------
ex3ndr
As I understand they use HSM for signing certificates. What will be if they
destroy HSM? How they can continue to operate?

~~~
joshmoz
HSMs can typically duplicate keys to other HSMs (though usually only other
HSMs from the same vendor). All of the Let's Encrypt private keys are stored
on multiple HSMs.

~~~
cpt1138
Anyone know what HSM vendor they are using?

