Why doesn't Let's Encrypt issue CA certificates?

Feature Requests
1

Let's Encrypt will issue only certificates that do not allow additional signing of sub-certificates and adding links to the certificate chain.

I'd like to sign my own certificates instead of asking Let's Encrypt for every subdomain I want to sign. I think that it would leave less stress on Let's Encrypt servers if users could sign certificates for subdomains themselves.

How I imagine this is like so: I request a CA certificate via certbot, Let's Encrypt verifies ownership of my domain via DNS with DNSSEC and signs a certificate signing request with RFC 2459 Section 4.2.1.11 permittedSubtrees x.509 Name Constraint attribute and CA=TRUE, meaning I can issue certificates at my will for my subdomains.

This would ease mass issues of certificates, for example if a router company would like to use SSL on their configuration pages, they would be able to sign <ROUTER_SN>.residential.theroutercompany.com for every sold router without complications and update those certificates over the air. This is of course just an example, I'd use this just to sign different certs for different servers.

Related SE question: https://serverfault.com/a/274876/557914

1 Like
2

Hi @sij

simple question: Are you a CA? Are you able to do all these things a CA must do?

If not, that's the reason Letsencrypt doesn't create such certificates.

2 Likes
3

Let's Encrypt would be directly responsible any certificates you mis-issue from your intermediate, which puts their status as a trusted root at risk. There are a lot of rules that CAs have to follow and name constraints don't really mitigate them.

6 Likes
4

Hi, @_az and @JuergenAuer!

What mis-issue can there even happen? I could only issue certificates for subdomains of domains which I own, not decreasing security of other domains in the world.

I would not be a CA that could issue certificates for any domain, only for domains that are subdomains of the domain that I own.

I may obviously be mistaken. If this is the case, can you please explain some security concerns and breaches that can happen if for example a CA certificate gets misused or to what extent can damage be done should a malicious party get a CA for their subdomains?

5

Sorry (in advance) for answering a question with a question, but I hope you get the message:
Q: "Why doesn't Let's Encrypt issue CA certificates?"
A: Do you know of any CA that is doing this now? I sure don't - if you do find one, come back and let us know, there would be plenty of people that would sign up for such a service.

So no one seems to do this anymore because the implied required restrictions that you speak of aren't yet in place to prevent someone to misuse their subCA and issue trusted certs for any domain name - or even a SAN cert with wildcard entries of major TLDs.
Now picture that: A trusted cert that covers: *.com, *.net, *.org, ... or maybe even just *.

1 Like
6

You are correct, I can't name a single CA that would do this en masse for regular people. But it would be a nice step to decentralizing and "hierarcifying" the single-point-of-failure CA system that we have today, where many CAs have the immense power of having a *. certificate.
I am aware that this will not be a feature for many years to come. Maybe it would be better to ask the ACME forum, but thanks for all the answers anyway.

Do you mean that browsers don't check attributes such as permittedSubtrees?

7

If you want this to happen, which it seems you do, Let's Encrypt is probably the wrong place to be arguing for it at this point, you'd need to talk to the trust stores, as they'd have to substantially weaken their oversight over the Web PKI in order to make something like this practical.

The major trust stores (where you'd want to start) are Microsoft, Apple, Google and Mozilla. If you can get those four on board you might well get somewhere with this. They're responsible for the trust of public CAs like Let's Encrypt by most popular web browsers and, (indirectly in Mozilla's case) operating systems.

To give you an idea of why the root trust stores don't want somebody they have no relationship with issuing whatever they want under an intermediate as you're envisioning, consider what happens when inevitably, but perhaps purely by mistake, you issue a certificate which contains a technical error.

Perhaps it has a stray NUL character in a text field, or it contains a nonsensical policy OID. Unfortunately, and unknown to you, this error causes a popular program to misbehave, maybe it's a web browser, or a mail client.

Today, under current rules, the trust stores can demand that the ultimate issuing CA revoke the offending certificate and ensure the problem is prevented from happening again. If it's unresponsive or its attempt to prevent future problems is unsatisfying, they can just revoke trust in that entire CA. If there is a cross signature they can insist the cross signature is revoked in order to give effect to the loss of trust. This really happens, albeit usually not for minor technical errors since it would make sense to just ensure the error stops happening.

