Could having intermediate CA not installed to trust store be a vulnerability?

Question

I've read through several articles and posts here and on other resources and I'm still confused.

Say I have a key pair, and I got a server certificate for my public key from some trusted CA. Now I'm generating fake certificate for some domain that someone else owns and sign it with my private key from that pair.

Having that, I set up some public network where I configure domain name resolution so that that domain (owned by someone else) is associated with one of my hosts in the network.

I perform a MITM attack on that host and provide a fake cert that has a chain [fakecert->myservercert->trusted_ca].

Now assume some device is connecting to that network.

The issue and the question is:

Since I have all certs (up to the root) in the chain provided to the client, would the client consider that connection secure?

I'm asking because almost all such questions and posts do not state strict requirement to have intermediate CAs in trust store. However I do not believe such scenario can work because if it would, any web gateway could sniff your traffic without installing an additional certificate in your trust store.

Though the actual question (why can't someone use a server cert to issue fake certs) is buried, effectively dupe https://security.stackexchange.com/questions/249347/what-differentiates-a-ca-cert-from-a-server-cert and several more linked there , That said, Polynomial's answer is very good and will help extend the time it takes searchers to read through the information on this site. — dave_thompson_085, Sep 30 '21 at 00:36

score 3 · Accepted Answer · answered Sep 28 '21 at 17:20

Now I'm generating fake certificate for some domain that owns someone else and sign it with my private key from that pair.

The detail you're missing is that certificates contain fields that restrict the types of operations that a certificate can be used for. The CA will not provide you with a certificate that can be used to sign other certificates.

As an example, here's what the server certificate for this website shows:

Basic Constraints:
  Subject Type=End Entity
  Path Length Constraint=None

Key Usage:
  Digital Signature, Key Encipherment (a0)

Enhanced Key Usage: 
  Server Authentication (1.3.6.1.5.5.7.3.1)
  Client Authentication (1.3.6.1.5.5.7.3.2)

Notice that the server certificate is an End Entity certificate. This can only be used to identify an end entity like a server or client, and cannot be used to sign other certificates. The key usage also specifies that the key for that certificate can only be used for creating digital signatures (i.e. signing messages) and key encipherment (i.e. non-ephemeral key exchange). The enhanced key usage shows that that this is restricted to authenticating clients and servers.

Compare this to the intermediate CA certificate:

Basic Constraints:
  Subject Type=CA
  Path Length Constraint=0

Key Usage:
  Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing (86)

Enhanced Key Usage:
  Server Authentication (1.3.6.1.5.5.7.3.1)
  Client Authentication (1.3.6.1.5.5.7.3.2)

The intermediate CA's basic constraints show that it is a CA certificate. It is allowed to sign certificates and and revocation lists for the purposes of server and client authentication. You may also notice that the Path Length Constraint is set to 0. This means that the intermediate CA certificate key can only be used to sign End Entity certificates, not other intermediate CA certificates.

Finally, there's the root CA certificate:

Basic Constraints:
  Subject Type=CA
  Path Length Constraint=None

Key Usage:
  Certificate Signing, Off-line CRL Signing, CRL Signing (06)

Enhanced Key Usage:
  Client Authentication
  Document Signing
  Encrypting File System
  Secure Email
  Server Authentication
  Time Stamping

This again is a CA certificate, but without the path length constraint, meaning that it can be used to sign intermediate CA certificates as well as End Entity certificates. Unlike the intermediary CA key, the root CA key is disallowed from directly creating digital signatures - it can only be used for certificate and CRL signing. This is to prevent abuse of the CA cert if it is compromised. Finally, you can see that the enhanced key usage allows the CA certificate to be used to sign certificates for a variety of purposes other than just client and server authentication. This allows the root CA to generate intermediate CA certificates for things like authenticode and email signing, separate to certificates intended for HTTPS.

The client can look at the chain and validate these usage constraints. If you got an End Entity certificate issued by a trusted CA, then manually took the key and used it to sign another End Entity certificate for a different website, the client would see that the chain includes an End Entity certificate, without Certificate Signing usage, somehow signing another End Entity certificate. It would reject that chain.

Could having intermediate CA not installed to trust store be a vulnerability?

1 Answers1