Are my internal systems susceptible to MitM if the root/chain is shared amongst all customers?

Question

Suppose that my certificate authority issues private certificates using the same chain for all of their customers. Does this mean that a malicious actor who happens to be another one of their customers can easily perform an MiTM without a certificate error by issuing their own cert with the same FQDN?

The CA in question allows private certificate issuance for any unrecognized TLD (as in, any TLD that is not on this list) without any domain validation required. Makes sense since the domains aren't publicly routable, so they can't do DNS TXT records or the HTTP well-known method.

Consider this scenario:

1. Alice requests a private certificate for super-secure-nginx-server.internal
2. CA issues the private certificate with the following chain:
   • ae8569d94f4ab1c464ad9b7cfd7840b0e39daf66 (root)
     • 477df10752e5acdb45936824e4be360251ddb0fc (intermediate)
       • abcdefg1234560 (leaf - CN: super-secure-nginx-server.internal)
3. Alice installs the leaf and intermediate certificate on her server
4. Alice pushes the root certificate to the certificate store on all computers and smartphones in the organization for users to access the internal sites without certificate error
5. Mallory, a customer of the same CA with malicious intent, requests a private certificate for super-secure-nginx-server.internal.
6. CA issues a private certificate with the following chain:
   • ae8569d94f4ab1c464ad9b7cfd7840b0e39daf66 (root)
     • 477df10752e5acdb45936824e4be360251ddb0fc (intermediate)
       • 7654321abcdefg (leaf - CN: super-secure-nginx-server.internal)
7. Mallory installs the leaf and intermediate certificate on an intercepting proxy server
8. Mallory performs monster-in-the-middle attack on Alice (or any person in her organization) using whatever means (DNS cache poisoning, etc.)
9. Alice accesses super-secure-nginx-server.internal and assumes the connection is secure since there is no certificate error. She is unaware that the connection is actually to Mallory's server. There is no certificate error since the FQDN is correct and the root is already trusted by the browser/OS.

In this scenario, the only way that Alice would know that something is off would be inspecting the certificate and having some out-of-band knowledge that the legitimate server's certificate is abcdefg1234560 rather than 7654321abcdefg.

Is my understanding of this issue correct? Surely the CAs have thought about this?

In this case, isn't it better to use a completely internal CA like Active Directory Certificate Services or step-ca rather than having a paid CA issue these certs?

It doesn't make sense for the CA to prevent Mallory from requesting such a certificate either, as her organization might also legitimately have a server with the FQDN super-secure-nginx-server.internal.

Update: Checked with the CA and they kindly referred me to a line that I missed in the documentation saying that it only works for domains of unrecognized TLDs that are not in use by another customer issuing certificates. Looks like the internal domain suffixes that my organization has been using aren't also in use by another customer, so that's why we never ran into any issues.

Answer 1

Is my understanding of this issue correct?

Based on your description the CA would issue certificates for arbitrary internal domains without any kind of validation, including no verification of conflicts with already issued certificates and no authentication and access control who can get certificates issued and for what domains.

Such blind instead of verified trust by the CA would clearly be insecure. If this is combined with an insecure network where the attacker can spoof system and thus redirect traffic to its own servers this can be used to MITM access to services by using a different but still valid certificate for the service.

Surely the CAs have thought about this?

We can rely here only on your description of what happens, which might not show the complete picture.

In this case, isn't it better to use a completely internal CA like Active Directory Certificate Services or step-ca rather than having a paid CA issue these certs?

Probably these can be used in a similar insecure way. So it is not the question of which product is better but how it is used.

Answer 2

Yes, the CA could be used for MitM attacks. There are at least two major design errors in this PKI:

• The .internal TLD is strictly for, well, internal domains of a single organization, but letting the same CA issue certificates for multiple organization obviously violates this scope restriction.
• If the CA issues certificates without any verification, then the certificates are pretty much meaningless, even within a single organization. A certificate is supposed to bind the public key to a particular identity (like a domain), but if you never verify this identity, then there's no actual connection between the two. It's like a blank certificate where anybody can put in any domain they want.

To fix this, you need to decide on the scope of the CA, and you need to actually ensure that certificates for a domain can only be obtained by those who control the domain.

• If you want an organization-specific CA, then you cannot share it between different organization. If you want a “global” CA, then you cannot use internal domains.
• DNS- or HTTP-based verification works for internal domains, too. But even if you decide against both methods, there has to be some kind of check, be it automated or manual.