3

Why having a valid certificate for "exampe.com" I can't make a "child" certificate for "subdomain.example.com"?

Google Chrome showing invalid certificate's info

What insecurities will arise if browsers start allowing domain's certificates to be valid CA for subdomains?

Vi.
  • 219
  • 2
  • 10

1 Answers1

11

X.509 validation is nominally disjoint from domain names. X.509 was designed in the context of The Directory, a mythical beast which can be thought of as a big, worldwide LDAP directory referencing every server on Earth and elsewhere. (Historically, it went the other way: LDAP is Lightweight Directory Access Protocol, a reduced version of the protocol which was meant to access the Directory.)

In the Directory, entities are designated by their Distinguished Name, a tree-like structure which has no relation with domain names (although some people have forced one into the other with "DC" DN components).

In true X.509, allowing a certificate owner, linked to a domain name, to act as a sub-CA for its own sub-domains is theoretically possible, but requires the use of the Name Constraints extension, which is standard, but almost universally unsupported. The idea would be to issue a certificate containing the name example.com, marked as a CA (Basic Constraints extension with cA set to TRUE), and Name Constraints extension with a "permitted subtree" of value .example.com (this should constrain ulterior certificates to sport host names, and these names may only be in subdomains of example.com). It is a neat idea, but it fails due to lack of support from browsers. So the net effect, if a CA issues such an empowered certificate to a domain, will be one of the two followings:

  • Client browser rejects the certificate.
  • Client browser accepts the certificate, but would also have accepted it even if it was not a proper subdomain.

Browser vendors are not keen on implementing this feature because it would be quite useless until commercial CA use it, and commercial CA won't use it until it is implemented by browsers. Moreover, commercial CA tend to prefer it if you buy several certificates from them instead of just one.

To sum up, this is a sad story of X.500 people not getting along well with IP/DNS people, and browsers not implementing the necessary features to get the whole thing to work. Things are unlikely to change in the near future.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 1
    I was unhappy when I found out that setting up HTTPS server brings your from technology world to the cryel money-ridden world... We're on the way from IPv4 to IPv6 (where you typically get a large subnet instead of single addresses). Maybe it's time to also provide better SSL where you also get some large thing by default (i.e. can create a child certificate, like as "fork-chroot-drop_privileges" in Unix)..? – Vi. Apr 03 '13 at 19:57
  • From what I understand, certain countries' certificate authorities are only "authorized" to issue certificates for their countries' top level domain. I would think questions of whether a CA should be considered "trustworthy" enough to be considered a root CA would be greatly eased if certificate authorities could be accepted as root CAs only for addresses within the proper domain. – supercat Sep 26 '14 at 21:49
  • If a CA in France is only authorized to issue certificates for `.fr` domains, one in Nigeria only for `.ng` domains, etc. then even if a CA was corrupt it would only affect the security of domains for which he could legitimately issue certificates. I would think it would be good for browsers to validate such things even if the feature weren't used for anything beyond that. – supercat Sep 26 '14 at 21:53