Comment by sschueller
11 years ago
A little vague on details.
Apache only or also Nginx?
Who is the CA?
No way I am running something like this on a production machine.
I like the idea but I would rather have the client just output the certificate and key in a dir so I can put the files where I need them and I can configure the changes to my webserver.
Also this does not solve the issue of a CA issuing certificates for your domain and doing MITM.
This is just a pre-announcement to let folks (OSes, hosting providers, other platforms) plan and do integration work. Per our own warnings, we definitely don't want this running on production machines until it launches in 2015.
Our Apache code is a developer preview, we'll be working on Nginx next.
ISRG will be operating a new root CA for this project. Although if you think that your choice of CA makes you more or less secure, you may not have understood how PKIX works -- you can buy a cert from whichever CA you like, but your adversary can always pick the weakest one to try to impersonate you.
> ISRG will be operating a new root CA for this project.
Are you going to be cross-signed by IdenTrust or something? If you're really going to try and create a new root CA from scratch, surely you will be impaled on the spike of low coverage for many years?
That's quite a painful spike indeed, but fortunately we'll be cross-signed by IdenTrust.
"ISRG will be operating a new root CA for this project."
Does that mean every client/browser will need to be updated to include the new CA? Or will it somehow be signed by other (competing) CAs?
I like the idea of this project, and I think it's a great thing for the Internet - I just worry that it will take a long time for it to be usable in practice.
No, it will be cross-signed and provide the chain so that it will work immediately in all mainstream browsers.
1 reply →
We're putting out a protocol for requesting certs and validating domain control (that our new CA will support -- and we'll be cross-signed to work in all mainstream browsers) and we've already written a client for it that integrates with Apache and can edit your Apache config.
If you're comfortable editing your own Apache configs, then you'll only need to use the client to obtain the cert and not to manage its installation long-term. (The client does need to reconfigure the web server while obtaining the cert as part of the CA validation process.)
The protocol is openly published, so you can write your own client too, or follow the protocol steps manually -- or any web server developer or hosting platform can develop their own alternative client.
There does need to be some client to speak the protocol, but there's no attempt to force you to use it to manage your certs and configs if that's not what you want. The convenience is aimed at people who don't understand how to install a cert, or who think that process is too time-consuming.
ACME is a protocol for securely and automatically issuing certificates. Presumably Apache, Nginx, IIS and any other web server could take advantage of it.
They are creating a new CA for this purpose.
I can't imagine this will replace the manual learn-pay-experiment-error-success process we have at the moment, so experts will still be able to control the process manually.
It doesn't address CA MITM attacks but it does significantly reduce non-CA MITM attacks by remove the two primary objections to deploying SSL: cost and complexity. Bravo EFF - this could be the most significant step in SSL adoption ever.
For those who are wondering why sschueller is saying such things (when I first read his comment my reaction was "how the f* could this be limited to Apache?", which worried me since I mostly use lighttpd), see the How It Works page [1] of Let's Encrypt.
> I would rather have the client just output the certificate and key in a dir
Could not agree more.
[1] https://letsencrypt.org/howitworks/
"This code intended for testing, demonstration, and integration engineering with OSes and hosting platforms. Currently the code works with Linux and Apache, though we will be expanding it to other platforms."
https://github.com/letsencrypt/lets-encrypt-preview
I'm sure they'd support "manual setup". Not many sites would opt into running their software agent (yet). I'm expecting the client to come with a lot more benefits than "simple setup", though.
I think that plenty of site admins will be happy to run this software agent—remember, there are many site admins right now that aren't even bothered to set up TLS at all.
I run plenty of tools right now on production boxes that I personally haven't fully audited—we all do. This tool should be simple and widely used enough that it will be trustworthy.
For the cautious, it would be nice if the tool offered a mode that could be run as a normal user, even on a different machine. It'd have to be an interactive process:
1. "Enter domain to be signed." 2. "To validate ownership of the domain, create a TXT record on xxx.example.domain with 'na8sdnajsdnfkasdkey' as the value." 3. "Domain ownership has been validated. Please paste the CSR." 4. "The zone has been signed. Here is your certificate:"
Much less convenient (basically the same as the process with current CAs), but it would allow security-conscious admins to use the CA in a way that is comfortable for them. Since the tool is open source, it should be fairly easy for someone to write their own tool that speaks to the CA while providing this interactive process.
The tool is interesting and to be honest, I'll be comfortable using it (I'm not running anything high-profile or sensitive). However, the real news here is the new CA—the tool is merely a convenience.