Leaving Beta, New Sponsors
letsencrypt.org
letsencrypt.org
The fact that they have chosen to reduce certificate lifetime in order to encourage automation is a really big win for the security of the web as a whole.
Also linked lower down in the thread
There's a staging server issuing untrusted certificates with significantly higher rate limits for this purpose. With the reference client, it's a matter of using the --staging flag.
If you are trying out the client for the first time, you may want to use the --test-cert flag, and a domain name that does not receive live traffic. This will get certificates from our staging server. They won’t be valid in browsers, but otherwise the process will be the same, so you can test a variety of configuration options without hitting the rate limit.
Without using the various hacks people have created, you can generate the certificates on linux and then move them over to windows, but doing this all the time is extremely inconvenient.
I hope that this gets addressed at some point, because encryption is important for everyone, not just linux admins.
From https://github.com/letsencrypt/letsencrypt:
"The Let's Encrypt Client is BETA SOFTWARE. It contains plenty of bugs and rough edges, and should be tested thoroughly in staging environments before use on production systems."
And NGINX support is still labeled "highly experimental".
Not complaining though; these things take time. Thank you for bringing free encryption to the masses, Let's Encrypt!
If you're looking for a Go client, lego[1] is awesome.
at the very least, it'd be nice if people stopped referring to other implementations of the LE spec as "unofficial clients".
https://github.com/hlandau/acme/blob/master/acmeapi/ocsp.go#...
In case it is not obvious, anyone in a privileged point on the network can fill resb with enough data that the program panics due to OOM and crashes. ioutil.ReadAll really needs a big warning in the docs because I have seen this pattern far too often.
- download letsencrypt-auto
- ./letsencrypt-auto
- download letsencrypt.tar.gz
- extract letsencrypt.tar.gz
- ./letsencrypt-auto
Another example: I recently wanted to run IDA on Arch Linux, but there are no 32-bit Qt5 packages. Compiling Qt5 is more painful than installing Python.
Rust and Haskell are both examples of safe languages. These languages admit very few bug classes. Both also compile to binaries; I'm not sure why you're touting that as a feature of Go.
That's not even a useful feature in this case. Running a python program is just as easy as running a binary from the user's perspective.
Good to see most of them using HTTPS for their homepage. Though Cisco and Gemalto don't yet.
Email sponsor@letsencrypt.org to coordinate.
http://appleinsider.com/articles/12/02/02/tim_cook_exposes_t...
EDIT: Any chance Let's Encrypt (or the underlying 501c3) could obtain cybersecurity grants from the US government?
Writing multi-microservice apps in Node just got a lot easier to deploy for my side projects and small consulting clients - as well as cheaper. Of course it's safer, you never have to think twice about doing TLS.
That said, I'd still opt for a wildcard certificate for anything enterprisey.
Thank you to all the people who worked for years to make it happen.
Let's encrypt can be used to generate a certificate for every subdomain, though it's a little more work compared to just using a wild card certificate.
Many sites use wildcard certs because they're the simplest way of getting SSL for your entire domain. There is one huge problem with that, though: Sharing the private key between different services means that the security of your private key is only as good as the weakest link. If any of your services suffer a compromise that leads to a private key leak (i.e. Heartbleed), all your other services are now vulnerable to MitM as well. Not just that, but weaknesses in your TLS configuration on one service could have implications on other services as well, as demonstrated by the DROWN attack.
That is not to say that there are no valid use-cases for wildcard certificates. If you're, for example, hosting a SaaS where each customer gets a custom subdomain, but the infrastructure behind each subdomain is essentially the same, there's no additional risk and wildcards are the perfect solution. If you're just getting a wildcard certificate because it's the most convenient solution, however, you're probably weakening some of your infrastructure in exchange for that.
This is something entirely orthogonal to the number of certificates. You could have 1000 codebases with different attack vectors under one SSL certificate, or 1 codebase the same attack vectors serving up 1000 SSL certificates.
What I was trying to say was that it's a good idea to have one key per DISTINCT($attack_surface), which includes anything from physical security to the software stack, in order to limit the damage during a compromise. Throwing wildcards at everything tends to go against that principle, even though I admit there are use-cases where wildcards are entirely appropriate (namely those where each subdomain has the exact same attack surface anyway), and using something else isn't worth the trouble.
Even if it was just spitting out a string that I needed to add/edit in my zone files (self-hosted DNS) every ~90 days, I'd be fine with that.
I haven't had much luck finding clients w/ support for this. I did find one that supported using Route 53, etc., via the APIs, but that didn't help me any.
If anyone is working on something like this, I'd be happy to throw a few dollars their way.
[1]: https://github.com/letsencrypt/letsencrypt/wiki/Links#bash
In the meantime, other CAs are starting to offer free DV certs (Symantec being the most recent example), although there's no word yet on ACME compatibility.
"1.7 million certificates for more than 3.8 million websites"
How is this possible if they (AFAIK) don't issue wildcard?
So I think it's actually essentially unlimited, you just can't request the exact same certificate more than 20 times per week
An extreme example would be DDNS providers like No-IP.
[ed to add:] Note that while you can just use example.com, or add alternate names, that would mean that a compromise of www1.example.com also compromised the key used for db1.example.com etc - which would largely defeat the purpose of splitting up different services across different vms/zones/machines in terms of security compartmentalization, because you'd only need one copy of the key to mitm all services.
(For some setups, where everything is a set of web apps/services, and TLS is terminated at the load-balancer/reverse proxy, this is a moot point -- but that's not always a good idea. See eg: how Google suddently rushed to encrypt their intranet after it turned out NSA had been happily snooping on everything from the "inside" via datacenter links that I assume were across rented "dark"/dedicated fiber).
Wildcard certs start at $100/yr (for -the- cheapest) and go quickly up from there.
Many people are not using SSL for many use cases because of this, and that's bad. Why leave them out in the cold for doing things like enforcing CORS security?
It's mind boggling to me that they could leave them out of the final product.
FWIW, I donated to Let's Encrypt in its early stages (and considered sponsorship), so it's not like I'm trying to just freeload here. I'm feeding a lot of money into broken system and I hate doing it.
One last thought: Google is about to start docking sites for not using SSL, which means that a lot of sites are basically going to be forced to buy these expensive certificates in order to play. This is a really artificial and sad barrier to entry for small startups. Security and privacy shouldn't just be the purview of the economically privileged.
With the wonderful work you have been doing with this project (even if I don't host anything on it myself, I'm much too much of a masochist to outsource my web hosting, when I can rent a dedicated server for much more, and do much more work to end up with the same service ;-) -- I think it's terribly wasteful that you have to spend time worrying about trivial things like paying for a wildcard cert, when you could be playing with other, more useful stuff. And, yes, I too hope that Let's Encrypt will support wildcard certs soon.
Keep up the good work, and the transparency! (Btw, are you working on a follow up to: https://blog.neocities.org/open-company-progress-report-2014... or did I just miss it)?
I would very much like to see wildcard support in ACME and hope that Let's Encrypt will adopt it eventually (although I think clients should offer it as an opt-in, as not to encourage practices which are bad for security), and I think that both of your examples are a good fit for wildcard certificates. I'd probably still stick with a regular wildcard as well - $100/yr vs. managing ~1k+ SAN certificates sounds like a bad trade-off - but I thought I'd mention it anyway.
I've been using Let's Encrypt for my personal blog and I definitely appreciate the free security that is does offer, even without wildcard certificates.
Honestly, wildcart certs would make my job a lot easier too, but with automatic renewal I'm more than happy to deal with multiple certs and stop giving the commercial CAs my money.
This is still a WIP in the official client, but there are a number of other clients with dns-01 support[1].
Publicly trusted CAs are not allowed to issue certificates for internal domains (i.e. made-up names which don't end with an ICANN TLD.)
[1]: https://github.com/letsencrypt/letsencrypt/wiki/Links#bash
How is it supposed to work? How can LE know that you are 192.168.1.24? Maybe we'd need some kind of certificates that are only valid within a certain zone? How would that work?
Thanks.
I personally like who's behind it. AFAIK, Let's Encrypt started with EFF sponsorship, later came Google, Mozilla, Facebook, now Cisco, Akamai, HP.
Probably there are other differences, would be glad to know.
[1] https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.le...
[2] https://www.ssllabs.com/ssltest/analyze.html?d=www.startssl....
It's true that they embrace a lot of best practices, like short certificate lifetimes, automation, logging all certificates to CT log servers (which StartSSL started doing quite recently as well), etc. The client also helps with securing your TLS configuration, among other things.
I love the landing page, it's clean, well organized and simple.
The web has a new server. If I trick the server into thinking that stuff I write gets hosted on example.com, it will generate a certificate asserting that I have a right to post stuff on example.com. It's easy for me to get that certificate revoked, but hard for the legitimate owners of example.com to do so.
Comparing this to self-signed certificates, I can think of a bunch of drawbacks, but I can't see any advantage. I hope I'm missing something.
It's not self-signed: Let's Encrypt is a certificate authority, which signs the certificates it issues.
Not a problem specific to LE, but to any DV cert.
http://i.imgur.com/jvp6a8M.png
Open Sans does not render very well on some platform combinations.
Edit: I should say your specific version of Open Sans. Your 14272-byte version of OpenSans-Regular.woff renders like this, whereas other sites' 21956-byte version renders fine.
Designing a harmonious and consistent UI under these conditions is difficult.
But I've seen it break on other platform combinations too, though. If you google around stackexchange and the mozilla forums, you'll find others.
Given how common that font is and how well visited that page is I think it's pretty obvious your system is broken.
Can you check to see if you have the font installed locally, and if uninstalling it (or updating it) changes the behavior?
Edit: Do you get the same issue on https://leclan.ch/ ?
Edit: HN's VPN endpoint hatred is preventing me from replying, so I'll post here as an edit:
Not likely eot/svg. You and LE are both serving me OpenSans-Regular.woff - yours is 21956 bytes, and theirs is 14272 bytes.
Could likely be something to do with fontconfig on your system.
I wonder if anyone has created a simple middle service that can locally cache the certs so you talk to the cache server?
I’ve been through that, now I just use https://gethttpsforfree.com/, which avoids the issues.
And it doesn’t wreck my Apache config every time.
In the end though, I have more than 7 certs for my main domain--With a bunch of services built up over the years, I have roughly 14 or 15 certs (so it took me 3 weeks to get all my certs created). Subdomains count against your domain limit, so "mail.example.com", "blog.example.com", and "www.example.com" count as 3 certs for "example.com".
Should we be worried that LE is sponsored by the big players (cisco et al.)
Not implying that we should. Just genuinely wondering if we should be wary or if it means anything at all, for the future of LE I mean.
ps:might be my misunderstanding as im not sure what sponsored actually entails.
To me this is a deal-breaker. Cisco did so many bad things in the past in terms of privacy that the only good news is that now I know to stay away from LetsEncrypt.
This seems like a conceptual misunderstanding of how TLS works. Let's Encrypt does not have access to your private key and does not have the ability to decrypt your traffic. They put a stamp on your certificate saying "Yep, this key belongs to this domain" - that's it.
I don't think that's realistic, but if we're talking conspiracy theories...
Noticed the domain, now glad to know.
The title could do with a fixup though - my RSS reader doesn't show the target domain.
+ client side certs.
Really easy to setup, thanks for all your efforts!
In terms of setting up HTTPS, I use nginx.
Then pointing nginx to the "live" cert location and setting a cron job to renew every 4 weeks or so pretty much takes care of the whole process. I notice the FBSD LE client was just upgraded, not sure what new features it offers, but certainly should work at least as well as before.
Possible there is support for Windows and IIS, but their own website strongly suggests otherwise.
EDIT: if they consider their client and their CA as two different products, well, right now the website conflates the two badly. And there's absolutely nothing there to suggest it supports Windows/IIS.
> And there's absolutely nothing there to suggest it supports Windows/IIS.
Their "system" is an API for issuing certificates. There's nothing platform specific about that.
> right now the website conflates the two badly.
From https://letsencrypt.org/getting-started/: You’re welcome to use any compatible client, but we only provide instructions for using the client that we provide.
Edit: This is the protocol they use: https://github.com/letsencrypt/acme-spec
I found the link here: https://letsencrypt.org/how-it-works/
Now I'm just confused.
But I still say: if their mission is to make it as easy as possible to install a SSL cert on any website, as long as they don't have any (apparent) support for Windows/IIS, they're a long, long, long way away from fulfilling that mission and probably shouldn't be leaving beta.
[1]: https://github.com/letsencrypt/letsencrypt/wiki/Links#window...
Maybe you're right, but how would a potential user know it?
That being said, I sincerely hope that anyone responsible for TLS deployment knows how to use a search engine and enter "letsencrypt windows".
Seriously, though. Maybe I misunderstand. Wasn't the entire point of this project to make it as easy as possible to add and maintain a SSL cert for any website? If that's their mission statement, then they're really, really, really far away from that goal and I re-assert that they probably shouldn't be calling it "production-ready".
If I'm wrong, and that's not their goal, well, fair enough.
All I'm saying is I run a website based on IIS and I go to their website, there's absolutely no hint that they support Windows in any fashion whatsoever. Nor even a hint that I might be able to Google for alternative clients that do.
Now I think that's a pretty damned big flaw. Maybe I'm the only one.
EDIT: (As an aside, the documentation is part of the project, so if it's "not perfect yet", as you claim, that also supports that they're not ready to leave beta yet.)
Traditional CAs leave the actual configuration of said certificates completely up to you. Let's Encrypt, in addition to having a protocol that's based on an IETF specification, offers a client which tries to completely automate this part, as well as renewal. Right now, this only works for apache (and, experimentally, nginx) with the official client. Note that just this alone is significantly more than what you'd get from a traditional CA. In addition to that, you also have a number of third-party clients, many of which do this for IIS as well.
The stability or "feature-completeness" of the CA Let's Encrypt is completely independent from the client ecosystem. Let's Encrypt provides certificates, and those certificates work on Windows - that's pretty much it. That's why the beta label was removed.
---
The answer is: I don't. I hit the "getting started" page. I see instructions for Linux. I don't have Linux. I say "oh well," and leave.
In fact that scenario is pretty much exactly what happened a few weeks ago when someone told me about let's encrypt. Which explains the post I made to this thread today.
example:
https://knowledge.rapidssl.com/support/ssl-certificate-suppo...
You're also missing my point that a documentation issue doesn't mean a service deserves the "beta" label.
How do you know that there are ACME clients for Windows? Irrelevant towards the beta status of the LE CA.
If you make the process require knowledge of acronyms like "ACME" or "LE CA", well. You've not attained that goal. You're not even close. That's the message I'm trying to get across here.
If I misunderstand the goal, then by all means, correct me.
I was excited to use this, kept up with the news for over a year then when it launched there were no really practical to use windows clients and after fighting with it for a while we decided it was cheaper and easier to just renew our paid cert instead of wasting time with it any longer.
I hope there is a viable automated windows client for this before we have to renew again next year but everything is pointing to this being more of a non-windows thing so far.