¿Puede un certificado SSL tener un período de validez más largo que el principal en la cadena X.509?

Este es un punto disputado históricamente.

En el algoritmo de validación de RFC 5280 (que reemplaza a RFC 2459 , por cierto), no hay ningún requisito de anidación de rango de validez. Sin embargo, algunas implementaciones históricas han insistido en ello; Consulte, por ejemplo, la guía de estilo X.509 de Peter Gutmann:

  

Aunque esto no está especificado en ningún estándar, algunos programas requieren validez   período de anidación, en el que el período de validez del sujeto se encuentra dentro del emisor   período de validez Sin embargo, la mayoría del software realiza una simple comprobación puntual   que verifica si una cadena de certificados es válida en un determinado momento   (normalmente la hora actual). Mantener la jerarquización de validez requiere que un   Se debe usar cierta cantidad de cuidado en el diseño de períodos de validez superpuestos   Entre sucesivas generaciones de certificados en una jerarquía. Promover   surgen complicaciones cuando una CA existente es re-rooteada o re-parented (para   ejemplo, una CA divisional está subordinada a una CA corporativa).

Microsoft PKI ("ADCS", también conocido como Servicios de certificados de Active Directory ) impone el período de validez del anidamiento, ya que cuando emite un certificado, no permitirá la fecha de finalización de la validez de ese certificado exceda el del certificado de CA actual (en efecto, truncando el período de validez estipulado por la plantilla si llevaría a tal situación).

A pesar de que, al renovar un certificado de CA, es posible mantener el mismo nombre de CA y la misma clave de CA, en cuyo caso los certificados de CA antiguos y nuevos pueden ser se usan indistintamente siempre y cuando ninguno de los dos caduque, en certificados EE emitidos antes y después de la renovación. Es decir, si el antiguo certificado de CA es CA1, el nuevo es CA2, el certificado EE1 se emitió antes de la renovación y el certificado EE2 se emitió después, entonces CA1- > EE1, CA1- > EE2, CA2- > EE1 y CA2- > EE2 deben validarse todos; Esto es muy conveniente para asegurar transiciones suaves. Si bien el anidamiento del período de validez implica que CA1- > EE1 y CA2- > EE2 se anidará, CA1- > EE2 y CA2- > EE1 podrían no anidar, y esto está bien.

Resumen: no puede confiar en el anidamiento del período de validez, y no debería intentar imponer el anidado al validar certificados.

Hmm, estoy de acuerdo en que hubiera esperado encontrar esta información en RFC 5280 4.1.2.5. Validez . (Por cierto, el RFC 5280 obsoleta al RFC 3280, que obsoleta al RFC 2459, por lo que realmente ya no debería estar mirando el 2459).

Dicho esto, puede resolver esto lógicamente (al menos para una configuración estándar similar a TLS): cuando un usuario final valida un certificado, tiene que seguir la cadena hasta la raíz, asegurándose de que cada certificado a lo largo el camino es valido Digamos que X2 caduca antes de X1 (y supongamos que X2 fue el emisor de X1). Una vez que X2 expira, X1 es tan bueno como inútil, ya que no hay manera de construir una cadena de validación de X1 a Xn.

Este es un caso en el que una CA puede emitir certificados con una vida útil más larga que la raíz: los requisitos establecen que A) Todos los certificados de hoja deben tener una vida útil de 3 años (digamos que van a dispositivos integrados) B) Todas las hojas los certificados deben emitirse fuera de la misma raíz (digamos que solo tiene espacio para anclar una raíz). Ahora, el certificado CA expirará en 2 años, y dentro de ese tiempo planea emitir un nuevo certificado CA para la misma clave de CA. En ese caso, no hay problema en emitir un certificado de 3 años de una raíz de 2 años.

La pregunta que está haciendo es un poco vaga en cuanto a si está buscando a la entidad emisora de certificados / emisor para aplicar la regla de "anidación de validez", o para que el cliente / verificador la aplique.

1. Si eres el CA / Emisor: : depende de ti. Hay muchos CA que no emitirán un certificado con una vida útil más larga que ellos mismos. Dicho esto, puedo imaginar escenarios en los que querría hacer esto.

2. Si eres el cliente / verificador: no creo que te gane nada para ser estricto al respecto. Usted está causando intencionalmente problemas de compatibilidad entre su cliente y las CA que no siguen el "anidado de validez" ... ¿para qué beneficio? _ (asumiendo que todos los certificados de la cadena deben estar dentro de su período de validez en el momento de la validación, supongo que esto es lo que usted llama "validación estándar" en su comentario).