A certificate is only as good as whoever validates it thinks it is. A certificate is good for SSL as long as the SSL clients (e.g. Web browsers, or VPN clients) accept it as good. Whatever you do, the existing clients will lead the dance.
A "wildcard" certificate is described in RFC 2818, section 3.1:
Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., .a.com matches foo.a.com but
not bar.foo.a.com. f.com matches foo.com but not bar.com.
This is the only place where the "
*" character has any special meaning. This means that your wildcard certificate is "a wildcard certificate" only in the context of a HTTPS server: in that context, the client will require that the intended server name (the one in the URL) matches the name in the certificate; the "wildcard" is a kind of match-all. So your certificate will be accepted by clients as a certificate for servers foo.domain.com, bar.domain.com, qux.domain.com... and so on.
Note that a few other protocols have more or less adopted the same name matching rules; e.g. a certificate for an IMAPS server will also need to contain the server name (that is, the name that the clients expect). Also, note that complete support for wildcards is kind of a rarity (clients who accept to consider
*fo*.domain.com as matching
foo.domain.com are not legion).
This is completely orthogonal to the question of issuing sub-certificates. A certificate which is accepted as an issuer for other certificate is called a CA certificate and the hallmark of a CA certificate is that it contains a Basic Constraints extension with the
cA flag set to
TRUE (see RFC 5280, section 22.214.171.124). No client will accept a certificate issued by your "wildcard" certificate unless it has this flag; and the presence or absence of a "
*" character in the name is totally irrelevant here.
As a side note, I find a bit dubious the idea of "securing everything" by copying the same certificate and private key in many machines. The more you copy a private key, the less secret it becomes. Asymmetric cryptography was meant as a way to avoid copying secret keys. The normal certificate paradigm is that each entity in a network should have its own private key, instead of sharing the same private key between hosts.