But under your proposal this mis-issuance would have taken place at some unknown location, perhaps on some Raspberry Pi in a closet, the person who issued the broken certificate can't be contacted, or may not think fixing this is important right now. So Let's Encrypt (in your example) are ordered to distrust this intermediate. That fixes the problem, once, but it's not permanent. "Huh, why is my issuing CA broken? I guess I will make another one" and the cycle continues.

So, you will need to show the trust stores how your proposed new regime could achieve their goals. It is possible you can do that, but that's probably where you need to start, not at Let's Encrypt. And frankly, you may struggle to even get Apple and Microsoft to notice you exist.

5 Likes
8

This would clearly be a bug in a "popular program". There should be no trust in the popular program with handling data of the certificate chain. Self-signed certificates AND self-signed CA certificates are common practice in large educational networks that need to have their own CA, but can't get it, and solely clicking the "I accept the risk" button in the popular program never involves accepting the risk that a nonsensical policy OID can misbehave a certain popular program.

In other words, we can already issue CA certificates, they will not be accepted by default. Temporarily accepting a third party certificate shouldn't lead to misbehaved actions of popular programs, such as curl's -k flag and chromium's "I accept the risk" button.

9

That's not really the point @sij. The point is, if Let's Encrypt offers name constrained sub-CA's to literally anyone, there is a very good chance this will result in mis-issuance. It really doesn't matter if there will be a buggy client or not, it's just not allowed to issue incorrect certificates! And as Let's Encrypt can't control those sub-CA's, they won't do it, as it would reflect back on Let's Encrypt itself. Understandable.

Also note that Let's Encrypt is all about automated issuance. If you would be allowed to get such a name constrained sub-CA certificate, so would anyone else in the whole world! Because Let's Encrypt doesn't work on an individual basis. Just like Let's Encrypt only offers DV certificates and not EV certificates. And that's probably a liiiiiiitle bit too much responsibility for 7 billion people.

2 Likes
10

There isn't really much information of support for permittedSubtrees (and nameConstraints in general); there would have to be solid proof that enough of the web (browsers and the many other users of TLS) supports them before LE would seriously consider that. It isn't a terrible idea, but I don't know of any CA that actually does offer this, and being first is always a bit fraught.

3 Likes
11

Thank you all for your responses

I don't really know why is it "forbidden" to misissue certificates on such a restricted level as a domain name. It's like saying that my domain name server MUST NOT send a JPEG image when asked for an AAAA record of a domain name. A cert of such restricted level can't do much damage, right?

But I guess that the whole design of the SSL certificate chains is broken and flawed in a way that it can't be fixed by using hierarchy like that is implemented in DNSSEC. I personally think that a DNSSEC hierarchy system would be better (""'s CA signs "com"'s CA (valid for com.), "com"'s CA signs "google.com"'s CA (valid for google.com.)), instead of having a clusterf**k of single points of failure, hundreds of CAs for the root domain "". Or just store public keys as domain keys.

It's too late to redesign the SSL system in such a way. Thanks again for patience and answers :slight_smile:

2 Likes
12

There are some earlier threads on this topic in response to other people with the same suggestion:

https://community.letsencrypt.org/search?q=sub-ca

Generally the answers were along the same lines as the answers in this thread. The root programs don't accept even a name-constrained sub-CA as being on the same level as an end-entity certificate for the same name. Instead, they expect contractual and policy oversight of various kinds, which an automated CA like Let's Encrypt wouldn't be able to provide for free or at scale.

If you could convince the root programs that this was safe and useful, it might be possible in the future! (@jsha even says that in one of the older threads.) But the root programs would have to be convinced of that first.

Another challenge is how long the sub-CA certificates would be valid for. If you wanted them to be valid for a longer time than 90 days, Let's Encrypt would probably also have qualms about that. But if they're only valid for 90 days, they might not be as useful as you would expect.

There is a mechanism for this called TLSA. I and other people have felt that this might be a good alternative to trusted CAs, but Chrome—at least—expressed a lack of enthusiasm for implementing it as a substitute. Nonetheless there is a different kind of keys-in-DNS mechanism as part of encrypted SNI (I forgot what encrypted SNI has been renamed to!) that might also be a good substitute, although the existing standards and implementations call for checking both rather than letting the DNS check substitute for the certificate check.

