
Running the Let's Encrypt Beta - technion
https://lolware.net/2015/10/27/letsencrypt_go_live.html
======
gingerlime
> Now you've still got a hurdle to overcome. In order for nginx to serve out
> the right certificate chain, you'll need to bundle the intermediary. So you
> should wget that from The official Certificates Download page.

A small suggestion - instead of wget-ing the certificate chain from the page,
I would use the cert-chain-resolver tool[0]. It's super simple, but highly
effective bash script that wraps around OpenSSL / wget and does all this for
you.

[0] [https://github.com/zakjan/cert-chain-
resolver](https://github.com/zakjan/cert-chain-resolver)

~~~
zachberger
Had the author used the official tool, the chain would be automatically
downloaded. [0] Additionally the author is over-weary of the official tool
complaining it modifies server conf files. In fact the default option
recommended to beta users, './letsencrypt-auto auth', simply downloads the
certificates and doesn't touch conf files at all.

[0]
[https://letsencrypt.readthedocs.org/en/latest/using.html#whe...](https://letsencrypt.readthedocs.org/en/latest/using.html#where-
are-my-certificates)

------
mholt
Let's Encrypt is already very easy to use, but for those looking for a totally
transparent way to use it, keep an eye on Caddy. It's a web server with Let's
Encrypt built in to serve HTTPS by default:
[https://caddyserver.com/blog/lets-encrypt-progress-
report](https://caddyserver.com/blog/lets-encrypt-progress-report) \- no extra
tools or configuration needed.

Just a few details left before it's ready:
[https://github.com/mholt/caddy/issues/284](https://github.com/mholt/caddy/issues/284)

~~~
motoboi
Probably would be a better ideia, in terms of software reusability and
security, to put a lets encrypt module on apache or nginx rather then put an
apache or nginx module on lets encrypt.

------
mafro
It seems a lot emphasis with Let's Encrypt is on the automated cert
registration/installation tools.

Am I missing something when all I really want are the free certs?

~~~
Natanael_L
A big part of the reason is that free certs exists already (startssl), but it
takes A LOT extra work to set it up.

The whole point here is that eventually the deployment tool can be integrated
in existing server software, such that when you set up your server on your
domain, requesting a certificate can be an automatic step that the sysadmin
and web developer don't even have to think about.

This makes sure encryption will eventually be deployed by default everywhere,
because it is literally easier than not to.

~~~
AndyMcConachie
I can't use StartSSL because my DNS registrar doesn't populate whois the way
they like it. Also, anyone relying on some sort of whois privacy cannot use
StartSSL.

~~~
TurkTurkleton
I didn't have any problems using StartSSL for any of my domains, and they all
have whois privacy.

~~~
aroch
Depending on the privacy providers, the protected email changes after every
email it receives. This causes startSSL to deny your certificate requests

------
collinmanderson
"The performance complaint is long debunked" \- There are still performance
hits.

\- There are still two additional round trips on the first https connection vs
http. That means there are still cases where http is faster than https, even
when using spdy/http2.

\- Also, the initial (before an HSTS header is seen) redirect from http ->
https when typing in a domain name adds to the overall first load time.

Even after the performance and maintenance issues, we still have the local-
development issue (developing on 127.0.0.1). You still need to own a domain
name to get a cert from Let's Encrypt.

I'm happy Let's Encrypt is making certs easier so we can start focusing on the
_next_ hurdles of massive TLS adoption. :)

~~~
TazeTSchnitzel
> There are still two additional round trips on the first https connection vs
> http.

Not with HSTS preload.

~~~
toast0
HSTS preload doesn't reduce the preamble to a TLS connection:

You have to send the TLS client hello, wait for the TLS server hello back (1
Round trip), send the handshake finished, wait for the server handshake
finished (2nd round trip), before sending application data. TLS 1.3 is
supposed to help with that (although I haven't read the spec), but that's
probably just bringing it down to one extra round trip in the common case. Add
tcp (one round trip), and http (one round trip), and it's four round trips,
twice as many as plain http.

If you are serving us users on broadband, and you only have servers on one
side of the country, half of your users are going to see about 80 ms round
trip, so https slows down your first page load by 160 ms, even before you
worry about encryption. If you have users around the world, and servers in
only one location, you're likely to see many users with 250ms or 300 ms, an
very simple https page (short request, short response) is going to take a
minimum of 1 second (2 round trips for tls, one for tcp, and one for http),
and if your users are on congested mobile networks, ouch.

~~~
collinmanderson
It doesn't reduce the TLS connection, but it reduces two round trips for the
HTTP->HTTPS redirect. If the link is https in the first place then it's not a
problem, but if you type in a domain name it will try HTTP first before starts
the TLS connection.

------
ludbb
I can't wait to see how this industry will change after LE is fully running --
this is amazing. Are there any stats about the different cert types, specially
about their deployment count and usage over time?

One thing I don't understand about the guarantees given by CAs is the one
about the warranty, like the "$1,750,000 Warranty" from Comodo. How exactly
can they provide that? Or is that some sort of MUST have if you want to
partner with an insurance company?

~~~
vtlynch
What types of stats are you looking for? "Different types" meaning different
CAs?

The warranty is odd. Its required to provide a warranty in certain situations
by the CA/B Forum (industry standards body). This is partially because some
countries laws require they be provided for the class of products/services
that SSL falls under, so requiring it from everyone sort of levels the playing
field.

But the large CAs (Symantec, Comodo, etc) are big fans regardless. They can
advertise this preposterous "warranty" which protects you, and usually the
customer does not ask too much about it and just likes the sound of it or
assumes it will cover them if they are hacked (which is not what its for). It
actually just covers some very small situations where the CA mis-issues your
certificate.

Some lawyers and experts at TrendMicro and Firefox found that due to how the
terms are written there is basically no way the end-user would ever actually
see that money. Those insurance warranties have never been used.

~~~
ludbb
About the stats: by "specially about their deployment count and usage over
time" I meant the number of certs deployed by cert type (DV, OV, EV) and how
has their usage progressed over time? If the second part is not clear, let's
say that 5 years ago EV certs represented 2% among issued certs, and today it
represents 1.4% -- I'm looking for historic data about this.

Thanks about the warranty clarification, so it only protects you if the /CA/
does something bad to you? In that case wouldn't it possible to sue the entity
for, possibly, an even larger sum?

~~~
vtlynch
Stats like that may be available but I can not think of anything at the
moment. I will look into that and let you know.

>Thanks about the warranty clarification, so it only protects you if the /CA/
does something bad to you? In that case wouldn't it possible to sue the entity
for, possibly, an even larger sum?

Yes, I believe the damage has to be due to the CAs behaviors. The two major
situations I can think of that would qualify would be:

1\. The CA issues a certificate for your domain/company to someone who was not
authorized. However I would think that cert would then have to be used in an
actual attack so you could quantify your damages.

2\. The CA is breached in some way that allowed your certificate to be
compromised or allowed an attacker to create a fraudulent certificate for your
domain/company.

That is a very good question about suing the CA for other damages. I am not
aware if this has ever occurred but it certainly seems like it could.

------
lucideer
This looks like the same thing that was announced over a week ago? What's
changed?

~~~
jamies888888
There's a beta client now.

~~~
ddworken
They have started sending out invites to people who wanted to join their beta
program. So now they are actually issuing certs.

------
mtgx
Is this something they can implement themselves?

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

~~~
tokenizerrr
The official client does not have to be ran as root. You can do the manual
auth mechanism which just gives you the certificates. The authentication
process against letsencrypt will give you a file to put in your webroot.

~~~
diafygi
Doesn't the official client need to have access to your private key?

------
noja
Don't touch my OS! If you want to install some packages, tell me to install
them (or ask me!). I don't like this script so far.

~~~
aroch
You ran a setup script, as root, without looking at it and are upset it
installed things? Shouldn't you be more upset that you didn't take the time to
look at what it does before running it as root?

~~~
noja
It's standard behaviour for a script to exit with an error if it can't find
the dependencies it needs to run.

~~~
aroch
letsencrypt-auto is specifically there to setup and update the entire
environment for letsencrypt to work. If you don't run it as root, you get
prompted to elevate. If you're at all concerned about what setup its doing,
the code is eminently readable and a few seconds of perusal would direct you
to the bootstrapping scripts
([https://github.com/letsencrypt/letsencrypt/tree/master/boots...](https://github.com/letsencrypt/letsencrypt/tree/master/bootstrap))

Running letsencrypt-auto is no different than running one of the curl | sh
installers; they serve the same purpose. Getting you up and running under the
assumption that you may be missing bits and pieces.

~~~
noja
I'm not concerned about what it is doing, I am complaining that the script
works differently to what I expect.

------
hsivonen
When should one expect to see an ACME client built into nginx so that you
could specify an ACME-enabled CA instead of a key file right in nginx config
and have nginx itself do the rest?

------
meapix
What kind of insurance does letsencrypt provide in case of data breach? isn't
that the whole point of certificate authority?

~~~
pmlnr
That should be the job of an insurance company, not a certificate authority.

Also, an https cert has nothing to do with data breaches :)

~~~
peterwwillis
Breach of the CA, not the web host. If the CA is breached there is no point to
the encryption.

~~~
charlesbarbier
It wouldn't break encryption because you don't give away the private key when
requesting a certificate from a CA.

It would definitively compromise the identity/trust part of it.

~~~
peterwwillis
Let me rephrase with a quote from the public-key cryptography wiki:

 _" An attacker who could subvert any single one of those certificate
authorities into issuing a certificate for a bogus public key could then mount
a "man-in-the-middle" attack as easily as if the certificate scheme were not
used at all."_

------
runn1ng
I don't want to sound mean, but that script seems anything but easy to me

~~~
tbrock
I agree. Why not just have an interface like encrypted =
encryption.encrypt(bytes)? Deal with getting a certificate and storing it for
me, the reason people don't encrypt everything today is because it's a pain in
the ass.

------
tenfingers
> With Automatic Web Server Configuration > > This will automatically
> configure Apache and Nginx servers > with your new certificate.

I wished they wouldn't do that at all. There's a world of hurt in trying to
pretend to configure the cert on the current system. That's simply never going
to work reliably. Let the individual distributions do their job by providing
just the rest.

The fact that it's default is even more worrying.

