Sub Ca with wildcard certificate

Feature Requests
1

Hi everyone,

I know this has come up before, but now that Let’s Encrypt issues leaf-level wildcards I still can’t see the blocker to also offering name-constrained subordinate CAs for the same namespace. Technically it’s the same validation you already perform for a *.example.com wildcard—the sole difference is the Basic Constraints and Name Constraints extensions you set when signing.

Right now I have to copy one wildcard key to every host and rotate it every 90 days. A Let’s Encrypt–signed sub-CA limited to example.com (pathLen = 0, DNSName = *.example.com) would let me run my own tiny ACME server internally and let every host grab short-lived leaf certs on demand. I’d still renew the sub-CA every 90 days, but the per-host keys would stay on the hosts that generated them.

That brings obvious wins:

  • No key-sharing: each machine holds only its own private key.
  • Smaller incident blast radius: compromise of one endpoint no longer exposes a domain-wide wildcard.
  • Cleaner automation: certbot (or any client) keeps working exactly as today, just pointed at an internal CA.

“But subordinate CAs are scary—what if they issue for other names?”

The fix is the Name Constraints you already support for third-party intermediates. A sub-CA limited to example.com literally cannot sign google.com, even if its key is stolen, because modern clients reject a path that violates DNSName constraints. For older clients that ignore Name Constraints you can also set pathLen = 0 so the sub-CA cannot create another sub-CA and escape the constraint.

“We’d lose Certificate Transparency for the leaf certs.”

All current CT policies only mandate logging the intermediate; leaf logging is nice but not required. You already accept that risk for any leaf wildcard. The security model is identical: if the sub-CA key leaks, you revoke the sub-CA and every descendant leaf becomes untrusted in the same single OCSP response—exactly what happens today when a wildcard key leaks. Additionally it would make the use of self issued leaf certificates for internal only websites possible because they would not be exposed (known) over the CT Log to outside the company and trigger a security issue with that.

“People can already solve this with multiple leaf certs.”

True, but only by copying one private key (or an ACME account key) to every host, which many security teams explicitly forbid. A name-constrained sub-CA means zero private-key distribution and a far cleaner separation of duties.

Concrete ask: expose a new ACME certificate profile "subca-wildcard" that:

  1. Requires the same DNS-01 validation you already run for leaf wildcards.
  2. Issues a subordinate CA certificate with pathLen = 0 and NameConstraints: DNS = *.example.com, example.com.
  3. Retains the same lifetime, so the global revocation window is no larger than today.

From the perspective of a relying party, the risk delta versus a leaf wildcard is essentially zero, while for operators the security and operational gains are substantial. I hope we can reconsider this small but powerful extension to Let’s Encrypt’s service.

I hope we can have a productive conversation about what is currently against it and what would need to be done to implement something like this so that it can be done.

Kind Regards Xyz00777

1 Like
2

This is essentially a non-starter in today's PKI where leaf certificates are significantly constrained by policy and not technical restrictions.

You're welcome to ask, but I'm just going to be realistic and say that this isn't possible, and nobody is working on making it possible.

9 Likes
3

