Wouldn't it be nice if LetsEncrypt could issue you a (1) name constrained, (2) 90-day limited intermediate CA with just the (3) DNS-01 challenge? I argue that such an intermediate CA would have no more authority than a wildcard cert which you can get today, so they should be able to issue it. [1] Everything supports name constraints now, which used to be an issue but isn't anymore. [2]
Then stick it in step-ca and issue all your certificates with internal ACME.
This would solve a lot of problems, such as leaking private hostnames in the certificate transparency log, or hitting issuance rate limits on LE servers.
> Wouldn't it be nice if LetsEncrypt could issue you a (1) name constrained, [...] intermediate CA
Unfortunately, name constraints don't work in all clients. Name constraints are an 'extension' to the standard and supporting them is optional.
According to [1]
> Before relying on this solution to protect our users, we wanted to make sure browsers were really implementing Name Constraints verification and doing so correctly. The initial results were promising: each of the browsers we tested (Chrome, Firefox, Edge, and Safari) all gave verification exceptions when browsing to a site where a CA signed a certificate in violation of the constraints.
> However, as we extended our test suite beyond basic tests we rapidly began to lose confidence. [...] The result was that every browser (except for Firefox, which showed a 100% pass rate) and every HTTPS client (such as Java, Node.JS, and Python) allowed some sort of Name Constraint bypass.
And even if someone went around and fixed every TLS library in the world, there'd still be millions of devices out there that never get security updates, like smart fridges and ancient android tablets.
There's a major chicken-and-egg problem: Because nobody will issue name-constrained certificates, clients don't have much reason to prioritise it as a feature. And because name constraints don't work perfectly everywhere, nobody will issue name-constrained certificates.
I doubt we'll ever see a trusted CA issuing name constrained intermediate CA certificates.
Of course, they could offer an API where if you've passed auth for *.example.com you can issue a cert for any subdomain below that without any further validation...
That post is almost 7 years old. My second link is to the test suite mentioned at the end, which if you look at it you'll see that name constraints are now universally supported. I don't think this take is valid anymore.
And for old devices, letsencrypt should force nameConstraints to be a critical extension so that old devices will just fail to accept it so that it won't be used “rogue”ly.
I don’t necessarily disagree, but to point out: issuing an intermediate CA does change the authority model a bit, insofar as it turns a single trusted issuance into a windowed lease to perform arbitrary issuances.
On a practical level, the latter is more logistically complex (and needs to be reconciled with other hard-fought battles, like CT). Given that it’s roughly the same as a wildcard certificate in terms of end-user use, it’s IMO understandable that this isn’t a priority for the CA ecosystem to support.
(The use case of circumventing CT is probably a non-starter as well. The Web PKI doesn’t want CT loopholes!)
Nobody has ever adequately explained how a wildcard cert presents a meaningfully different security profile than a name constrained CA. Wildcard certs used to identify a subdomain are not logged in CT and nobody is freaking out about it. And if your answer is "because nested subdomains" you should also explain the differential risk of nested subdomains compared to wildcard certs, not fully qualified certs. I don't see how it's meaningfully different.
One accepts an arbitrary subdomain as a matter of verification policy, and the other has broader PKI implications: how should verifiers handle name constraints with multiple prospective paths? How should they handle CAs that issue longer-lives certificates than the CA/B guidelines permit? CAs that allow end-entity certs with known insecure algorithm choices, etc?
In short, allowing user-controlled name-constrained intermediate CAs opens up multiple cans of worms that the ecosystem is not currently prepared to handle. Presenting a compelling argument for these user-controlled CAs means explaining (and getting buy-in) for solutions to the above.
Thanks, I appreciate a response with some substance.
> name constraints with multiple prospective paths
Can you expand on this for me? Is this really a problem?
> longer-live[d] certificates than the CA/B guidelines permit
The iCA cert would only be valid for 90 days (or less, they could make it 30 or 15 days). Would a cert be valid if the iCA cert that issued it is expired?
> known insecure algorithm choices
Disallow bad algorithms by policy. Evidence of issuance using a bad algorithm gets the iCA revoked and the ACME account locked out. Many clients don't allow insecure algorithms by their own policy.
If you're securing your internal network with bad algos but it never touches the wider internet, does it make a sound? Would this be better or worse than installing self-signed root CAs everywhere?
> Can you expand on this for me? Is this really a problem?
Sure, happy to: the issue here is that the user’s root might present multiple prospective validation paths, none of which have to agree on the total constructed set of permitted/denied name constraint subtrees. Path validation also doesn’t impose an order, meaning that two clients can (correctly!) disagree on the set of names that a validation path can issue.
Is it really a problem? Maybe: the various Web/Internet PKI standards aren’t clear about how to handle situations like this, and things that change the Web PKI to rely more heavily on correct extension handling have historically revealed lots of fragile/noncomplying clients.
> Would a cert be valid if the iCA cert that issued it is expired?
Nope, I made a mistake here: this wouldn’t be an issue, for the reason you’ve said.
(Having an ICA that expires every 90 days would impose other logistical challenges, however: you’d either need to include it in the server response along with the leaf, or lean heavily on an extension like AIA to retrieve the current ICA certificate.)
> If you're securing your internal network with bad algos but it never touches the wider internet, does it make a sound? Would this be better or worse than installing self-signed root CAs everywhere?
Probably no worse for the private network scenario, although I think the proposed solution here ends up confounding the public and private cases: the certs issued under a NC’d ICA would also be valid on the public Internet, and may end up intentionally or unintentionally depending on this behavior.
If I had to TL;DR my opinion here, I think it would be: “all of these things are solvable or addressable at the policy level, but the Web PKI has historically been brittle to assumptions that currently standardized things are correctly respected by the client ecosystem” :-)
It would be impossible to enforce that issued certs are submitted to certificate transparency logs and this would break the security model around the ca system.
I don't understand the difference between wildcard certificate and intermediate certificate.
Intermediate certificate is more secure because you can use different certificates for different subdomains, insead of sharing private key for wildcard certificate with every subdomain server.
Whether it hits CT or not - is not relevant at all. What matters is if intermediate certificate hits CT.
A wildcard covers one single level of sub-domains. An NC'd CA can be used to issue for anything. Nameconstraints are 'enforced' on the client side and many don't support it.
Running a public CA - even with a nameconstrained CA, is a challenge to do properly.
I thought that the main problem that certificate transparency addresses is the fact that multiple certificate authorities can all issue certificates for all domains (i.e. there is an overlap in the name space).
So when a CA gets compromised in some part of the the world (or gets manipulated by a state actor that effectively runs the CA) somebody could just emit a valid certificate for a domain you control.
In case of private intermediate name restricted CAs, that can be addressed by logging the issuance of the intermedia CAs.
> I thought that the main problem that certificate transparency addresses is the fact that multiple certificate authorities can all issue certificates for all domains (i.e. there is an overlap in the name space).
Yep, that's a "main" thing that CT is intended to address. But it has other useful applications as well: because anybody (including website operators) can monitor the transparency log, they can additionally assert that their own trusted CA is not issuing more than one certificate for the domains they control.
Logging only the name-constrained intermediate CA would make third-party monitoring less useful. It would also have a perverse effect on attacker incentives: the attacker now only needs to compromise a user-controlled CA with a likely to be weaker security posture.
(That being said, maybe these tradeoffs are worth it! I don't have a strong opinion about that, other than my impression that the status quo with Let's Encrypt + intentionally leaking a few private subdomains isn't really that bad.)
Then stick it in step-ca and issue all your certificates with internal ACME.
This would solve a lot of problems, such as leaking private hostnames in the certificate transparency log, or hitting issuance rate limits on LE servers.
[1]: https://news.ycombinator.com/item?id=29811552
[2]: https://bettertls.com/