Comment by lvh | Hacker News Reader

Comment by lvh | Hacker News Reader

Some context on how this works: your system (usually OS) ships with a bunch of root certificates that are allowed to sign any certificate (de facto). New CAs need to get in that store to be trusted, but they don't get to be in that store until they convince a vendor (here, "root program") to include them.

But LE has been around for a while and its certs mostly work fine everywhere! That's partially because it was already in a ton of root programs, and partially because of cross-signed roots. A cross-signed root is effectively the root CA except signed by a different CA. A client that doesn't trust the new root yet trusts it via the cros-signed root.

Most sites need 2 certificates in the chain to be validated: the leaf certificate certifying the site itself and the intermediate online CA that signs leaf certs. The intermediate is signed by the root, which is in your trust store so you don't need to send it. Lots of sites send it anyway. This is a misconfiguration and just serves to make TLS connections slower: you're sending an extra certificate along that by definition nobody uses. This is because it's self-signed: you either already trusted it anyway (and then didn't need it) or you don't trust it and then the self-signed certificate is unconvincing.

New CAs also need their cross signed root sent along to be widely supported, so they basically get that worse performance all the time. Unfortunately, you don't know in advance which roots a TLS client will trust, so until you're in every major trust store, you have to. Now that LE is in every major trust store, it's a real first-class CA and everyone gets to look forward to doing away with the cross-signed root crutch. (You can't do it immediately because old, unpatched machines.)

LE is great and has done wonders to make all the other CAs up their game.

You can read more about LE's trust chain here: https://letsencrypt.org/certificates/

A reason you might want to send a "root" in some cases:

New roots get spun up all the time (maybe a dozen a year? That sort of ballpark). For Let's Encrypt that meant the cross signing arrangement described, but for an existing CA they can use their older roots to sign newer ones while they wait for trust stores to do their thing, this produces a certificate for the same name, but instead of being self-signed it's signed by the old root.

If you send this cert as well as your ordinary intermediate, some older clients that had no reason to trust the intermediate can now connect it back to a root they do trust. So for a few bytes you get a compatibility win.

This type of thing is also done when a root is replaced urgently due to distrust. Clients that are on top of their game trust the replacement root. Clients that don't know about this distrust trust the old root, which has signed the replacement. So everybody trusts the replacement, yet up-to-date devices aren't at risk from the old root any more.

A mechanism called AIA chasing lets browsers which use it "fix" an incomplete chain, but at some cost to privacy, another approach is to cache bits of chains and try to use the cached bits to fix broken chains, again this has privacy problems. Definitely send your intermediate (any modern leaf cert in the Web PKI has an intermediate) but more might be necessary.

I would like to see AIA chasing done by TLS servers (there's no major privacy concern there) so that this isn't extra work for admins, but we don't live in that world, so it's on you (or tools you use) to get it right.

You're correct, but for clarity for those playing along at home: that's just another variant of a cross-signed root. It's not an actual root CA in the sense that I was using it (self-signed): that is still always pointless.

Interestingly, as shown in the diagram you've linked, in this particular scenario, Let's Encrypt didn't have IdenTrust (owners of the DST Root CA X3 used for the cross signature) sign their new root (ISRG Root X1). Instead DST Root CA X3 was used to sign Let's Encrypt's intermediates, so there isn't actually anything to "do away with" really.

As a result there are two versions of each intermediate certificate, one signed by DST Root CA X3, one signed by ISRG Root X1. The URL for the former is baked into your leaf certificate, you _can_ configure servers to send the other version, and Let's Encrypt in fact does so for the test server required by Mozilla's CA root trust program, but most people don't need to do that.

If there ever is a good reason to switch over (maybe in a few years when DST Root CA X3 is due to expire) thanks to the relatively short lifetime of Let's Encrypt certificates they can move all their subscribers (at least, all those with compliant ACME implementations, if you hard code everything you get to keep both halves when it breaks) without those subscribers needing to even know about it, let alone make any changes.

If somehow the private key of a root CA gets leaked, will that make all devices vulnerable?

Also what is stopping a government from getting access to these private keys?

Yes; nothing.

Until we discover the compromise, yes. We have a few better tools for doing that now, like Certificate Transparency.

A number of CAs are effectively under the control of a government: https://ccadb-public.secure.force.com/mozilla/IncludedCACert...

The CABforum BRs define, de facto, the rules/requirements for being a CA: https://cabforum.org/baseline-requirements-documents/

> The CABforum BRs define, de facto, the rules/requirements for being a CA: https://cabforum.org/baseline-requirements-documents/

Note that there have been several ballots which have been won by the CAs against the browsers, after which the browsers have turned around, shrugged, and just enforced the new requirements for their root stores without them becoming CAB BRs.

Most obviously this applies to Google and Apple requiring all newly issued certificates to be CT qualified.

Note that CABF bylaws require a simple majority of browsers to vote positively for a ballot for it to pass, regardless of how CAs vote.

I've heard great things about Let's Encrypt, many people who I trust use and trust Let's Encrypt, and I use and trust them too.

But beyond that warm fuzzy feeling, and what they write about themselves on their web site, I'd love to know more particulars about the nature of why they're different, why so many people trust them, how they came about, who's running it, who's supporting it, who are they competing against, and what their mission and back story is. Why are they pushing other CAs to up their game, and why weren't those other CAs doing what Let's Encrypt is now pushing them to do, in the first place?

Provides an API to generate, renew and revoke certificate.

Provides certificate for free that are accepted by all browser/OS.

Let the user easily generate wildcard certificate if you control the domain link to it.

In other words, remove the human interaction.

Server can now easily and automatically renew certificate. No need to go through weird interfaces and obscure settings to always have an up-to-date certificate.

Belphemur said it best: before LE SSL/TLS was relatively 'obscure', sure many sites had it, but it was an optional extra that cost a yearly fee. Now, any old joe bloggs can setup a webserver (or use tools like cPanel which have LE integrated) and get the nice shiny green padlock with 'secure' in their browser.

And, if you run your own server, their client even generates the configs for most major web servers on most major OS', so you don't even need to lift a finger. Type 1 command and boom, you're secure.

Doesn't get easier than that.

Reply on news.ycombinator.com