• caglararli@hotmail.com
  • 05386281520

Support for domain-specific root CAs in X.509 certificate format, OS and browsers

Çağlar Arlı      -    28 Views

Support for domain-specific root CAs in X.509 certificate format, OS and browsers

Chance is one gets an invalid certificate warning when one follows this link https://www.cnss.gov. As explained there (same warning) this is on purpose, and the solution is supposed to be to install1 extra root Certification Authority certificate(s) in the machine or browser.

Is there support in the X.509 certificate format (e.g. some attribute) to

  1. Restrict the rights of a CA accredited by a root CA certificate, and the CAs it may certify, to certifying for iad.gov, ioss.gov, cnss.gov domains? Without this (and support in OS or browsers), by installing a root CA certificate, one is granting unnecessary powers to the added root CA2.

    Update: a comment points to a question Can I restrict a Certification Authority to signing certain domains only?, which answers tell that "Name Constraints" do just that. So make my question: how widely and correctly supported are "Name Constraints" by now3?

  2. Make a root CA the exclusive supplier of certificates for stated domains? Without this (and support in OS or browsers), the domain-specific CA gives no protection that I can discern to the domain users, and the whole mess would seem pointless to me.

Note: I used "browsers" but the question extends to any program using certificates other than thru OS services.


1 That's by running a 29MB executable that anyone can download (from a domain with standard CA practices), or installing a separate certificate which access appears restricted, but the question is not about how nonsensical these installation processes are.

2 Admittedly, that may not be much of an issue, compared to the fact that many state actors of many states can obtain a rogue certificate for anything: there are already so many trusted CAs (counting those indirectly trusted), and it's enough to subvert one. IMHO, the complexity of actually organizing a Man-in-the-Middle attack, more than the residual risk of the rogue certificate being noticed, is the main deterrent against too casual a use of that facility. But the question is not about that either.

3 And as a test: are the certificates we are asked to install in my example using "Name Constraints"?