Sign Internal Enterprise CA with 3rd Party CA

Feature Requests
1

I have built a Subordinate CA using Active Directory Certificate Services. It will be an internal Enterprise CA that will only sign certificates for users and computers within my Active Directory Domain.

Can I use a 3rd party CA like Let's Encrypt to sign my Enterprise CA signing certificate?

2

No.

3

To expand on the general "No", which is really the answer:

In order to be signed and trusted, you would need to have your systems go through the same audits and procedures as the other publicly trusted CAs. You'd basically need to have all the same controls and effort, even if you were only planning on using it for your internal systems, since the signed certificates would end up being valid worldwide for any names.

The way to do the things you're trying to do is to either:

  1. Have your root trusted automatically by the systems within your network, through Active Directory installing it in your systems' trust stores or the like. Or,
  2. Have your internal systems request publicly-trusted certificates through a public CA like Let's Encrypt, even if they're not accessible to the outside in other ways beyond what's needed to validate control over the name that the system uses. (Often a DNS-based approach is easiest for that sort of thing, but you can do approaches like where a firewall allows for the HTTP challenge to be solved but doesn't allow for any other traffic.)
4

I'm having a little difficulty understanding your explanation. It's me not you.

Allow me to explain what I need.

We want to use an Enterprise CA to issue certificates internally to computers and users for internal use only.

We want to avoid having to manage the private keys of a root CA even if we use a stand alone Root CA.

Since 3rd Party CAs are in the business of protecting private keys, we thought we could use a 3rd party CA to sign our internal Enterprise CA signing certificate instead of depending on an internal stand alone Root CA.

Is this possible?

5

Sure, that's a normal thing for enterprises to do.

I'm not quite understanding what it is that you're saying you want to do versus not want to do. Part of having an enterprise CA is managing the keys for it. If you want to outsource the running of a private CA to some entity that's specialized in running enterprise CAs, there are plenty of vendors that offer that kind of service. I think all the major "cloud" providers and commercial CAs offer products that can help your organization's private PKI. It's just not something that Let's Encrypt offers, since its focus is purely on public sites using the public Web PKI.

You can certainly set up private PKIs that involve some 3rd party private CA that signs your internal CA. But that's all very separate from the public web PKI, which has very strong audit and compliance requirements that are much more expensive than anyone's going to accept unless you're actually going to be serving as a public CA yourself.

6

So what I think I'm understanding is that 3rd Party CAs like Let's Encrypt and Digicert etc only sign public web cert.

The hierarchy we're trying to accomplish is this

Root CA - Let's Encrypt
SubCA - Internal Enterprise AD CS
Identity Certs - Internal endpoints

Is this possible?

7

With their public root and intermediate certificates, yes.

Let's Encrypt only offers public certificates.

Digicert offers Private PKI services (and so do other commercial CAs). But that's a different product offering not related to their publicly-trusted certificates.

No, because Let's Encrypt won't sign your SubCA since it would need to be subject to all the same rules that Let's Encrypt itself is.

8

I understand WHY you want this; you get all of the advantages of a publicly trusted root CA (you don't need to distribute that root CA certificate to all of your internal hosts) and all of the advantages of an internal CA (you can easily get certificates for any host you want). The problem is that you could issue a certificate for literally any host on the Internet and it would be trusted by everyone on the Internet. I cannot imagine a universe where any public CA would agree to that.

9

Ken,

Thank you for that clarity. I didn’t think that through.

10

It's probably disallowed by BRs, but technically, wouldn't it be possible to use a name constraint on the sub CA?

11

I think you can use a name constraint, but it still needs to be fully audited just as though it didn't have one.

12

Certificates with name constraints are recognised by the TLS baseline requirements (https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.3.1.pdf) as Technically Constrained CA Certificates and have reduced requirements compared to an unconstrained CA certificate.

In particular technically constrained certificates only require a self audit by the issuing CA and CAA checking is optional for certificates issued from a technically constrained CA certificate.

13

CAs offering that service usually don't give you the private key, but they issue on demand for the authorised domains.

If you want to do stuff like TLS inspection you cannot use a publicly trusted certificate.