Na verdade, você deve usar dnsName
entradas na seção subjectAltName
do certificado para especificar os FQDNs, não a parte CN do subject
. O uso do subject
para este propósito foi preterido desde a publicação da RFC 2818 em 2000. Citando seção 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.
O único caso em que o conteúdo do subject
é relevante no contexto da validação do certificado do servidor é se não houver dnsName
incluído no subjectAltName
, um caso que foi preterido nos últimos 17 anos em o tempo de escrever.
O uso de certificados curinga é preterido, conforme mostrado na seção 7.2 do RFC 6125 :
This document states that the wildcard character '*' SHOULD NOT be
included in presented identifiers but MAY be checked by application
clients (mainly for the sake of backward compatibility with deployed
infrastructure).
Usar a mesma chave privada para vários serviços geralmente é considerado uma prática ruim. Se um dos serviços for comprometido, as comunicações de outros serviços estarão em risco e você terá que substituir a chave (e certificado) por todos os serviços.
Eu sugiro o RFC 6125 como uma boa fonte de informação sobre este assunto.