It is not a matter of wildcards. The behaviour you observe is due to the following: if there is a Subject Alt Name extension in the certificate, then the Common Name part of the DN is simply ignored. Said otherwise, the server names in the certificate should always be in a Subject Alt Name extension; the Common Name part of the subject DN is used as a fallback only if the Subject Alt Name extension is altogether missing (precisely, if there is no SAN, or if there is a SAN which contains no
dNSName element at all). See RFC 2818, section 3.1:
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
Therefore, in your case, you should put both
dNSName elements in the SAN extension (the SAN extension can contain many DNS names). Whether names are wildcard or not does not matter at this level. As an illustration, have a look at the certificate used by Google (connect on
https://www.google.com, then ask your browser to display the "certificate details"): this certificate currently features a SAN extension with no less than 44 DNS names, 34 of which being wildcard names.