I don't remember the Chrome developers' reasons for being less enthusiastic about TLSA, but two likely possibilities that come to mind are that Certificate Transparency is very important to them (and we don't have a DNS equivalent that would allow an after-the-fact investigation of an attack involving false TLSA records), and that CAs are doing DV from data centers that may be more difficult to spoof or tamper with compared to many smaller networks—especially, say, a public wifi network!—so in the absence of universal and strongly enforced DNSSEC signing, many more MITM attacks against TLS services could succeed if spoofing DNS for an individual resolver was sufficient to get it to accept an arbitrary key.

4 Likes
13

Part of it is that nobody but Verisign wants Verisign to be the sole arbiter/CA for .com and .net. They already own the DNS so it makes absolute sense for them to be the DNSSEC root, but this discussion goes way back into the mists of time with the original SSL proposals, and it was rejected that the TLD owners would be the cert chain owners. It's been proposed and shot down many times since. That's not "too late to redesign SSL", that's "nobody wants to live in that world."

Similar proposals have been floated for everyone from ICANN to national bodies to one or a handful of trusted NGOs to be "the" root, but have likewise not made it past too many objections.

On the other hand, if a CA simply wants to restrict its own certs for extra peace of mind, because it's, say, a national register that only issues for .in or whatever, they're free to do so. My research is that browsers actually have been supporting this for roots pretty robustly for a while now (but I've seen zero about intermediates), while it's a little more on & off for non-browser clients.

2 Likes
14

Work to encrypt SNI continues as Encrypted Client Hello. It was felt that even if we aren't sure today what else might be plaintext in ClientHello that we care about, it can't hurt to just encrypt everything.

Currently draft-ietf-tls-esni-09

5 Likes
15

Oh thanks, that's exactly what I was thinking of!

2 Likes
16

There’s also been some experimentation of an alternative approach, Delegated Credentials, which could be thought of as letting one CA-issued cert provide trust to sub-certs under certain conditions.

Not sure on current state in browsers, but we were experimenting with draft 4 in Firefox a year ago: Validating Delegated Credentials for TLS in Firefox - Mozilla Security Blog

7 Likes
17

There are proper mechanisms in place to fully support Organizational private CAs. You can create an Active Directory integrated CA with Windows Server Certificate Services, and push the root CA cert to the Windows trust store. FireFox and Chrome both have Enterprise capabilities to push the CA cert to their trust stores, and any version can have the cert added manually. MacOS can use MDM to add it to the root keychain trust as well. For Linux, you can also add the root CA cert to the trust store, and assuming you have established a secured internal repository, updating would be simple (for instance, on EL systems, install your internal repo and signing key on the box and enforce signing on the repo, configure a daily cron job to update the CA package, then build a RPM to install the root CA in the trust store. GPG sign the RPM and repo metadata.)

Self signed certs have become less useful as browsers won’t trust them and most Linux distros no longer allow you to put certs without the “CA” attribute in the trust store anymore. I work on a product that integrates with LDAP, in addition to accessing HTTPS servers. It used to be we could add the LDAP server cert to the OS trust list, but since EL7, we have had to tell our customers to deploy AD Certificate Services to issue LDAP certs, then upload the root CA to our trust store. Don’t get me wrong, this is absolutely the correct way to do it, just a lot of smaller companies never bothered setting up AD CS until they were forced to in the past few years.

3 Likes
18

There are proper mechanisms in place to fully support Organizational private CAs.

Yes, I know about that, but the main issue still persists - no CA that is by default trusted in popular browsers will ever sign your private CA.

V V sob., 6. feb. 2021 ob 18:19 je oseba Ruaphoc via Let's Encrypt Community Support <letsencrypt@discoursemail.com> napisala:

2 Likes
19

Please read this article.

2 Likes
20

Please read this article.

Thanks for the link, I get the problem now. The CA would be able to spoof the organization name field. Is there a way for an upchained intermediate certificate to prevent changing organization name of downchained certificates? Can a CA certificate be created in such a way that it would not be trusted to sign certificates with an organization name other than it's own? If that's not possible, than yes, this is clearly a very crucial thing that prevents achieving what we're discussing about in this topic.

V V sob., 6. feb. 2021 ob 22:29 je oseba Levi via Let's Encrypt Community Support <letsencrypt@discoursemail.com> napisala:

1 Like