Evite los certificados con múltiples CN (como se sugiere en los comentarios), no es así como las especificaciones (RFC 2818 y RFC 6125) dicen que debería funcionar y, aunque puede funcionar en algunas aplicaciones de clientes, generalmente fallará. De RFC 2818:
Si una extensión subjectAltName de tipo dNSName está presente, que debe ser utilizado como la 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 recomienda a las Autoridades de certificación que usen el nombre dNSName.
En su lugar, genere certificados (o CSR) con múltiples nombres alternativos del sujeto (SAN).
Si utiliza OpenSSL, editar su openssl.cnf
(o editar una copia) y establecer estas propiedades, en las secciones pertinentes ([req]
y [ v3_req ]
):
[req]
req_extensions = v3_req
[v3_req]
subjectAltName=DNS:www.example1.com,DNS:www.example2.com,DNS:www.example3.com
También hay un buen truco para utilizar una variable de entorno para esto (más bien que arreglarlo en un archivo de configuración) aquí: http://www.crsr.net/Notes/SSL.html
Es posible que desee tener uno de ellos (cualquiera) en el CN.
(También puede estar interesado en this answer.)
Un poco googlear [me hizo esto] (https://certificates.heanet.ie/node/17). –
@LinusKleen: ¿Eso dará como resultado un certificado único con múltiples dominios en él? ¿Es eso posible? ¿O obtendrás múltiples certificados (usando la misma clave privada)? – Thilo
Es posible, @Thilo. Es un certificado único con su asunto que contiene múltiples CN. –