Actually, you should use dnsName entries in the subjectAltName section of the certificate to specify the FQDNs, not the CN part of the subject. Using the subject for this purpose has been deprecated since RFC 2818 has been published in 2000. Quoting section 3.1:
If a subjectAltName extension of type dNSName is present, that MUSTbe used as the identity. Otherwise, the (most specific) Common Namefield in the Subject field of the certificate MUST be used. Althoughthe use of the Common Name is existing practice, it is deprecated andCertification Authorities are encouraged to use the dNSName instead.
The only case where the contents of the subject are relevant in the context of server certificate validation is if there is no dnsName included in the subjectAltName, a case which has been deprecated for the past 17 years at the time of writing.
Usage of wildcard certificates is deprecated, as shown by section 7.2 of RFC 6125:
This document states that the wildcard character '*' SHOULD NOT beincluded in presented identifiers but MAY be checked by applicationclients (mainly for the sake of backward compatibility with deployedinfrastructure).
Using the same private key for several services is usually considered bad practice. Should one of the services be compromised, communications from other services will be at risk and you'll have to to replace the key (and certificate) for all services.
I suggest RFC 6125 as a good source of information on this matter.