En realidad, debe usar dnsNameentradas en la subjectAltNamesección del certificado para especificar los FQDN, no la parte CN del subject. El uso subjectde este para este propósito ha quedado en desuso desde que se publicó RFC 2818 en 2000. Citando la sección 3.1 :
Si está presente una extensión subjectAltName de tipo dNSName, DEBE usarse como identidad. De lo contrario, DEBE utilizarse el campo de Nombre común (más específico) en el campo Asunto del certificado. Aunque el uso del nombre común es una práctica existente, está en desuso y se alienta a las autoridades de certificación a utilizar el dNSName.
El único caso en el que el contenido de los subjectmismos es relevante en el contexto de la validación del certificado del servidor es si no se dnsNameincluye en el subjectAltName, un caso que ha quedado en desuso durante los últimos 17 años en el momento de la escritura.
El uso de certificados comodín está en desuso, como se muestra en la sección 7.2 del RFC 6125 :
Este documento establece que el carácter comodín '*' NO DEBE incluirse en los identificadores presentados, pero PUEDE ser verificado por los clientes de la aplicación (principalmente por razones de compatibilidad con la infraestructura implementada).
Usar la misma clave privada para varios servicios generalmente se considera una mala práctica. Si uno de los servicios se ve comprometido, las comunicaciones de otros servicios estarán en riesgo y tendrá que reemplazar la clave (y el certificado) para todos los servicios.
Sugiero RFC 6125 como una buena fuente de información sobre este asunto.