I work for a small business that’s getting big enough to justify an internal PKI. I already have one built using Microsoft Active Directory Certificate Services (for it’s integration into the rest of the AD infrastructure). This system is seamless if a given device is joined to Active Directory, but non-domain-joined devices don’t receive the root certificate generated by the internal CA.
I’d like to solve this by switching our intermediate CA to a publicly recognized root, but this means getting an intermediate certificate capable of issuing it’s own certs. Several of the major certificate providers offer variations on this under various brands… and they’re perfectly happy to take payments in organs and limbs.
I’m wondering if it’s possible to do this through Let’s Encrypt. The domain is a public domain, so there’s no conflict there.
Unfortunately it isn't. We aren't able to provide this service. We strictly issue end-entity leaf certificates and can't provide intermediates/sub CAs.
Bear in mind that as a Registration Authority (sub-CA allowed to issue for specific domains), I believe you also become subject to auditing requirements. It’s a costly venture, and usually only used by large organizations.
I wonder if there's an easier path with a name-constrained intermediate; I don't know how that affects the auditing requirements. I thought that there was once an option involving name constraints that was much less rigorous in some regard, but I don't know if that still exists.
Anyway, maybe you could ask a commercial CA and/or PKI consultant about this option. Ideally it would lead to less stringent audit requirements than an unconstrained public CA. (Individual X.509 extensions can be marked as Critical which means that a client that doesn't understand the semantics of the extension should reject the certificate, whereas for a Not Critical extension a client that doesn't understand the extension may still accept the certificate. So the name constraint is normally always set as a Critical extension so that software that doesn't understand the restriction simply can't use those certificates at all... but I think all recent browsers do understand it.)
... actually, we have a forum thread from 2016 about this topic
which says that at least at that time, Comodo offered this service commercially.
We’re currently trading emails with commercial CAs regarding this. I had hoped that Let’s Encrypt would have an option for it so we could avoid a commercial CA.
I’m trying to clear cert errors off of internal websites, mostly for various appliances. On the one hand, it’s such a small task, on the other hand, it’s a headache and a half. Our internal CA solves 95% of the problem. As long as the client machine is domain-joined, they get the root certificate from the internal CA and everything is fine. However, there are edge-cases. Some devices won’t accept the cert because they don’t trust the root. Some clients aren’t domain joined, and tracking manual certificate installs is a logistics issue.
Thus I’m trading emails with sales reps about licencing fees and wishing there was a better way around the whole problem.
IdenTrust hasn’t granted Let’s Encrypt the authority to do this. If you look at the Let’s Encrypt Authority X3 intermediate certificate, its basicConstraints section says
Critical
Is a Certificate Authority
Maximum number of intermediate CAs: 0
That means that Let’s Encrypt is not allowed to nominate new CAs via the IdenTrust chain of trust at all.
ISRG could conceivably do this with the new ISRG root instead, but
at a cost in device compatibility
at a cost in audit complexity
probably at a cost in staff time and effort due to the greater amount of damage that a misissued intermediate certificate can do, and the greater risk if one isn’t revoked when an underlying domain expires
It’s not necessarily a bad idea but Let’s Encrypt’s current economic model works because the marginal cost of issuing a new DV certificate with the current infrastructure is very, very, very low, while the marginal cost of issuing a new path-constrained intermediate from the ISRG root would be much higher than “very low”. To start with, it couldn’t be done automatically at all on the current infrastructure because the ISRG root isn’t online and it requires a manual activity involving human effort to generate new intermediates.
So while I’m sorry that you may end up having to pay for this, I think it’s also true that Let’s Encrypt isn’t set up to be able to do this without charging for the service (or, for that matter, even with changing for the service). The infrastructural changes required to do that would be fairly large and so it probably won’t happen quickly, but it’s an interesting topic to keep in mind for the long term.