If they already have the CA stuff ready can they just release that? I don't really care about their auto-magical tool which is meant to reconfigure your server for you. Configuring Apache/IIS etc is not that complex, the only reason I don't have a certificate on my private website is because the certificate costs more than the hosting annually (literally).
Plus I'm never going to run this tool even when it is production ready. I don't trust random tools to reconfigure my system, and would prefer to manually follow tutorials so it is easy to undo every change or at least be aware of exactly what changes got made.
The CA itself is not ready yet. When it is, you can use the client in a simple mode to grab a certificate and drop it wherever you want, without automated configuration.
I don't want a tool that I have to run as root and that is going to touch anything in /etc/nginx/.
I do want a tool using which I can do something like:
$ letsencrypt 'foo.bar.example.com'
which would spit out foo.bar.example.com.key, foo.bar.example.com.cert, and foo.bar.example.com.csr.
I'd also like to have:
$ letsencrypt --renew foo.bar.example.com
Which would re-generate all these certs. The main problem for me, just like for you, is that domain validation certs are not free (or at least somehow included in the price of the domain registration). This type of tool solves that.
If, on top of this tool, we also get something that lets a person new to ops autogenerate or even autodeploy an nginx vhost with TLS/SPDY support, awesome! But the ability to generate and renew certs from the command line, for free, is what I want and probably what you want too.
I totally agree. You would however need to somehow authenticate that you own foo.bar.example.com (code in email, host something under foo.bar.example.com, a TXT record, etc.).
The tool doesn't care about your ownership of the domain, it cares about whether the host it's running on is trusted by the owner of the domain. The simplest way to verify that is for the CA to tell the tool "serve up this nonce value at this randomly-generated URL", and then to request that URL and see if it gets the right value.
Depending on exactly what proof the CA wants, that will probably require some kind of tinkering with the webserver's config, or at least inspecting it to figure out how to fulfil the CA's request.
Hopefully there'll be a fallback mechanism that tells the sysad what to configure, if only because not every webserver in the world is Apache or nginx.
They were never going to for free - the ones that do sell certs make huge amounts of money off them. That's why LetsEncrypt exists - to push the market value of a trusted X.509 certificate close to 0.
> Plus I'm never going to run this tool even when it is production ready. I don't trust random tools to reconfigure my system, and would prefer to manually follow tutorials so it is easy to undo every change or at least be aware of exactly what changes got made.
Agreed. I can already generate and install a certificate (though I wouldn't mind a standalone tool to make that simpler). I'd like some automated process that renews that certificate, or better yet, certificates that don't expire in the first place.
It makes sense for certificates to expire when domains do (though domain expiry also seems like a bug), but other than that, I think every other use case for expiry is better served by revocation.
What if you can't connect to the internet to check? Expiry works better in a lot of other cases, including offline systems with intranet-only access. Without expiry, you can DDoS a revocation server and perform an MiTM with a very weak cert issued 20 years ago (supposing the client accepts it.)
Intranet systems, and those connecting thereto ( e.g. corporate VPN clients ) should really be using only a trusted internal CA with mutual server- client authentication. Probably with hard coded cert signature on each end.
For example on our network every user-laptop-service combination has a unique cert. A user can be dropped from, say, accessing IMAP with a single change on the server and without affecting their webmail access.
MITM is very difficult in that scenario as the attacker had to compromise both ends.
Half of the point of expiry is to ensure that practices that used to be secure and are now not safely reach EOL, hence the 39 month restriction soon in place.
Without the expiration parameter, you could crack an 512 or 1024 bit certificate five years from now and it would be just fine to use. All you would have to do would be attack the CRL/OCSP server and keep it offline for a very short period of time.
There are several systems for servers to provide "stapled" indications from a CA that a certificate has not been revoked as of a given date. And if you're accessing an offline system on an Intranet, you might want to use a pinned certificate, or a pinned internal CA.
> If they already have the CA stuff ready can they just release that?
While I'm sure they have something ready[0], I'm not sure they have a fully-worked-out policy for running it (required to get into certificate chains), or a production deployment of it, or a third-party vulnerability test of it.
Additionally, ACME verification is a vaguely complicated protocol which will likely need a tool to sign the various messages involved (or you're going to be looking at munging together OpenSSL commands), and you're looking at the developer preview of that.
Good god. I knew StartSSL was bad, but not this bad.
I usually buy certs either through Gandi.net (which has a good "free certificate" program with its own domains), or COMODO through Namecheap as a reseller.
What would you expect if you are not paying for the cert? For me revocation was not an issue. I just got a new cert under a different subdomain as I don't use subdomains on my personal site and the main domain is added as an alt name.
What I would expect is for every CA to comply with the CAB/Forum Baseline Requirements, § 10.2.4:
>If the CA or any of its designated RAs become aware that a Subscriber’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.
There is no "if you pay them" condition to that. CAs are not supposed to make, or allow to stand, any signature on a compromised key—period.
Startcom's refusal to revoke all compromised public keys communicated to them after Heartbleed, and in fact their practice of charging for any revocation in general, is not in compliance with the baseline requirements for a CA.
As a result, Startcom should be removed from all browsers as a trusted CA. Let's Encrypt would be a very good replacement, especially if they also offer keys using ECC P-256 (and perhaps a subsequent replacement ECC algorithm).
That's not a correct response to Heartbleed... It could have been easily exploited to get your private key and certificate, and not revoking it leaves it valid.
It's quite reasonable pricing. It's less than most CAs does for a one year certificate, and revoking it is more work than issuing it in the first place.
They are not without fault, but they've much good for open source project and the like, and don't deserve the bad rap thrown at them in every thread that mentions SSL.
There was no bad rap in the thread until btreecat decided to be an ass. The only other subthread mentioning startssl is https://news.ycombinator.com/item?id=8904105 which only notes that as far as he can see letsencrypt is similar to startssl's delivery/validation process and seems to be vulnerable to mitm.
And also, you'll need IP addresses for each subdomains hosted, which can rack up costs. Though most of "modern" browsers and OS support SNI, this is less of a problem now.
False. I was able to get two certs issued for different sub domains for free. This was how I got around them charging $25 for revocation during heartbleed. I use the alt name in the certs as is.
I meant for hosting providers. If you are on any type of a hosting provider that doesn't have dedicated IP assigned to them, such as in case of "shared" hosting. If the service support SNI (Server Name Indication) then dedicated IP is not necessary, only complication is that if your site needs to support older browsers and/or OS, SNI may not work.
StartCom (or any of CA) doesn't care about IP address.
I was looking at the how it works[1] article but it isn't clear to me how the domain is validated.
Couldn't an MITM between the LetsEcnrypt service and the example.com server request a certificate, then respond to the challenge, and then use that certificate later?
Getting a certificate from StartSSL was similar. The only difference was that there was a human involved in the loop (a mail is sent and the user has to copy paste the contents of the email), but in essence, both the services seem vulnerable.
This seems to be an unsolvable bootstrapping problem, unless some sort of physical verification is done.
The protocol asserts that you have control over the domain, and over a machine that can be accessed at the domain's A record. If you can make your machine appear to be at google.com from the perspective of LetsEncrypt for the duration of the request process, you can get a cert from them.
This is standard for all domain-validation-only certificate authorities, i.e. the cheapest cert you can get from any given company.
If they already have the CA stuff ready can they just release that? I don't really care about their auto-magical tool which is meant to reconfigure your server for you. Configuring Apache/IIS etc is not that complex, the only reason I don't have a certificate on my private website is because the certificate costs more than the hosting annually (literally).
Plus I'm never going to run this tool even when it is production ready. I don't trust random tools to reconfigure my system, and would prefer to manually follow tutorials so it is easy to undo every change or at least be aware of exactly what changes got made.