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.
See a Let's Encrypt cert in action:<p><a href="https://helloworld.letsencrypt.org/" rel="nofollow">https://helloworld.letsencrypt.org/</a><p>Nice work team!
It seems odd to me that the intermediates were cross signed instead of the having the root be cross signed.<p>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.<p>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).<p>[1] but some clients are dumb and won't validate successfully when they reach a root they know :/ Most browsers will though.
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?
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?<p>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.
Yay!<p>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.
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!<p>edit: initially said SSH. I blame the plane wifi
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?
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.<p><a href="https://crt.sh/?Identity=%25&iCAID=7395" rel="nofollow">https://crt.sh/?Identity=%25&iCAID=7395</a>
Delicious irony: my employer's web proxy supplies their own certificate in place of the real one for <a href="https://letsencrypt.org/" rel="nofollow">https://letsencrypt.org/</a>.<p>Though, to be honest they do this for >90% of https sites, in my experience.
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.<p>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.
From a comment on a similar reddit-thread[1]:<p>> 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.<p>I don't like it, but I suspect this is where we're heading.<p>[1] <a href="https://www.reddit.com/r/linux/comments/3pg37u/lets_encrypt_is_trusted/" rel="nofollow">https://www.reddit.com/r/linux/comments/3pg37u/lets_encrypt_...</a>
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.
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.
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?
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?
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.
Has anyone seen anything re IIS integration?<p>[EDIT] I have seen this: <a href="https://github.com/ebekker/letsencrypt-win" rel="nofollow">https://github.com/ebekker/letsencrypt-win</a><p>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.
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.
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.<p>Will definitely use this as soon as they open their doors to me.
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?
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.<p>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.
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.<p>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.
Er... you're trusted by a CA that's owned by a company that resides in Austin Texas...<p>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<p>Excuse me while I reserve some skepticism about just how trusted your security certificates should be.
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.<p>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.<p>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...
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.
The headline is wrong and not very clever for such a project.<p>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.<p>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.<p>Questions to the project leaders:<p>* 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?<p>* 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?
I truly appreciate the hard work Let's Encrypt is doing.<p>However, this is not free.<p>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.<p>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.<p>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.