Can a CN-only certificate bypass a name constraint?

Question

I am trying to cross-certify an internal issuer certificate, adding a name constraint for our domain.

However, it seems that an attacker could bypass this protection by putting the desired host name in a CN attribute of the subject, and not adding a subject alternative name extension. The scenario is an operator for our internal CA goes rogue, and creates illegitimate certificates to execute MITM attacks.

In short, it seems like the name constraint is useless, unless it contains a directory name constraint all the way down to a CN for a specific host (in which case, it's secure, but still worthless).

Would this attack work in practice? Do browsers take measures to prevent it?

Answer 1

The "official" X.509 stance on rogue CA is that rogue CA are out of scope of X.509. It takes some effort to accept that... The idea is that all the CA structure is not really about preventing attacks, but rather being able to point fingers at the culprits. If a CA goes rogue, then the fraudulent certificate chain will allow to pinpoint which CA got it wrong, and thus direct blame where it is due.

---

Most browsers deal with the issue about name constraints by not supporting name constraints at all, which means that trying to restrict a sub-CA to a specific domain is, for now, a fool's quest.

IF the support of name constraints was wide-spread, then you could restrict a sub-CA to issuing SSL/TLS for a specific domain by adding a name constraints that forces the subject DN to a prefix that defines the CN to a value that cannot be a FQDN for a machine. Thus, any "SSL aware" certificate would necessarily need a SAN extension, thereby avoiding the problem you allude to. But this still makes assumptions on the behaviour of implementations that encounter a certificate whose subject DN contains multiple "CN" fields; if the SAN constrains the DN to "CN=INVALID FOR DOMAIN", and the rogue sub-CA issues a cert with, as DN: "CN=INVALID FOR DOMAIN,CN=www.google.com", how will client software react ?

To sum up, name constraints don't work well or at all in practice, for lack of widespread support, but even if they were supported, whether they actually work would remain a hit-and-miss game.

Answer 2

I'd like to expand on Tom Leek's excellent first paragraph where he said:

The "official" X.509 stance on rogue CA is that rogue CA are out of scope of X.509. It takes some effort to accept that...

The whole CA ecosystem works on the idea that the root CA in a chain is absolutely trustworthy, hence Certificate Authority - you don't question an authority!

By putting a root cert into your trust store you are saying "I believe that those guys are trustworthy and dependable and will never issue a fraudulent certificate". If an intermediate CA is caught issuing fraudulent certs, (we hope) that the root CA above them will revoke their certificate, making all the certs they've ever issued become instantly invalid, allowing admins to begin cleanup and re-issuance of valid certs. If a root CA is ever caught issuing fraudulent certs, their public trust will be gone, they will get ripped out of the browsers, they will lose all their customers, and they will go out of business - almost over night (see: DigiNotar).

For better or for worse, the entire system hinges on trust that the public CAs are acting in good faith out of fear of bankruptcy if they are caught (and with the amount of auditing they have to go through, we hope they will be).

As Tom said,

It takes some effort to accept that...