(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 126.96.36.199 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:
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.)