
Let's Encrypt is Trusted - coffeecheque
https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.html
======
lorddoig
Being told that you now trust someone with your secrets via a news website is
a pleasingly succinct display of everything that's wrong with the CA model.

~~~
vonklaus
_We’re pleased to announce that we’ve received cross-signatures from
IdenTrust_

This is what is wrong with the CA, model, not their method of announcing it to
a community anxiously awaiting the arrival of their product. What is absurd is
that identrust has a shitty non-responsive 90's looking website and wants $299
for an SSL certificate, which is something that should be free. I will say
though, they really did sell me on their trust worthiness with the alternating
images of a fingerprint and a lock. So now I know they're legit. It is worth
the $99 for SSL on a single site annually because there is binary data
superimposed on some of the pictures.

~~~
sgc
I don't think he was saying they acted poorly by announcing on HN, but that he
would prefer to grant someone trust rather than have it forced on him before
he even knew about it. Not an easy task for a functional web, but it would
obviously be better if possible.

~~~
Natanael_L
There's many ways, all obnoxiously complex unless you go back to a CA-ish
voluntary trust model.

Keys as addresses (I2P, Tor hidden services, CJDNS) fixes a large part of the
security problem, then on top of that you can add your choice of address
translation. WoT style individualized trust webs? Trusted lists of name
assignments DNS style? First-come first-serve á la Namecoin?

~~~
xorcist
Not necessarily. You could also place domain validated trust in the
registrars, to cryptographically verify their delegations. That would build a
chain of trust which you in turn could use to validate keys for services in
those domains.

~~~
Natanael_L
That's the DNSSEC+DANE approach and that's still the same as the DNS approach
I listed (trusted name registry lists), except that the address isn't an IP-
address (or in other words, your domain's DNS server that says what IP
addresses your subdomains have is itself identified by a public key).

------
joshmoz
See a Let's Encrypt cert in action:

