
Let's Encrypt Launch Schedule - joshmoz
https://letsencrypt.org/2015/06/16/lets-encrypt-launch-schedule.html
======
diafygi
I'm suuuper excited for this to launch! However, it's worrisome that the ACME
protocol (what Let's Encrypt uses) still has a ton of bugs open[1] and they
are still changing the protocol often. Just search for "TODO" on the spec
markdown[2].

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.

[1]: [https://github.com/letsencrypt/acme-
spec/issues](https://github.com/letsencrypt/acme-spec/issues)

[2]: [https://github.com/letsencrypt/acme-
spec/blob/master/draft-b...](https://github.com/letsencrypt/acme-
spec/blob/master/draft-barnes-acme.md)

~~~
cbhl
> _The certs issued using this API end up telling people it 's safe to input
> their passwords or credit card numbers._

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.

~~~
vtlynch
Validation has nothing to do with the security of the certificate. There is
nothing preventing you from using a DV, OV, or EV certificate to transmit any
type of data you want.

~~~
dragonwriter
> Validation has nothing to do with the security of the certificate.

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.)

~~~
vtlynch
Yes, it is true that validation does add accountability and security. However,
suggesting that DV certificates are less suitable than EV certificates for
handling a certain kind of data is nothing more than misinformation.

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.

------
qrmn
I gather they're not launching with ECDSA certificates (and obviously not with
EdDSA or whatever comes out of CFRG, because that's still being discussed by
the IETF/IRTF), but they're going to add it later. Any idea when?

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).

------
jtchang
I am really excited about this whole initiative. Mostly because encryption
should really be standard at this point if not for the hurdles one has to face
in deploying it.

What type of help is the Let's Encrypt team still needing?

~~~
joshmoz
Glad you like the project!

Contributing to our software is one way to help:

[https://github.com/letsencrypt/boulder](https://github.com/letsencrypt/boulder)

[https://github.com/letsencrypt/lets-encrypt-
preview](https://github.com/letsencrypt/lets-encrypt-preview)

Also, if you work for a company that might be interested in sponsoring us,
starting that conversation is another great way to help out.

~~~
diafygi
What are the tiers for corporate sponsors?

~~~
garrettr_
The tiers are Platinum, Gold, and Silver. Check out the current sponsors [0]
and info on becoming a sponsor [1].

[0]: [https://letsencrypt.org/sponsors/](https://letsencrypt.org/sponsors/)
[1]: [https://letsencrypt.org/become-a-
sponsor/](https://letsencrypt.org/become-a-sponsor/)

------
tokenizerrr
Very glad to hear there is a launch schedule, have been curious about how this
project has been progressing. It's a fantastic intiative and I almost can't
wait until September 14.

------
EGreg
Can someone summarize why this is better than, say, StartSSL or AlphaSSL?

~~~
aroch
No predatory pricing (StartSSL has $25 revocations), free (AlphaSSL) and user-
friendly (StartSSL is a UX nightmare). PositiveSSL is probably the cheapest,
well supported cert (certs can be had for $3-4/y).

~~~
yellowapple
Are you sure about that $3-4 price point? The cheapest I'm seeing on their
site is $49/yr.

~~~
electroly
Namecheap sells PositiveSSL certs for $9, I'm sure others are in that price
range as well.

------
masida
Very nice initiative.

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.

~~~
adisbladis
SNI has been a thing for a long while now.. Do you seriously need to support
older browsers than this?
[https://en.wikipedia.org/wiki/Server_Name_Indication#Web_bro...](https://en.wikipedia.org/wiki/Server_Name_Indication#Web_browsers.5B6.5D)

~~~
LinuxBender
SNI is fine for web browsing, but for end-points that need to be reachable by
older versions of python, tomcat, ruby and many proprietary apps, this will
not suffice. This becomes a problem on business to business communications,
automation, API's, etc. For the general purpose websites, blogs, etc, SNI
would be fine.

~~~
hobarrera
You're probably talking about _really_ old versions of applications. I've been
using SNI for half a decade without any issues.

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.

~~~
LinuxBender
If you take a look at the wiki article, there are some versions listed. Those
are still in use. If our company forced people to use SNI, we would be out of
business. There are TLS 1.0+ enabled apps that can't do SNI. Perhaps you and I
are just in very different business models.

------
general_failure
can someone clarify if revokation is free with letsencrypt?

Also, who pays for all this infrastructure? Mozilla?

~~~
bracewel
All the services provided by Let's Encrypt will be completely free, including
revocation.

------
worklogin
Do Chrome and Mozilla have Let's Encrypt in their Root stores? I don't see
them.

~~~
vtlynch
No. The Let's Encrypt root was recently created and will be submitted to root
inclusion programs. It will probably be quite a while until its suitable to
issue certs solely from the Let's Encrypt Root.

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...](https://groups.google.com/a/letsencrypt.org/forum/#!msg/client-
dev/I-iFKihZ4Vo/5g9Xb5SroOsJ)

~~~
worklogin
Dangit, I didn't read the second paragraph. For GA, they will have the cross-
sign. It's just for the EA that they don't.

------
jglauche
Damnit, my existing cert expires September 12. Any free alternatives to that?

~~~
teraflop
[https://www.startssl.com/](https://www.startssl.com/) provides free domain-
validated certificates.

~~~
Karunamon
Please don't use startssl. Revocation costs money, and the company's behavior
surrounding heartbleed was at the very least _very unethical_.

~~~
teraflop
Fair enough, but bear in mind that StartSSL's revocation fee is lower than
what most certificate providers charge as a _starting_ price. Personally, I'm
fine with taking the risk and eating the $25 cost if something unexpected
happens.

~~~
clinta
No company should be incentivising companies to not revoke compromised
certificates. Even if the cost is modest. It's more about not patronizing a
company with such a bad business model than it is about the dollar cost.

~~~
currysausage
StartSSL's business model: making things free that don't cost them measurable
money, and charging for transactions that cost them money.

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.

~~~
Karunamon
How does an automated revocation cost them money?

~~~
currysausage
[https://blog.cloudflare.com/the-hard-costs-of-
heartbleed/](https://blog.cloudflare.com/the-hard-costs-of-heartbleed/)

