Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible to make a certification authority certificate (even unsigned), which only allow to sign certificates for specific domain(s)?

share|improve this question
Do you mean in an enterprise domain environment with multiple domains you have a CA in one domain? And you only want it to be valid in that domain? – NULLZ Feb 23 '13 at 11:26
I mean allow the CA certificate to sign for limited amount of domains so it can't be misused for other domains. – Smit Johnth Feb 23 '13 at 13:24
up vote 9 down vote accepted

(I assume you are talking about certificates for SSL servers.)

Technically no. What would be closest to that would be the Name Constraints extension (see section of RFC 5280), which theoretically allows for restricting a complete PKI subtree to an explicit set of domains (and subdomains thereof). The extension supports both whitelist and blacklist semantics (in your case, you would like a whitelist). In practice, however, this fails for two reasons:

  • The Name Constraints extension is mostly unsupported by existing implementations of SSL. They are likely to ignore the extension.

  • When a SSL client connects to a server, it looks for the server name in the server certificate, as specified in RFC 2818, section 3.1. It will look for names of type dNSName in a Subject Alt Name extension, and these names are covered (theoretically) by the Name Constraints. However, if the server certificate lacks a Subject Alt Name extension, clients will fall back on the Common Name (in the subjectDN). The Common Name is not in scope of the Name Constraints. This means that a certificate could evade the name constraints by omitting the Subject Alt Name extension and putting an arbitrary server name in its Common Name.

(This is the whole story of X.509: lots of hooks and provisions for many useful features, which don't work because of lack of support from implementation and lack of coordination between specification bodies.)

share|improve this answer
>The Common Name is not in scope of the Name Constraints< - well, what is it for then? About support: most browsers even doesn't support newest SSL versions. – Smit Johnth Feb 23 '13 at 14:08
Common Name is in scope of Name Constraints of type distinguishedName, which do not apply the domain-specific semantics; X.509 was not designed for storing a server name in the Common Name, but the name of a human being. Using the Common Name as a server name is a hack which, alas, we must live with since it is widespread. – Thomas Pornin Feb 23 '13 at 14:11
Like you tell, SSL certificates consist of WORKAROUNDS. – Smit Johnth Feb 23 '13 at 14:31
Damn! I made it work with successfully testing and then I read your answer (Common Name) – VarunAgw Oct 18 '15 at 14:05
To make things worse, hexchat failed to validate it because of some openssl bug – VarunAgw Oct 18 '15 at 19:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.