[https://helloworld.letsencrypt.org/](https://helloworld.letsencrypt.org/)

Nice work team!

~~~
nitrogen
I was unable to connect using a vendor-specific browser on an old Android 4
device. Is this a limitation of the LE cert, or a cipher suite issue with
older browsers, or something else?

Really looking forward to spreading HTTPS far and wide.

~~~
pugtor
Taking a guess from the SSL Labs report[1], that site appears to be using the
modern config from Mozilla's toolkit[2], which limits it to browsers from the
last few years.

1:
[https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.le...](https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.letsencrypt.org)
2: [https://mozilla.github.io/server-side-tls/ssl-config-
generat...](https://mozilla.github.io/server-side-tls/ssl-config-generator/)

~~~
newman314
It's also throwing a OSCP error as well as no HSTS/HPKP headers to get to A+
grade.

~~~
pugtor
But hey, it's got OCSP stapling!

------
toast0
It seems odd to me that the intermediates were cross signed instead of the
having the root be cross signed.

With a cross signed root, clients with only the IdenTrust root will validate
the cert, and clients with only the LetsEncrypt root can validate the cert.

With a cross signed intermediate, the server has to guess which root the
client has and serve the correct path, there's a TLS extension to indicate
roots the client supports, but nothing actually uses it, so I don't know how
the server is going to guess (other than to assume no one has the LetsEncrypt
root, since it's new).

[1] but some clients are dumb and won't validate successfully when they reach
a root they know :/ Most browsers will though.

~~~
j4cob
This was a performance decision. Cross-signing the root instead of the
intermediate would mean that web servers would have to include both the root
and the intermediate in the chain they serve, rather than just the
intermediate. That would add a full packet to each handshake.

~~~
Natanael_L
Why are there multiple intermediate certs? I don't know the details of the
standard procedure.

~~~
vog
In case the main intermediate cert has been compromised and must be revoked,
the alternative intermediate cert is already signed and can be used
immediately for desaster recovery.

------
jakejake
Can anyone who knows more than me say - is this the beginning of the end of
the SSL cert selling business? Is there still value to buying an expensive
cert from another vendor?

~~~
yokohummer7
Not yet, because Let's Encrypt doesn't provide wildcard certificates as of
now. This may change in the near future, though.

Also note that free single domain certificates have been available from
StartSSL for a very long time, but this didn't destroy the certificate
industry.

~~~
mastax
An argument can be made that Let's Encrypt doesn't need wildcard certificates
since new certs can be generated automatically every time a subdomain is
added.

~~~
robryk
An interesting usecase of wildcard certs: when I do not want to publish the
hostnames I am using. Sandstorm[1] uses unpredictable hostnames as one
mitigation against various cross-origin attacks -- if the attacker doesn't
know the domain of the app, he can't try to use XSRF against it[2].

[1] [https://sandstorm.io](https://sandstorm.io) [2]
[https://docs.sandstorm.io/en/latest/using/security-
practices...](https://docs.sandstorm.io/en/latest/using/security-
practices/#client-sandboxing)

~~~
icebraining
If you are willing to only accept SNI enabled clients (the vast majority
nowadays), you can achieve the same by having one cert issued per subdomain,
then configuring the web server/reverse proxy to use them.

There are a few existing Nginx configs for that (search for "nginx dynamic ssl
cert").

~~~
schoen
I think there are other problems for doing this for Sandstorm. One is the
delay when starting to use a new hostname (right now Let's Encrypt might take
around 20 seconds to issue a new hostname, which may well increase to the
originally-predicted one minute eventually), while another is that all Let's
Encrypt certificates are published, so if you really want the hostname to be
completely unknown to an attacker, the individual Let's Encrypt certs wouldn't
work.

Anyway, Sandstorm developers told me that they wouldn't plan on using Let's
Encrypt while it doesn't offer wildcards, so I think we are missing out on
supporting this use case.

------
bracewel
ISRG, the org behind Let's Encrypt, is hiring! --
[https://letsencrypt.org/jobs/](https://letsencrypt.org/jobs/)

------
throwaway7767
Can someone who's tried the client confirm if it's possible to get a key/cert
out of it without having it mess with my configuration files?

I'd like a manual mode, as years of sysadmin work have made me extremely
skeptical of tools that try to automatically modify config files.

~~~
vog
That was my initial impression, too.

However, as far as I understood, there is an API that will just hand out the
certificate.

I guess they don't want it to be accessed by a web browser because they want
us to regenerate and include a newer cert automatically.

So you have a somewhat higher setup cost (setup automatic cert update rather
than one-time download of your cert), but then you can't forget to update your
cert over the years.

I believe they also want this is be a fast desaster recovery. So if their main
intermediate certficate is compromised, they can revoke it and hand out new
certificates (using the backup intermediate cert) for all domains within a
very short amount of time.

Nevertheless, I would have preferred a good explaination about how to setup
this process manually, rather then depending solely on their tool.

(In case this process it too cumbersome without their tool, they should
simplify it rather than hiding this in their tool.)

------
zmmmmm
Yay!

Honestly, it is amazing to me that someone like Google or Amazon did not do
this as free service a long time ago. But having an independent entity like
this do it is far better.

~~~
cinquemb
Serious question, to what degree is one defined as being independent? When you
have "platinum" sponsors like akamai and cisco, and can take donations through
paypal?

~~~
zmmmmm
They are a separate legal entity, with multiple independent sources of funding
and a diverse range of board members[1]. I'm not sure about degrees of
independence, but I would say this satisfies my criteria. Are you arguing they
aren't really independent of their sponsors?

[1] [https://letsencrypt.org/isrg/](https://letsencrypt.org/isrg/)

~~~
cinquemb
I wasn't arguing anything just asking a question.

But I will say that, without any numbers, its hard for me to say either way.
Clearly, RSA was in independent legal entity, but a $x million dollar check
didn't stop them from peddling shoddy crypto… though that's not something
surprising to hear in this community.

------
axx
The big question:

Does this mean we can now all use Let's Encrypt to generate new certificates
without people running into problems?

~~~
callahad
It means certs signed by Let's Encrypt will work just fine for people without
any special setup. See
[https://helloworld.letsencrypt.org/](https://helloworld.letsencrypt.org/) for
an example.

This does _not_ , however, mean that we can all start using Let's Encrypt.
They're doing a slow roll-out before making certs generally available to the
public. You can apply for the Beta at
[https://goo.gl/forms/kf0IGCeAk5](https://goo.gl/forms/kf0IGCeAk5), or wait
until general availability later this year.

~~~
axx
Thanks!

------
icelancer
Huge win for them - will help push SSL/TLS on everything. Can't overstate how
important this is for the web. Now to get the word out to everyone!

edit: initially said SSH. I blame the plane wifi

~~~
landr0id
I think you meant SSL/TLS

~~~
MertsA
can you sign a cert for SSH? I know that you can add the SSH server public key
fingerprint as a DNS record and sign an openSSH certificate with your own
private CA but are there any public CAs who will sign SSH certs and would the
ssh client even trust anything other than a manually added CA?

~~~
darkr
Yeah - [Open]SSH supports signing for host and user keys, and you can operate
your own CA, and the certificates you issue can encode a signed set of
permissions/access controls with them (E.g permit-agent-forwarding,
permit-X11-forwarding, certificate life times) this functionality is IMHO
vastly underutilised.

OpenSSH certificates are not X509 certificates though, and out of the box SSH
servers will not trust any public authority.

Also, AFAIK CA cross-signing, intermediates and other things that are fairly
commonplace in X509 land are either not supported or not widely supported in
OpenSSH.

~~~
pquerna
Using the OpenSSH Certificate format, many of the common features from X.509,
like intermediates, cross signing, key usage attributes or restricting access
based on an attribute in the certificate are not part of the spec:

[https://github.com/openssh/openssh-
portable/blob/master/PROT...](https://github.com/openssh/openssh-
portable/blob/master/PROTOCOL.certkeys)

When I first learned about OpenSSH Certskeys, I was really excited; Spent
awhile trying to make it useful, but you end up building all the CA
infrastructure, and this time instead of distributing certificates to servers
once a year, you want to distribute certificates to your _users_ every month
or two -- so the pain is higher, there is less automation, and everyone on
your team feels it....

Exploring OpenSSH certs is what led me to founding ScaleFT. There had to be a
better way.

ScaleFT Access leverages these SSH Certificates, but we expire them every 5
minutes to provide other features that are hard with the limited capabilities
of the format:

[https://www.scaleft.com/products/access/](https://www.scaleft.com/products/access/)

There are patches to make OpenSSH use X.509, but they are not widely
adopted... and asking people to patch a sshd is a non-starter for many
environments.

------
steve19
"We’re pleased to announce that we’ve received cross-signatures from
IdenTrust"

How is this beneficial for IdenTrust?

~~~
mholt
Related discussion: [https://community.letsencrypt.org/t/what-is-the-business-
mod...](https://community.letsencrypt.org/t/what-is-the-business-model/310)

It establishes IdenTrust as a more influential leader of SSL certificates on
the Web. There are other ways CAs can make money, and this extra publicity
will probably serve them well.

~~~
cpeterso
IdenTrust is an interesting organization. IdenTrust is a bank consortium
acting as a public key certificate authority and secure applications provider
whose members include over 60 of the largest banks in the world. John Sculley
has been IdenTrust's chairman since 2006.

[https://en.wikipedia.org/wiki/IdenTrust](https://en.wikipedia.org/wiki/IdenTrust)

------
teabee89
Are they planning on not relying on a 3rd party root CA and instead, ask all
browsers and OS vendors to include LetsEncrypt CA? IOW, is this [trusting
IdenTrust] a first step, or is this the original goal?

~~~
kej
This is a temporary step. There are two versions of their intermediate cert,
the one in this article that is cross-signed and another that is signed by
their own root (which isn't yet included everywhere). There's a diagram on
this page that explains the situation:
[https://letsencrypt.org/certificates/](https://letsencrypt.org/certificates/)

------
scott_karana
> and we’re excited to be one big step closer to bringing secure connections
> to every corner of the Web.

What steps are left now? :-)

~~~
mholt
From what I can tell, they're polishing their CA software (Boulder), and
getting the rest of their infrastructure and policies ready for GA.

------
bracewel
A quick look at all the certificates Let's Encrypt has issued so far can be
found using Comodo's CT based crt.sh tool.

[https://crt.sh/?Identity=%25&iCAID=7395](https://crt.sh/?Identity=%25&iCAID=7395)

~~~
Laforet
That's surprisingly fewer domains than I expected. No wonder I never received
any replies for my application to their beta program.

~~~
pugtor
I think the idea was the public beta should wait until the certs are valid
everywhere.

------
wyldfire
Delicious irony: my employer's web proxy supplies their own certificate in
place of the real one for
[https://letsencrypt.org/](https://letsencrypt.org/).

Though, to be honest they do this for >90% of https sites, in my experience.

------
peterwwillis
Remember that you only need one of the hundreds of CAs (650 at my last count)
to generate you a cert to essentially compromise a site's connection security.
Free certs mean more sites will use TLS, which means there will be more
targets, which means more incentive to start attacking the weakest CAs and/or
their verification practices.

But this is kind of a good thing, because after enough attacks on the old
model, people will ask for an improvement or replacement of the model.

~~~
alwillis
Thanks to HTTP Public Key Pinning (HPKP), this is no longer a threat:

 _HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP
response header much like HSTS and CSP. It allows a host to provide
information to a user agent about which cryptographic identities it should
accept from the host in the future. This can protect a host website from a
security compromise at a Certificate Authority where rogue certificates may be
issued for your hostname._

You can read all about it: [https://scotthelme.co.uk/hpkp-http-public-key-
pinning/](https://scotthelme.co.uk/hpkp-http-public-key-pinning/)

And here are web-based tools for examining and generating HPKP hashes:
[https://report-uri.io/home/tools](https://report-uri.io/home/tools)

~~~
peterwwillis
You don't get to say there is no threat if almost every website today is
vulnerable.

First, this is optional software that almost every public server in the world
is currently not using. It's like saying just because executable whitelisting
exists that downloaded exploit payloads on operating systems is no longer a
threat. If nobody uses it, the threat still exists.

In addition to actually implementing it on your server, every single user
still has to make a secure initial connection over a trusted network on every
device they'll ever use to get to that site.

But not every client even supports HPKP. There's lots of older software which
doesn't support it, and IE doesn't support it at all, which by itself would
leave 12% of all clients vulnerable.

[https://projects.dm.id.lv/Public-Key-
Pins_test](https://projects.dm.id.lv/Public-Key-Pins_test)

[https://en.wikipedia.org/wiki/Usage_share_of_web_browsers](https://en.wikipedia.org/wiki/Usage_share_of_web_browsers)

~~~
alwillis
_You don 't get to say there is no threat if almost every website today is
vulnerable._

I didn't mean that literally the threat has been eliminated due to HPKP; it's
yet another tool that can be used.

 _First, this is optional software that almost every public server in the
world is currently not using. It 's like saying just because executable
whitelisting exists that downloaded exploit payloads on operating systems is
no longer a threat. If nobody uses it, the threat still exists._

HPKP isn't software--just additional HTTP headers that pretty much every web
server can be configured to send.

 _In addition to actually implementing it on your server, every single user
still has to make a secure initial connection over a trusted network on every
device they 'll ever use to get to that site._

True; it's even described in the RFC:
[https://tools.ietf.org/html/rfc7469](https://tools.ietf.org/html/rfc7469)

 _Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA
connects to a host, it lacks the information necessary to perform Pin
Validation; UAs can only apply their normal cryptographic identity validation.
(In this document, it is assumed that UAs apply X.509 certificate chain
validation in accord with [RFC5280].)_

------
johncolanduoni
It just _had_ to be right after I renewed my SSL cert, didn't it? :P

~~~
dfc
This is not a spur of the moment announcement. Their timeline has been
publicized all over the place

~~~
johncolanduoni
It was a joke, I was well aware of the timeline. It hasn't moved to general
availability anyway.

------
jonah
Chrome says they don't supply Certificate Transparency information. Is this
something they should be doing?

~~~
bracewel
This is something we entirely plan on doing, in fact we currently submit all
issued certificates to a number of CT logs (which can be viewed here
[https://crt.sh/?Identity=%25&iCAID=7395](https://crt.sh/?Identity=%25&iCAID=7395)).

Unfortunately the best candidate, at least for us, for supplying SCT receipts
to end-users, via x509v3 extensions in OCSP responses, is currently not fully
supported in Golang.

------
josteink
From a comment on a similar reddit-thread[1]:

> So thus beings the transition. EV certs are going to be the only ones that
> get the "green" chrome in browsers anymore. Sites using standard SSL are
> going to get the normal no-lock/white treatment. And sites without SSL will
> get the caution symbol/yellow treatment.

I don't like it, but I suspect this is where we're heading.

[1]
[https://www.reddit.com/r/linux/comments/3pg37u/lets_encrypt_...](https://www.reddit.com/r/linux/comments/3pg37u/lets_encrypt_is_trusted/)

~~~
cpach
_" EV certs are going to be the only ones that get the 'green' chrome in
browsers anymore."_

Are there any facts to back up this claim?

Edit: This is what HN looks like in Firefox 38.0.5:
[http://img4.imagetitan.com/img4/RsbN6Rsn61k2IMN/12/12_l.png](http://img4.imagetitan.com/img4/RsbN6Rsn61k2IMN/12/12_l.png)

Sure, the background color is white, but there's still a padlock icon.

~~~
jaytagdamian
Image not found

~~~
cpach
I don’t know what happened there. Try
[https://i.imgur.com/cY0Kx6x.png](https://i.imgur.com/cY0Kx6x.png)

------
nodesocket
Am I missing where I can signup? Love to try them.

~~~
bracewel
The general availability period hasn't begun yet, but you can still sign up
for the beta program here --
[https://docs.google.com/forms/d/15Ucm4A20y2rf9gySCTXD6yoLG6T...](https://docs.google.com/forms/d/15Ucm4A20y2rf9gySCTXD6yoLG6Tba7AwYgglV7CKHmM/viewform?c=0&w=1)

------
arkad
This entry has 443 points how and I don't want to upvote to spoil it...

------
cddotdotslash
Is there an easy way to pull out the cert and load it into an AWS ELB without
running the client on the server it will eventually protect? I'm not a big fan
of using software that auto changes my config files, plus you can't actually
run scripts on ELBs.

~~~
viraptor
let's encrypt uses ACME protocol for certificates. You can use your own tools
to handle it - either automatically or manually. Their automated client is
just a user-friendly wrapper.

------
mholt
Congratulations LE team!

Final Star Wars VII trailer and LE gets cross-signed. Best. Day. Ever.

~~~
ersii
I would just like to point out the irony in using 'LE' as a short for Let's
Encrypt, as 'LE' usually gets used for shortening Law Enforcement.

(Also: Congratulations and well done, Team Let's Encrypt!)

~~~
davidcollantes
"LE" is identified more with "Limited Edition," I think. At least in the US.

~~~
jpreiland
I always associate "LE" with "Lawful Evil", but maybe I'm a nerd

------
ausjke
What does this mean to a new user? Can I now get a ssl certificate? will it be
cheaper, or even free? I saw they have a beta-program for the certificate but
don't know what it exactly does.

------
gergles
I really dislike the fact that a CA is able to bless a new CA completely
independently. Does this cause anyone else the slightest amount of anxiety, or
am I just being paranoid?

~~~
belorn
Whats the alternative to CA being able to delegate signing? Would you prefer
having browsers constantly being updated with new lists of CA's, maybe one new
per day.

Second, would you prefer that browsers blessed a new CA completely
independently? If not then who should have that power? Governments? Non-profit
organizations like ISRG?

The big alternative is to maintain your own list of trusted CA's, going
through each and every new CA that you encounter and associate a trust
relationship. Not even famous security researchers do this, and I can't really
blame them as it is like a lawyer reading every EULA that they encounter and
fully investigate the scope of them. The scope and complexity just get beyond
what a single person can manage.

~~~
gergles
Yeah, I guess I think it makes more sense for the browser manufacturers to be
the people to whom I delegate that responsibility. I already trust them not to
run malware on my computer and to accurately display the SSL state of a
connection.

I just think it's odd that any CA can turn around and make any other random CA
fully blessed. It seems like it completely circumvents the browser
manufacturers including root CAs at all.

Totally agreed re: maintaining your own list of CAs. I mostly do go through
the system CA list and disabling any from foreign governments I don't ever
plan on trusting, but that's mostly feel-good and not actual security.

------
okigan
Could somebody clarify: LetsEncrypt allows anybody to create certificate for
any domain, so would not that allow anybody to create MITM certificate for any
such domain?

~~~
ubernostrum
Look at the tech overview:

[https://letsencrypt.org/howitworks/technology/](https://letsencrypt.org/howitworks/technology/)

You can only obtain a certificate for a domain if you can validate that you
control the domain. Their steps for that (place arbitrary content at an
arbitrary URL they request, or create an arbitrary DNS record they request)
are such that, if you weren't the legitimate controller of the domain but
could do those things, you wouldn't need a fake cert -- you'd already have
pwned it thoroughly enough to be able to MITM it in other ways.

~~~
flashman
> You can only obtain a certificate for a domain if you can validate that you
> control the domain.

Technically, you only have to make their systems _think_ you control the
domain. If their servers or 'establish proof of ownership' process are hacked,
wouldn't this allow an attacker to do the same thing that happened in the
DigiNotar hack?

[https://en.wikipedia.org/wiki/DigiNotar](https://en.wikipedia.org/wiki/DigiNotar)

~~~
alwillis
This is why HTTP Public Key Pinning was created as a way to tell browsers to
trust _only_ a particular certificate, not just any certificate that was
signed by a CA in the browser's trust store:
[https://news.ycombinator.com/item?id=10418144](https://news.ycombinator.com/item?id=10418144).

~~~
okigan
Another follow up: from your link, looks like the server adds a header
specifying which certificates are allowed.

Would not MITM just remove that header?

~~~
alwillis
From the RFC:
[https://tools.ietf.org/html/rfc7469](https://tools.ietf.org/html/rfc7469)

 _Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA
connects to a host, it lacks the information necessary to perform Pin
Validation; UAs can only apply their normal cryptographic identity validation.
(In this document, it is assumed that UAs apply X.509 certificate chain
validation in accord with [RFC5280].)

The UA will not be able to detect and thwart a MITM attacking the UA's first
connection to the host. (However, the requirement that the MITM provide an
X.509 certificate chain that can pass the UA's validation requirements,
without error, mitigates this risk somewhat.) Worse, such a MITM can inject
its own PKP header into the HTTP stream, and pin the UA to its own keys. To
avoid post facto detection, the attacker would have to be in a position to
intercept all future requests to the host from that UA.

Thus, key pinning as described in this document is not a perfect defense
against MITM attackers capable of passing certificate chain validation
procedures -- nothing short of pre-shared keys can be. However, it provides
significant value by allowing host operators to limit the number of
certification authorities that can vouch for the host's identity, and allows
UAs to detect in-process MITM attacks after the initial communication._

------
vbezhenar
Is there some web interface to sign my certificate, similar to startssl? I
don't really want to run new program in my server just to generate
certificate.

~~~
Natanael_L
You could run it on a laptop to get the cert, then install on the server. But
right now it remains an invite only beta until they get ready for general
availability

------
cm2187
Has anyone seen anything re IIS integration?

[EDIT] I have seen this: [https://github.com/ebekker/letsencrypt-
win](https://github.com/ebekker/letsencrypt-win)

But ideally we would want Microsoft to add a checkbox in the UI of IIS
Manager, which when creating a https binding offers to use let's encrypt
instead of an installed certificate.

------
dSnapApjw
I like that statement "community trust"...much the same I have come to trust
most of the wisdoms on this site. I for one-learn, and greater, I learn from
each of you the value of clarity. So trust as David Abshire says, "Is the coin
of the realm, the glue, the oil, (alternative energy-) ingredient."txs,
dSnapAp. SFCA.

------
andrewrothman
I can't wait for Let's Encrypt to finally start signing certificates. The
future of encrypted communications is among us, and it's going to be huge.

Will definitely use this as soon as they open their doors to me.

------
vinay_ys
In a mobile only world where your critical business runs only via mobile app
do CA based SSLs even matter? Why not use your own CA with your own
certificates and don't have to trust any CA?

~~~
schoen
If you're doing TLS solely with your own app, this is often described as a
best practice -- avoiding exposure to the public PKI entirely.

Personally, I'm typing this post into a web site using a web browser, so I
appreciate that it has a certificate that my browser can validate!

------
franciscop
Yes, finally. I've been awaiting this moment from the first announcement.
Happy they made it (:

------
devit
The next step should be to stop trusting any other CA, and have Let's Encrypt
support EV certificates by working with other CAs and still requiring Let's
Encrypt DV verification.

This way, Let's Encrypt in particular would need to be breached for a
successful attack, while right now it's enough to breach either Let's Encrypt
or any other CA.

------
dadrian
Congratulations jdkasten!

------
SimeVidas
So… we’re all still waiting for the client, right?

~~~
mathrawka
No, they have announced their launch schedule in the past. Here is the latest
update: [https://letsencrypt.org/2015/08/07/updated-lets-encrypt-
laun...](https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch-
schedule.html)

~~~
SimeVidas
But we _are_ waiting for the client, no? If I understand correctly, the client
will enable us to install Let’s Encrypt’s certificate on our web server. I
assume, “general availability” is when the client will become available for
everyone.

~~~
mathrawka
The source for the client is here:
[https://github.com/letsencrypt/letsencrypt](https://github.com/letsencrypt/letsencrypt)

However, their release schedule dictates when the service (yes, the client is
part of this) is ready for use.

Until then you are waiting for the service to be available.

------
jamminn
So, it's still all about trust then? I thought Let's Encrypt would go beyond
trust.

~~~
jrochkind1
What do you mean?

------
tychuz
I'm all for native desktop and mobile applications, but in this case I'd
actually love a web app - enter your domain, get certificate.

Downloading a tool, reading man page, works out of the box only with
apache/nginx - ehhh, seems like a lot of work, considering some comments
touting 'user friendliness' compared to StartSSL.

~~~
Natanael_L
But you need to run _something_ on the server to validate that you've got
control of it on your domain. A web app isn't enough.

The better solution is to integrate this tool into various server tools like
Apache and Wordpress and in whatever else you might be running with a one-
click installer.

------
balabaster
Er... you're trusted by a CA that's owned by a company that resides in Austin
Texas...

Texas hasn't exactly got a glowing reputation in the software industry due to
its mountain of intellectual property lawsuits filed by patent trolls... er,
sorry, I mean non-practicing entities

Excuse me while I reserve some skepticism about just how trusted your security
certificates should be.

~~~
vtlynch
Absolutely pointless and irrelevant. This is the same logic that Donald Trump
uses to dismiss all Mexican people as rapists.

~~~
balabaster
Except that the courts are used there time and again to strong arm well
meaning companies into paying millions out to fight frivolous lawsuits that
run them into the ground. Exactly the kind of tactic you'd expect intelligence
agencies to use to strong arm encryption companies into giving up their data.

------
1K2bCjh1aH
./letsencrypt-auto Updating letsencrypt and virtual environment
dependencies.....Command "python setup.py egg_info" failed with error code 1
in /tmp/pip-build-KgdEvk/ConfigArgParse

~~~
cpach
HN is not a support forum. Please look here instead:
[https://community.letsencrypt.org/t/welcome-to-lets-
encrypt-...](https://community.letsencrypt.org/t/welcome-to-lets-encrypt-
community-support/8)

------
signaler
This will still require early stage overhead for many people switching over /
'going dark all the things'. Even though Let's Encrypt's goal is to make the
process of encrypting the Transport Layer seamless, ubiquitous and non-
commercial.

Take for example my setup. It sits on a private NGINX server, and is proxied
through a public facing CDN. Trying to simply 'switch on' TLS involves
absorbing academic style tutorials from multiple disparate sources, and
requires me to have a background in DevOps and that I have at least tried some
technical task like this before. In layman's terms: Unnecessary Early Stage
Overhead.

Now give Let's Encrypt a few more years and it will be a lot more seamless;
possibly the default. It could possibly be 'baked in' to things like
Softaculous, and cPanel, which are brilliant drivers for the success of web
software. Digital Ocean staff are probably already working on a droplet with
LetsEncrypt baked in...

~~~
axx
I don't see how TLS is early stage overhead for someone runnig a private nginx
server behind a CDN?

Sure, someone with no devops skills at all will have a _harder_ time, but it's
for the better. Soon it will be The Way to install a webserver. Thanks to
Let's Encrypt it's so easy to install TLS that nearly every future webserver
tutorial will include it.

------
NateDad
Why python for the client software if you obviously already have Go experience
in-house? Using python means you have to run all this virtual-env crap in a
bash script, apt-get install a bunch of crap for setup and not support
Windows. Seems like using a (nearly) dependency-free Go application for the
client as well would have been a no brainer. Was it just a case of having more
access to python devs, or were there other technical reasons? Anyone know? I
bet this has been asked before, but not I'm turning anything up with google.

~~~
mholt
I can't speak for them obviously, but here's a Go ACME client if you're
looking for one:
[https://github.com/xenolf/lego](https://github.com/xenolf/lego) \- we're
using it in Caddy[1] to make HTTPS the default for websites.

[1]:
[https://github.com/mholt/caddy/commits/letsencrypt](https://github.com/mholt/caddy/commits/letsencrypt)

~~~
NateDad
Wow, that's awesome. Nice work integrating this into caddy.

Although, it makes me even more confused as to why they used python for the
official client.

------
UserRights
The headline is wrong and not very clever for such a project.

The project was able to get a CA to sign their keys, this is what happened.
Using the word "trust" is simply wrong and might be interpreted as a too
simple kind of propaganda after we learned a lot about the untrustable nature
of a hierarchical certification infrastructure.

Another, even bigger trust-breaking elephant in the room is the fact that this
project is USA based - as long as US government and agencies are insisting on
practices we know from authoritarian and anti-democratic states like e.g.
China or Saudi-Arabia there is no way any US based project can use the word
"trust" for their product description - it might be recognized as a simple lie
by informed people.

Questions to the project leaders:

* you must obey US laws and therefore offer MITM access to every Let's-Encrypt "trusted" network stream - why aren't you educating your users about this serious limitation of your product?

* why don't you rebase your project to a country where a government policy exists that is allowing companies to build trustable security based products?

~~~
schoen
There is no U.S. law that compels us to "offer MITM access to every Let's
Encrypt trusted network stream".

TLS sessions are negotiated between TLS clients and servers. Their
confidentiality is guaranteed by that negotiation and the certificate
authority, if any, doesn't have the server's private key and can't read the
server's TLS sessions.

What CAs have the power to do is misissue certificates. Using a CA's services
generally does _not_ increase your exposure to misissuance attacks by that CA.
If Let's Encrypt misissues certificates, it could misissue them for sites that
are not and never have been Let's Encrypt users, just as any other CA can
issue certificates for any public Internet service.

As I've said elsewhere, Let's Encrypt wants to use, and encourage others to
use, technologies that limit our power to do the wrong thing, including HPKP
and Certificate Transparency. We want more limits on our power and other CAs'
power, not fewer, that lead to misissuance events getting caught and attacks
on TLS users failing.

------
mangeletti
I truly appreciate the hard work Let's Encrypt is doing.

However, this is not free.

In return for getting an SSL certificate, your users will need to trust an
organization to protect the secrets they share with you and vice versa. This
organization has no economic incentive to do good for you or to do harm to
you.

What happens when this organization is compelled by the TLA to give up the
lucky charms, and there is no team of attorneys to fight back, and no billions
at stake, and there is a gag order? And, given the rate at which a "free" SSL
certificate will proliferate, these will be some valuable lucky charms.

This is not FUD. This is simply recognizing that "free" SSL certificates don't
really address the issues that arise from centralized authority in a
decentralized economy.

~~~
idibidiart
I personally argued with the W3C TAG against an HTTPS-only web for this
reason. Tim Berners Lee, who heads the TAG, ceremonially speaking, argued
against it, too, but on different ground. The browser vendor 'experts' on the
TAG totally dismissed any and all argument against forcing everyone to use
HTTPS. They were basically told by their employers (the big browser vendors
and CDNs like Akamai) to make it happen. HTTPS is a rather costly false sense
of security. Now anyone who wants to setup a website, for whatever reason, has
to go thru some central authority in the name of "securing the web" (LOL) but
it's just another way to control free speech and what people do with the web.

~~~
vtlynch
>Now anyone who wants to setup a website, for whatever reason, has to go thru
some central authority

Which 99% of people already do when the buy a domain name.

There is NO evidence that using SSL restricts your freedom of speech. There is
evidence to the contrary though, where SSL allowed people to speak freely
without having their communications intercepted or monitored.

Certificate Authorities only reject websites for certificates in rare cases
where the domain bears resemblance to a well known company (such as
"paaypal.com" or "microsoftproducts.com"). This is not something that every CA
does not something that a CA HAS to do.

There is no "false" sense of security HTTPS IS encrypted, and CA signed
certificates ARE authenticated. Claims that the whole CA system is MiTM by
government are largely unsupported, and if you believe that, then you are
screwed over HTTP anyway.

I dont disagree that there are some disadvantages to an HTTPS-only web, but
those generalizations are wrong.

~~~
idibidiart
"HTTPS IS encrypted"

Oh wow. Really? You haven't done your homework then. So many ways to undermine
the certificate authority model, including many famous cases, one involving
the Iranian government gaining access to their citizen's "encrypted" traffic.
HTTPs is about having traffic be open to powerful entities and closed off to
the common criminal. It's a two tier model, not real security.

