I want this project to proceed, but they should really focus on getting a much more mature and stable spec before launch. This isn't WebRTC, where you can just continuously tack on additional stuff or change the API constantly. It's TLS certs. The certs issued using this API end up telling people it's safe to input their passwords or credit card numbers.
I really hope the ACME spec gets stable before the launch in July.
I'm pretty sure they shouldn't tell users it's safe to type in credit card numbers -- these certs are "domain validation" (DV).
The certs that generate a green chip in the address bar are "extended validation" (EV) certs that typically cost hundreds and require a human to manually verify things.
There is an interesting HN discussion on the topic at https://news.ycombinator.com/item?id=8344238
It has to do with the security and accountability of the end-to-end process in which the certificate is used, which is a security concern even if you define "security of the certificate" so narrowly that it isn't relevant to the security of the certificate as such. (Though what you have a trusted third-party vouching for in the certificate -- which is the key distinction in EV -- is, I would think, by any reasonable standard, a factor in the security provided by the certificate.)
The cipher being used and the SSL configuration dictate MUCH more about the security of a site than its level of validation. EV certificates do not guarantee the site isnt using a insecure cipher. EV certificates do not guarantee that the private key was not sent via plain text in an email while a network admin was installing it. So from an encryption standpoint, there is no advantage.
From a authentication standpoint, an EV MAY provide more security but remember: An EV primarily validates the name and location of the relying party. It does not check to see if they are operating ethically or if you are getting ripped off.
I dont think EV is bad, but clamping down on what type of certificates can be used gets tricky. There are very few uses where EV (or OV) certificates should be required.
What's the hold up; HSMs that'll do secp256r1?
Because of the huge performance improvement ECDSA brings over RSA, I know I'm not going to be deploying Let's Encrypt certs until I can get ECDSA ones (as well as RSA ones, presumably).
What type of help is the Let's Encrypt team still needing?
Contributing to our software is one way to help:
Also, if you work for a company that might be interested in sponsoring us, starting that conversation is another great way to help out.
The Let’s Encrypt client is essentially an operating system component. Generically, it requires root privileges to bind to port 443 and (if requested) to reconfigure your webserver for certificate installation and renewal
That also seems like a perfect compromise vector for bad actors to modify the client software.
The Let's Encrypt effort is noble and definitely required but I think they would have been better-focused and quicker to market had they concentrated on establishing themselves as a CA first and leaving the 'auto-configuration magic' to a later stage, for the small subset of users who want that.
But for me the biggest problem with adoption of SSL is still that every domain name needs it's unique IPv4 address, and all problems that come with that, not registering or paying for the SSL certificate.
At work, I usually use virtual hosting for about 100 domains on one IP address. I don't see us buying an IPv4 address per domain and adding them to my NIC configuration one by one. Once we can safely ignore IPv4 and use IPv6 only it will probably become easier and cheaper.
Anything so old that does not support SNI probably still uses SSLv3, or maybe even SSLv2, so you really should be upgrading that ASAP, rather than keep supporting it.
Only if you care about IE on Windows XP (which is no longer supported and no longer gets security updates) or Android phones more than 4 years old (2.3 Gingerbread and older). SNI works fine on other devices.
Have you measured? Do you have numbers for how many users you have running one of those two environments?
All modern browsers support it, as do Nginx and Apache.
Also, who pays for all this infrastructure? Mozilla?
Sponsorship is provided by multiple companies, including Mozilla. See https://letsencrypt.org/sponsors/ and https://letsencrypt.org/2015/04/09/isrg-lf-collaboration.htm... for more.
For now, the certs are cross signed by "DST Root CA X3" operated by Identrust. This root has very strong inclusion.
For specifics, please see: https://groups.google.com/a/letsencrypt.org/forum/#!msg/clie...
An exception from that rule in the wake of Heartbleed would arguably have been appropriate, but the business model as such is in no way bad. If the whole SSL industry worked in a way that put price and cost in proportion, there would be no need for Let's Encrypt.
I think it's quite understandable that they charge for things that cost them money, but keep the rest free. You can't really expect for them to give out for free something that has a cost for them.
(Root in Windows, Cross-Signed by StartSSL for others)
1. No Expiration for 3 Years
2. 256-bit strong encryption with 2048-bit SSL certificate
3. Domain validation by trusted Root certificate authority.
4. Lowest price SSL
Get Comodo PositiveSSL Certificate at only $4.99/year from CheapSSLSecurity and make your self free from SSL Expiration.
Visit here for mode details - https://cheapsslsecurity.com/comodo/positivessl.html.