Para ser aceptado como un emisor para otros certificados, un certificado de CA debe estar marcado como tal: deben contener un extensión Basic Constraints con el indicador cA establecido en TRUE . Si un cliente (por ejemplo, un navegador web) ve una supuesta cadena de certificados de servidor, con el certificado "X.com", no marcado como CA, utilizado como CA intermedio, el cliente rechazará la cadena, en aplicación del estándar algoritmo de validación de certificados, en sección 6.1.4 , paso (k):
(k) If certificate i is a version 3 certificate, verify that the
basicConstraints extension is present and that cA is set to
TRUE. (If certificate i is a version 1 or version 2
certificate, then the application MUST either verify that
certificate i is a CA certificate through out-of-band means
or reject the certificate. Conforming implementations may
choose to reject all version 1 and version 2 intermediate
certificates.)
Tenga en cuenta los comentarios sobre los certificados "versión 1" y "versión 2". Los certificados modernos X.509 son "versión 3" (su campo version contiene 2, no 0 o 1). Las versiones anteriores para el formato X.509 no tenían espacio para extensiones, por lo que no hay Basic Constraints . La vulnerabilidad evidente que temía, con cualquier propietario de certificado que pudiera actuar como CA, era, sin duda, evidente. Pero a la gente le tomó varios años ponerse al día.
Afortunadamente, todas las implementaciones actuales de SSL consideran los certificados v1 y v2 como "definitivamente no CA", al igual que el certificado v3 que carece de una extensión Basic Constraints .
En una vena similar, Internet Explorer, hasta alrededor de 2003 (si recuerdo bien), no comprobó el indicador cA ... y de hecho fue un problema grave, que se solucionó rápidamente cuando se descubrió. Dice bastante acerca de X.509 que nadie lo ha probado durante bastante tiempo, porque IE ya tenía soporte SSL en 1996 y los certificados v3 estaban estandarizados a principios de 1999 (entonces, como es típico de Web, ya estaban implementados en ese momento, y el estándar era más una documentación de la práctica existente que cualquier otra cosa).
En cuanto a su pregunta específica: ¿cuánto tiempo se extiende esta cadena? No hay límite intrínseco, en el estándar X.509, sobre la longitud de la cadena, siempre y cuando todos los certificados de la cadena estén debidamente marcados como CA (excepto posiblemente el último) y tengan las firmas adecuadas y todos los campos en los certificados coincidan como Ellos deberían. Sin embargo, la certificación es delegación de confianza y la confianza se diluye muy rápido cuando se delega demasiado. Por lo tanto, las cadenas excesivamente largas son una clara indicación de que todo el proceso de PKI ha ido mal.
Además, las cadenas largas pueden alcanzar límites internos en algunas implementaciones. La construcción de la cadena (la operación que prepara las cadenas potenciales para validarse) puede resultar costosa (con certificados especialmente diseñados, puede tener un costo factorial para una longitud de cadena dada), por lo que las implementaciones deben incluir algún mecanismo de protección, que A menudo es una longitud máxima interna de la cadena. Las cadenas que se encuentran en la práctica tienen una longitud de 2 a 4 certificados (es decir, una raíz, tres CA intermedias como máximo y luego el certificado de entidad final). Mi propio código tiende a rechazar cadenas más allá de 8 certificados, y ese límite arbitrario nunca ha sido, en mi experiencia, un problema.