Yeah, having "Sub-CAs" adds a lot of auditing requirements, and while there might be a way to get it to work with CAs eventually (regardless of whether Let's Encrypt specifically ever were to implement something like this) it's probably the hardest way to do this sort of thing.

Why can't you do that sort of thing without wildcards at all? If you don't want each system fully getting their own certificates (which I don't see why you would need to be copying keys around to get that, just have each system use their own ACME account and own certs), but want to centralize your systems through a single ACME server, why couldn't that server just "proxy" through requests for the names (with whatever approval process you want), and either handle the DNS authentication (being the single place with DNS API update credentials) itself or pass along the challenge data for HTTP to the originating system? I can see some enterprise use cases where you'd want your own ACME server, I just don't see why adding Sub-CAs and making the centralized system issuing "real" leafs (rather than just passing along certs from a real CA) would make things easier, given the requirements in place for hosting an intermediate (even if it were to be constrained).

4 Likes
4

There's no reason for that. Each host can perfectly have its own keypair and ACME account, and request certificates with that, even if all certificates carry the same hostname(s), wildcard or not.

The only constraint is that each host must be able to fullfil ACME host verification, but for wildcards you already support DNS verification anyway, which is easier to generalize to multiple internal hosts.

6 Likes
5

Thanks for you quick answers.
@mcpherrinm i dont quite understand what you mean with your first sentence could you please be a bit more detailed? To the second point, i would really like to understand what is not possible in it, like what audit points would come with it (i have tried to look these up, but have not been very successful in finding them and what effects they really have in practice (if i found any)).

To the other points:

Wildcards may look convenient on paper, but in real-world corporate environments—they’re more headache than help. Beyond the usual compliance hurdles, handing out a single certificate that spans every subdomain violates the principle of least privilege and opens new attack vectors. Here’s why wildcard certificates (and alternative “shortcuts”) remain impractical for most organizations:

Firewall & HTTP-01 Validation
To prove ownership via HTTP-01 you’d have to open port 80 on every single application server. No security team in their right mind will green-light exposing dozens (or hundreds) of hosts directly to the Internet.

DNS-01 & API Credentials
Even though DNS-01 avoids opening port 80, you still need to distribute or centrally manage DNS-provider API keys. Giving a dozen servers direct access to that key fails every audit; consolidating it on a proxy simply concentrates a juicy secret in one place. (Side Note: Yes im aware of a media.ccc.de talk where someone showed how to do something like that with an internal dns server who than syncs with the external but still a big workaround)

Outbound Internet Restrictions
Many networks block servers -who are not internet facing- from talking to the public Internet indirectly or at all. Running an ACME or DNS-01 proxy still requires unrestricted DNS resolution and HTTPS access—something most production zones forbid without special exceptions.

Certificate Transparency (CT) Exposure
If you issue individual leaf certificates instead, they all get logged in CT, publicly revealing internal-only hostnames. Security teams won’t tolerate “the-all-mythi-db01.example.com” or "soc-ticket-system.example.com” appearing in a global log searchable by attackers.

Operational Reality & Governance
Whether you opt for leaf or wildcard certs, you must still prove domain control—and that runs headlong into the same firewall, DNS, and CT policies. There’s no magical bypass.

Self-Signed Certificate Nightmares
In many legacy environments we still rely on self-signed certs—and they’re a constant source of outages. Countless home-grown apps or third-party open-source tools simply refuse to hit an “Accept self-signed certificate” checkbox (or silently ignore validation errors -who normaly should show a mitm attack or that something is wrong), leaving users to wrestle with broken integrations and help-desk tickets, or the "yeah just press okay thats normal" error messages from a wrong configured browser and self signed certificate.

Least-Privilege Violation
Granting a department access to a wildcard cert means any team could spin up arbitrary web services (test, staging, or worse yet, shadow-IT) all bearing a valid certificate. That flies in the face of best practices for access control, auditability, and compartmentalization.

Bottom line: opening port 80, scattering DNS API keys, or publishing internal domains to CT logs is universally forbidden by corporate security policy. That’s why—despite their theoretical appeal—wildcard certificates (and other “shortcuts/workaround”) simply aren’t feasible in most enterprise environments.

6

I frankly doubt this is true, your confident and emphatic assertion to the contrary notwithstanding. But supposing you're right, surely such an organization can manage its own PKI? "Certificate from a public CA" simply isn't necessary (or even desirable, I'd think) in this case.

3 Likes
7

I believe that is answered by his phrase here:

(emphasis is mine).

3 Likes
8

The technical term for the kind of sub-CA you're asking for is Technically Constrained TLS Subordinate CA Certificate.

It is true that the Baseline Requirements allow institutions like Let's Encrypt to issue such certificates, and it's even true that the audit requirements for such sub-CAs are less than the audit requirements for "normal" intermediates (like our E5 and R10).

However, those audit requirements do still exist. The BRs, in Section 8.1, say that

Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained... as well as audited in line with Section 8.7 only, or...

So let's take a look at those requirements from Section 8.7:

During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA's Certificate Policy and the Subordinate CA's Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable CP are met.

So if we give you a sub-CA, then every quarter we need to audit at least 3% of all certificates you've issued, and ensure that you're complying with our CP/CPS. What does that mean in practice?

(nota bene: everything from here on out is hypothetical)

For starters, you almost certainly can't comply with our CP/CPS as written: it is a very specific document that would take a significant amount of work for you to comply with. Cherry-picking one example, you'd have to ensure that your key material is generated by and stored on a FIPS-qualified HSM.

We'd also have to employ additional personnel to perform those quarterly audits of your certificates and of your compliance with our CP/CPS. And since we'd be putting our own reputation as a CA on the line, we'd need a strong contract laying out what happens if you deceive or evade the audit process. Both auditors and lawyers cost money, so we'd probably need you to pay us for the privilege of having a sub-CA.

And then we need to do all of that for every subscriber who requests this profile.

At that point, we've drastically departed from the mission of Let's Encrypt: to make TLS free and ubiquitous by automating it. We can't automate audits, we can't automate contracts, and we certainly can't do those things for free. So this is a service that would be impossible for ISRG to provide.

11 Likes
9

What OCSP response?

2 Likes
10

(I believe this is a wisecrack related to the fact that we are turning down our OCSP infrastructure. But such sub-CA certificates could be revoked via CRLs just as easily, so I don't think this particular point is worth poking holes in. The difficulties with sub-CAs don't center on revocation.)

6 Likes