9 ms·
Let's Encrypt: an automated certificate authority to encrypt the entire web
- evenh 7y agoThere is an alternative ACME server implementation available from Buypass: https://www.buypass.no/ssl/products/acme https://www.buypass.no/ssl/products/acme. Haven't tried it personally, but they launched support for ACME v2 in late 2019.
- jhoechtl 7y agoI have deep concerns about the development to criminalize and ban non-https web sites from functioning in mainstream web browsers. Many flee to Letsencrypt certificates which have a short TTL frame. What if Letsencrypt gets bought by Google / Microsoft and the free lunch is over? The end of the free web as we know it... ?
- sschueller 7y agoI am also concerned about the centralisation of everyone going to Let's encrypt. Yes they are non-profit but they are located in the United States and must follow US laws.
- cpach 7y agoAnyone could launch LE2 outside of US. All the protocols are open. You need some capital though.
- darkwater 7y agoAnd some already trusted CA to cross-sign your certificate...
- cpach 7y agoThat is not strictly required though. LE did this in order to speed up the rollout but you can also skip that step and submit the root CA to the appropriate places, e.g. Mozillaʼs CA Certificate Program.
- darkwater 7y agoAnd then you lose all the older browser installations... There was a reason if LE went the way they went and basically it is retro-compatibility. Anyway I'm not arguing that it would be impossible to create an LE2 but it would not be that simple. Especially if the buyer is someone already in the certificates business that wants to destroy the "free-for-all" concept.
- GuyPostington 7y agoTo help produce an LE2, please contribute to https://github.com/tdelmas/Let-s-Clone https://github.com/tdelmas/Let-s-Clone
- user1980 7y agoToo big to fail: It's not just for banks any more. If LE is compromised a few times and some fraudulent facebook.com or google.com certs leak out, how long before Firefox/Chrome/Edge blacklist their root cert like they did with Symantec[1], and end up breaking half the internet? I understand that ACME is an open standard, but can someone point me to an alternative ACME provider that isn't "please call us for a quote" enterprise-grade? [1]: https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/ https://blog.mozilla.org/security/2018/03/12/distrust-symant...
- move-on-by 7y agoSeems like a reasonable fear, but it is mitigated by short certificate lifespans. Symantec was much more painful to distrust due to multi-year certificate lengths.
- nickik 7y agoISRG is a California public benefit corporation, and is recognized by the IRS as a tax-exempt organization under Section 501(c)(3) of the Internal Revenue Code. Our EIN is 46-3344200. And the protocol to talk to LetEncrypt is open, if LetEncrypt turned evil, you could go to other providers without updating your overall process.
- fulafel 7y agoIt all depends on what root CAs the major browsers ship with. If browser vendors consider it good to have free certs available, like they seem to, then EFF/Mozilla/etc could start a "Let's Encrypt II" in case something happened to them.
- GuyPostington 7y agoYou could help too if you choose to contribute to this project! https://github.com/tdelmas/Let-s-Clone https://github.com/tdelmas/Let-s-Clone
- CKN23-ARIN 7y agoFun fact: LetsEncrypt cost $3.6M to operate in 2019.
- cpach 7y agoIMO that’s a very modest sum considering what it does. LE scales extremely well.
- PedroBatista 7y agoMy question is: who pays for the whole party and more importantly will they continue to pay?
- cpach 7y agoYou can find that info here: https://letsencrypt.org/sponsors/ https://letsencrypt.org/sponsors/ Why wouldn’t they continue to pay? Hint: Presumably the sponsors feel that they get something more than only goodwill for their donations.
- klohto 7y agoJust a rough estimate: 7x Platinum $350k/y = 2,450M 2x Gold $150k/y = 300k 73x Silver $40k/y (vary depending on # of employees) = 2,920M In total, LE receives over $5.5M a year. I think they are covered
- jaas 7y agoThis math is off because the vast majority of Silver sponsors are at $10k, and some of the sponsors at all levels are in-kind, meaning we get something other than cash from them. In 2019 we spent $3.35M in cash (we came in a little under our projected budget of $3.6M). We raised $3.82M in cash between sponsors, grants, and individual giving.
- dlgeek 7y ago(For those who aren't aware, parent is the executive director of LE).
- moralestapia 7y ago>It won't happen man, don't worry ;) Fast forward a few years, ICANN v2.0
- cpach 7y agoIt could happen. Or maybe it won’t. We’ll see.
- profmonocle 7y agoICANN is a natural monopoly because DNS was designed to have a single, central authority. Switching to a new DNS root without ICANN's cooperation would be a monumental task, and they know it. But setting up a new CA, while expensive and time consuming, is very doable. If Let's Encrypt somehow became as corrupt as ICANN, there'd be incentive for some organization to create an alternative.
- buboard 7y agoLets hope that SSL certs will only be a temporary solution. Why can't we switch to a system that doesn't depend on central authority? In the meantime, it would be nice for letsencrypt to pledge not to take big donations from corporates.
- zozbot234 7y agoYou can use self-signed SSL, it's essentially TOFU. Or install a local cert authority on your own machines.
- yrro 7y agoTis a shame web browsers are only able to use Kerberos to authenticate connections and not additionally to provide confidentiality and protect the integrity of the communications channel. Certificates are pain in the arse and it depresses me that we still don't have a way to deal with compromised private keys.
- Spivak 7y ago> pledge not to take big donations from corporates You mean the people who actually benefit financially from the service? Look, I get the sentiment but this is a case where the incentives are remarkably aligned. Companies that derive real business value from the service foot the bill while the rest of the world gets free certs.
- buboard 7y agooops i mean big corporates, like, major companies throwing millions at them
- simias 7y agoI'm not too worried. If SSL becomes mandatory and no cheap/free solution is available there'll be a very strong incentive to build a new CA doing what Let's Encrypt does to replace it. Then it's "just" about getting browsers to trust the new CA and at this point I think the main threat is the Chrome monopoly, not Google buying Let's Encrypt. After all the CA system is effectively decentralized.
- whatshisface 7y ago>there'll be a very strong incentive A $0 incentive, to be specific.
- dwild 7y ago> Then it's "just" about getting browsers to trust the new CA and at this point I think the main threat is the Chrome monopoly, not Google buying Let's Encrypt. Even for Let's Encrypt it took 3 years before they were comfortable to abandon the IdenTrust cross signed certificate, and they won't even do it until July 2020, so a whole 5 years. That's from a very popular NPO supported by many corporation.
- abjKT26nO8 7y agoThis is just a symptom. The underlying problem is the whole model of the SSL PKI. To quote Ivan Ristic's Bulletproof SSL and TLS: > There’s an inherent flaw in how Public Key Infrastructure (PKI) operates today: any CA is able to issue certificates for any name without having to seek approval from the domain name owner. It seems incredible that this system, which has been in use for about 20 years now, essentially relies on everyone—hundreds of entities and thousands of people—doing the right thing. My hope is that in time we will move to something like DANE[1]. [1]: <https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities> https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
- pornel 7y agoIt's fantastic that Let's Encrypt made short(er)-lived certificates possible. With automation in place it doesn't matter if the cert lives a year or a week. Eventually it will get short enough that we won't have to bother with revocation lists, OCSP, etc.
- tialaramex 7y agoIn the medium term the intent here is Delegated Credentials. The TLS working group is putting the finishing touches on a mechanism which goes like this: You still have TLS certificates like today, but the private key corresponding to the public key in that certificate lives on a dedicated machine that's not accessible to the outside world, rather than your web server. This dedicated machine uses the private key to sign tiny messages which basically say "I, the owner of this TLS certificate you've seen, authorise this web server for a short period (say 24 hours) to prove its identity using a short-lived key which you can verify using public key P". Then your web servers serve up the TLS cert (for which they don't know the private key) this short message with P in it, and proof they do know their short-lived private key which can be verified using P. Browsers check the certificate, the delegated credential message and so on and you've got all the same security but with much shorter lived credentials. This way, when somebody finds a zero day in your tremendously complicated web site and uses it to steal the private key, that key is only valid for maximum 24 hours and so you can close their window of opportunity relatively swiftly if you're on top of it. Meanwhile the dedicated server for making the signed messages is not publicly accessible and can be simpler and thus more secure. This isn't really a way forward for making toy web sites with 1000 visitors per day, but if you're building anything where you already have multiple servers possibly in different locations then it's more interesting.
- throw0101a 7y agoACME wasn't the first attempt at automating certs. See Simple Certificate Enrollment Protocol (draft) and Enrollment over Secure Transport (RFC 7030): * https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_Protocol https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_... * https://en.wikipedia.org/wiki/Enrollment_over_Secure_Transport https://en.wikipedia.org/wiki/Enrollment_over_Secure_Transpo...
- tialaramex 7y agoACME's secret sauce is the name validation challenges, not present in SCEP and other prior standards. The same people, roughly, worked on two things, one of which is made very visible in ACME a published standard, but just as important is the other side of the coin. The Baseline Requirements https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/ from the CA/Browser Forum set out shared rules for how a publicly trusted CA must do its job. From the outset the BRs have been clear that a CA needs to somehow validate that it's issuing the certificate for some-fqdn.example.com to the people who actually have some-fqdn.example.com or else this PKI is futile. But until relatively recently the BRs were pretty vague on how exactly they ought to do that. As a consequence some CAs did an admirable job, many did a passable job, some were a bad joke either through not grasping the threat model or just ordinary incompetence. A trusted CA for example once had a system which would check you owned www.example.com by connecting to example.com over HTTP and making a request for a magic document, say http://example.com/xyzzy.html http://example.com/xyzzy.html then it would grep the reply from the server for a magic string, which was the same as the name of the document, in this case xyzzy, and if it was found the check passes. But wait a minute, this means if your server says "404 Not Found: xyzzy.html was not found" the check passes and you get a certificate. Oops. Now, not checking for a 200 OK was a bug, but even if you do check for 200 OK this validation clearly more of a polite "Keep out" notice to bad guys rather than any sort of actual defence. So in the same period Let's Encrypt was being set up and ACME was being defined, the CA/B Forum also reformed the BR definition of how to validate DNS names using some of the same personnel. The result is the Ten Blessed Methods (although right now there are actually more than ten of them) and ACME is an automation of just three of those specific methods. Since then CA/B Forum has also worked on obsoleting the riskier and less useful methods and creating newer safer ones. Today that would be /.well-known/pki-validation/xyzzy.html safely in a reserved namespace, and it'd need a value inside it that's either entirely random or is determined by some other factor not under an attacker's control (in Let's Encrypt the equivalent string is a hash of the LE user's public account key). Some of the Ten Blessed Methods are inherently kinda manual. Some just aren't very universal. So ACME and Let's Encrypt focus on the three which are most suitable for automation, surfaced in a way that is hopefully even more secure than required by the BRs and made available to everyone.
- 3dfan 7y agoIt's still a pain in the ass to manage wildcard certificates with letsencrypt. Especially when your DNS registrar does not support DNS changes via API. And even if the registrar supports it, you have to build and maintain the code that talks to the API. Yuck. I wonder why they don't allow whover controls the domain name to use the domain/.well-known/acme-challenge to create wildcard certs that are valid for all subdomains of that domain.
- bemused 7y agoset up your own dns-server for wildcard certificate validation on all your domains: https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns quite straightforward to set up - works great here for ~50 domains from various registrars
- ajphdiv 7y agoWow. Why did I not think of this. Thanks for sharing.
- _nickwhite 7y agoThis seems like a good idea... until your self-hosted DNS server starts getting DoS attacked. I've had seemingly innocent servers practically taken off the Internet with UDP/53 floods- very easy for any 12-year-old to execute.
- bemused 7y agothis dns server only needs to run for 5 minutes every 4 weeks while renewing certs - no open ports otherwise
- b3lvedere 7y agoNiel Pang's acme.sh script works perfect for me: https://github.com/acmesh-official/acme.sh https://github.com/acmesh-official/acme.sh
- 7y ago
- buboard 7y agoIt s funny how free certificates are now easier to use than overpriced ones. Knock on wood, letsencrypt works well , except when it doesn't , e.g. when you remove a subdomain from your webserver and then it refuses to renew them for the entire domain. But still it s the best thing to happen to the web in a long time.
- GuyPostington 7y agoYou should post on the community forum if you ever experience an issue like that again. Https://community.letsencrypt.org
- buboard 7y agothanks. it was actually my fault, i shouldn't have deleted the virtualhost. but when you have many domains these things can happen
- vegardx 7y agoThere's no alternative when you have multiple SANs, all of them have to be validated. But since they are free and easy to automate you can just issue a certificate for every domain.
- otterlicious 7y agowhen you remove a subdomain from your webserver and then it refuses to renew them for the entire domain Most Let's Encrypt clients have the ability to automatically exclude any subdomains that have stopped working. However they don't enable this by default because they have no way of knowing if the domain is really gone or if a janitor just happened to unplug the server to plug in their vacuum when the renewal was attempted.
- shill_predictor 7y agoFor me it was a cherry on top of my home built pipeline. I was able to learn the general cert usage through setting up my CI/CD. It was fun and costed me nothing.
- inkeddeveloper 7y agoSamesies. I'm glad someone else considers home built pipelines a fun hobby as well.
- Spivak 7y agoWhat does your pipeline look like? I've always wanted to do this but a lot of CD systems are so heavy. Great at work but super overkill for a homelab.
- shill_predictor 7y agoGitlab for CI, Nexus for jars and docker containers and routing traffic with traefik. Its super easy if you setup them using docker. I will move to jenkins CI tough. Its plugin/ecosystem brings you much more value over gitlab.
- feisuzhu 7y agoI'm always annoyed by the fact that no spec exists for a `intermediate CA for a particular domain`. If it exists, multiple level wildcard pain disappears and Subject Alternative Names stuff is not needed.
- szubster 7y agoX.509 Name Constraints extension is what you are looking for. They are VERY expensive when ordered from public CA, but we use them at work for internal PKI.
- yrro 7y agoDo real world https clients actually verify the end entity certificate against the name constraints of all the certificates in the trust chain?
- cpach 7y agoGood question. I’m guessing that modern browsers such as Google Chrome and Firefox does. When it comes to agents such as wget, curl, mstsc.exe, etc, then I’m not so sure.
- vegardx 7y agoI believe clients that don't support name constraints extension won't pass certificate chain verification should the root, intermediate or certificate itself have a name constraint defined.
- szubster 7y agoYes, they are. The extension should be marked as critical, so if the client does not understand it it should error out. At least java, go, curl and all major browser support it.
- bostik 7y agoOh cool, so they work now? When I was setting up internal PKI back in 2015, I wanted to limit the CA to be less dangerous. At the time name constraints did not work. At all. It wasn't possible to create a CSR with the field in OpenSSL, because the config parser didn't know about the key. So I did what any self-respecting person would do: I created the CSR manually with low-level API, plugging in the OID directly. When I tried to sign that one, the openssl libs just blew up with BIO_read_XXX errors everywhere. I then tried the same thing with golang's TLS stack. Trying to operate on a CSR with name constraints triggered a panic. So I gave up - no name constraints on internal CA. Never got to try it out, but considering how the client libraries behaved on seeing the flag, it would have been amusing to see how different clients behaved when served with a certificate chain that ended up in name constrained CA.
- orsenthil 7y agoAdrian does a great job in summarizing the Let's Encrypt paper. He highlights all the important sections and gives the reader the complete overview of the system. Thanks for the summary.
- stevespang 7y ago"Today the majority of HTTPS sites use Let’s Encrypt and it’s the fastest growing CA, but it’s usage is still rarer among the largest sites." . . . who are the one trolling users for almost a hundred dollars a year fees for https like GoDaddy . . . which you get for free at QTH.com hosting . . .
- mmmuhd 7y agoWhile let's encrypt is great I keep getting worried let not what happened to the team managing openssl resulting to heartblead bug happen to the let's encrypt team it would be a disaster
- GuyPostington 7y agoCan you give some more insight on what happened to the team managing openssl during that time? I remember being on-call at a job when the news dropped.
- pfarnsworth 7y agoCan I use Let's Encrypt to sign my own personal CA so that I can issue certs for my domain that are in that chain?
- schoen 7y agoNope! For various reasons, including that the IdenTrust cross-signature has a path length constraint that doesn't allow any longer chains for this path. Also, Let's Encrypt doesn't want to be responsible for supervising the correctness of your CA's operations. In theory this could be practical if you look at name-constrained delegations but it seems to me that there are a lot of practical problems with making this widespread. If you happen to be interested in discussing them in more detail, come over to https://community.letsencrypt.org/ https://community.letsencrypt.org/ and create a new "Issuance Policy" thread and we can get into it in more depth. But the short answer to your question is simply no—Let's Encrypt doesn't offer this service, isn't currently permitted to offer this service, and isn't interested in offering this service.
- vbezhenar 7y agoThis kind of service would be extremely valuable for some use-cases. But I could see a hard to solve issue here. Imagine that private key for domain1.com leaked and ordinary person (not owner) wants to revoke corresponding certificate. It's enough to tell CA who issued that certificate and it'll revoke it. Now imagine that private key for sub1.domain2.com leaked. It's signed by domain2.com operator who's just small business or some hobbyist guy and does not even read his mail. Should letsencrypt be responsible for revoking those certificates? What if there are 4 billion of those certificates (e.g. 1.1.1.1.domain2.com, 1.1.1.2.domain2.com and so on)? Should letsencrypt reach domain2.com owner and ask him to revoke? Now it's human labour and can't be automated. Should letsencrypt just revoke domain2.com CA if any of his subdomains were compromised? That's not good either. Should we allow domain2.com owner to issue valid certificates for his subdomains without following proper security practice (like not distributing private keys in his devices)? Not a good idea too.
- zeroz 7y agoLet's encrypt support for S/MIME would be great. While seeing great progress in securing the web via HTTPS email still lacks fundamental security. While I would love to see a functioning PGP or other decentralized setup, network effects are a strong force and it's still to much hassle for non-technical people. Free S/MIME would help me to distribute secure e-Mail setup for friends & family. Looking for free or cheap certificates there was no satisfying provider. Either expensive, or not trustworthy server-side generated certificates, or not compatible/ not trusted root authority, or dedicated Windows software for generating certificates: [0] https://www.swisssign.com/email/email-id-silver.html https://www.swisssign.com/email/email-id-silver.html [1] https://www.sslplus.de/bestellen/step1.html?cert=79 https://www.sslplus.de/bestellen/step1.html?cert=79 [2] https://www.dgn.de/e-mail-zertifikat-dgncert/ https://www.dgn.de/e-mail-zertifikat-dgncert/ [3] https://en.sklep.certum.pl/data-safety/id-certificates/certificate-basic-id.html https://en.sklep.certum.pl/data-safety/id-certificates/certi... [4] https://wiseid.com/pricing/ https://wiseid.com/pricing/ [5] https://www.actalis.it/products/certificates-for-secure-electronic-mail.aspx https://www.actalis.it/products/certificates-for-secure-elec... [6] https://volksverschluesselung.de/ https://volksverschluesselung.de/ [7] https://en.sklep.certum.pl/data-safety/id-certificates/certificate-basic-id.html https://en.sklep.certum.pl/data-safety/id-certificates/certi... [8] https://www.bundesdruckerei.de/de/loesungen/Certificate-Service-Manager#CSM https://www.bundesdruckerei.de/de/loesungen/Certificate-Serv... [9] https://www.instantssl.com/ https://www.instantssl.com/
- Avamander 7y agoLE for domain-validated code signing would be good as well. Knowing an executable came from a trusted domain even if it was mirrored or rehosted sounds nice.
- rkagerer 7y agoInitially, ISRG was funded almost entirely through large donations from technology companies. In late 2014, it secured financial commitments from Akamai, Cisco, EFF, and Mozilla, allowing the organization to purchase equipment, secure hosting contracts, and pay initial staff. Today, ISRG has more diverse funding sources; in 2018 it received 83% of its funding from corporate sponsors, 14% from grants and major gifts, and 3% from individual giving.
- castillar76 7y agoThis is good, because having something that owns ca. 60% of the SSL certificates on the internet supported by corporate largesse is not a good route forward. I'm glad that's shifting.
- abrowne2 7y agoKudos to the Let's Encrypt team for their service. I've used it in every project. Much praise!