Certificado de comodín SSL para emitir otros certificados

3

Digamos que compro un certificado SSL * .example.com. Ahora quiero generar subcertificados e incluir el certificado * .example.com en una ruta de confianza:

  1. host1.example.com, con un nombre alternativo rr.example.com
  2. host2.example.com, con un nombre alternativo rr.example.com
  3. host3.example.com, con un nombre alternativo rr.example.com

Las preguntas son:

  1. ¿Los navegadores web y otros clientes reconocerán esos subcertificados si se reconoce el certificado * .example.com?
  2. ¿Debería regenerar todos los subcertificados cuando caduque el certificado principal, o podría prolongar el * .ejemplo.com dejando el resto intacto, o emitir un nuevo * .ejemplo.com y firmar mis subcertificados con este?

En realidad, estoy buscando una forma barata de migrar mi red de certificados autofirmados a los firmados, por eso cada servidor debería tener un certificado diferente y no uno compartido. Además, también debería ser más fácil en el mantenimiento si una de esas claves tiene fugas.

    
pregunta czaks 28.04.2014 - 10:53
fuente

2 respuestas

2

Lamentablemente, el modelo PKI implementado en los navegadores no impone una restricción de los dominios que puede firmar con una CA, por lo que cualquier sub-CA puede firmar cualquier dominio que desee. Es por eso que ninguna CA en la que se confía en los navegadores emitirá una sub-CA de este tipo (al menos oficialmente, todavía podría emitirlas para permitir que algunas agencias realicen ataques de intermediarios). Por lo tanto, no podrá comprar una CA secundaria que solo puede firmar dominios a continuación de example.com.

Incluso si pudieras comprar un certificado de este tipo, el tema no importa, por ejemplo. puede ser *.example.com o lo que sea. El sujeto solo se usa para encontrar la CA emisora al hacer coincidir el nombre del emisor en el certificado hoja con el nombre del sujeto de las CA conocidas al validar la cadena de confianza.

Aparte de eso, un certificado no se firma con el certificado de la CA, sino con su clave privada. Por lo tanto, si el certificado de la CA caduca, solo puede emitir un nuevo certificado con el mismo par de claves pública / privada y el mismo asunto y no necesita volver a emitir todos los certificados firmados por su CA. Pero generalmente la validez de una CA es mucho más larga que la de los certificados emitidos por la CA. Por lo general, no vuelve a emitir un nuevo certificado de CA porque ya no es válido, sino porque la clave privada se vio comprometida o se debilitó (por ejemplo, reemplace las claves de 1024 bits por 2048 bits). En este caso, la clave pública cambia, por lo que debe volver a firmar los certificados emitidos por la CA.

    
respondido por el Steffen Ullrich 28.04.2014 - 13:30
fuente
1

Creo que necesitará su propio modelo de CA para sus servidores, ya que la compra de un certificado válido para firmar otros certificados no es una opción según esto .

Suponiendo que tiene una red interna de servidores que sirven datos / servicios a través de HTTPS. puede utilizar openssl para crear una jerarquía de certificados. En el nivel superior será un certificado autofirmado que se utilizará para firmar otros certificados para el uso de sus servidores. Consulte esto para obtener más información. La mejor parte sobre el uso de openssl es que no requiere inversiones para crear un modelo de CA.

Los certificados generados por este enfoque serán reconocidos por los navegadores si el certificado raíz está instalado en el almacén de confianza. Como tiene control total sobre su certificado raíz, puede darle la validez deseada simplificando el mantenimiento.

En caso de una pérdida de clave privada. Debe crear un nuevo certificado raíz y generar nuevos certificados de servidor. Pero con este enfoque no debería ser un gran problema.

    
respondido por el Shurmajee 28.04.2014 - 11:58
fuente

Lea otras preguntas en las etiquetas