Let's Encrypt Blog

We're working on an FAQ. This thread has been really helpful in clarifying which Qs are FA :)

With regard to your questions:

> Will it provide wildcard certs?

Not initially, but possibly in a future iteration.

Note that having an automatic CA addresses some of the use cases for wildcard certs. Namely, if you're using a wildcard cert just to avoid having to manage individual certs for foo-1.example.com through foo-N.example.com, you can just have them each automatically get a specific cert.

> How does it auto-renew, does it have to run all the time?

That will depend on the software running on the web server. The current "node-acme" and "lets-encrypt-preview" implementations in the Github repo are examples. Ultimately, in addition to these tools, it would be great to have ACME / LE support built into web server platforms, which are already running all the time.

> Why is the cert for identrustssl not trusted in Chrome or Safari? That doesn't inspire confidence : https://www.identrustssl.com/

I don't know what the story is with that site, but I believe the Let's Encrypt CA will be cross-signed under the same IdenTrust CA that issued the cert for https://letsencrypt.org/. So Let's Encrypt certificates should work wherever that site works (which includes Chrome and Safari, at least on my MacBook).

> Can every CA support issuing certs this way please? :)

I can't speak for other CAs, but we are definitely open to other CAs re-using technologies from Let's Encrypt to…

Not making that point at all. Just making the point that related certificates and keys need to be looked up at run time from some secure place rather than be provisioned onto a file system at build time or via some hard to automate sysadmin ritualistic dance on the command line post startup. If in amazon, the secure parameter store is a good place for storing secrets. They also provision nice EC 2 credentials to hosts allowing you to access resources securely without having to rely on silly ssh keys baked into images or passwords passed around insecurely. And of course they allow you to centrally manage ssl certificates as well and manage provisioning those to things like load balancers. Kubernetes has nice infrastructure for this as well.

The point is that this stuff should never be baked into docker or ec2 images and having software expecting to find these things in some file on the filesystem actively makes it harder to configure it in a sane way.

I've seen quite a few docker images that require me to mount a volume with certificate files to work at all. The only way to beat some sense into that is to customize the Docker file and template these files (e.g. dockerize is great for this). Sane deployment automation seems to be an afterthought with many developers.

Since you brought up SSL, a nice innovation a few years ago was https://letsencrypt.org/ which uses short lived certificates that need to be renewed regularly. That sounds like a good practice to do anywhere…

Hi Galen,

If you use Stripe, Twitter, npm, or your bank, you'll see the company name in a green bar. That's an EV certificate and is the only way for a website to prove a company's identity.

EV certs are great, particularly if you're selling something or people are logging into your site.

Since they involve a bunch of verification, the industry standard time get the certificate is normally about 7-21 days.

https://certsimple.com, my company, live checks data while you enter to do EV in an average of 5 hours. It takes 80 seconds to apply, including making the CSR - no Q and A in a terminal, no installing anything, just cut and paste.

Because of this, we're faster at EV than everyone else.

We also give 5% of our revenue to groups that make strong crypto happen - we cut our first cheque to OpenBSD Foundation last Friday. We also publish a bunch of interesting research around performance and security at http://certsimple.com, including OSS code to recreate our results.

Hope that helps! Email me any time at mike@certsimple.com if you have questions.

Mike

PS. if you don't need EV, we recommend you get a free certificate from http://letsencrypt.org which should be launching soon.

Mike from CertSimple here, from my old openid account (as I'm replying too fast with my other one):

> $469 USD per year?

No. All certificates are two years - the big price is the total. I've made this more apparent on the front page.

If someone wants a non-EV cert we also recommend https://letsencrypt.org

We could easily sell non-EV certs - they can be generated in seconds as they don't require manual ID verification to make a quick buck, but I think poor identity verification is what got SSL into the current mess we're in. You'll note GitHub, Stripe, Mozilla and npm have EV certs. Make of that what you will.

Unfortunately letsencrypt doesn't do EV certs.

We compared Symantec (whose brands include GeoTrust) when deciding on a CA partner. We picked Digicert based on the issuance speed and business practices. Symantec upsell IE5-level export encryption as a security feature. We don't want to support that.

The CA we chose to partner with - Digicert - who we have the same prices as - sits in the middle of the market. They makes the certs for GitHub, Facebook, Intel, Yahoo, and Nintendo.

Is this machine-generated text? That or it's badly translated. Either way, it's strangely incoherent and subtly flawed.

Take just the first section. It talks about a bubble sort of ints. Then provides code for bubble sorting strings [1]. Then talks about "sign position in the ASCII table". "linking to the native sort function" is... not the right term (what happened to "call"?). And then we suddenly talk about "the element to be found" (weren't we just sorting?). The rest of the article is in the same vein.

I hope I'm not coming across as just picking on someone's English skills - even with perfect English I would find it hard to follow the train of thought.

[1] This is subtly different because (naive) string comparison is not constant-time, unlike comparing ints in most languages. I was half expecting the article to go there but it didn't.

PS: If not for the discussion here, I would've skipped the read because the site has no HTTPS. Please get a cert, it's free: https://letsencrypt.org/

> Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion.

> Referring to solutions that are under construction doesn't cut it. If you're that passionate about it, contribute to the SSL cert solution yourself instead of to the endless calls for HTTPS-only

Right. In similar threads, I've seen a lot of people linking to Let's Encrypt[0]. The idea of that project is great but, at best, all we can do now is discuss how to enforce HTTPS once Let's Encrypt (or something comparable) is available. Anybody who runs a small, personal website that generates no revenue would essentially be screwed if it were enforced before then, as (and someone can correct me if I'm wrong here) there aren't really any affordable options at this point for people who don't have much money to throw towards their site.

[0] https://letsencrypt.org/