Irónicamente, certificados X.509 puede teóricamente tener el alcance a dominios específicos y sub -dominios, a través de la extensión Restricciones de nombre : si un certificado de CA contiene una extensión Name Constraints con un campo permittedSubtrees que contiene un dNSName del valor example.com puede emitir certificados solo si los nombres de host que aparecen en las extensiones Subject Alt Names de estos certificados son del dominio example.com o de un subdominio del mismo. Esta restricción se propaga a lo largo de la cadena, por lo que los certificados emitidos por la sub-CA también deben cumplir.
Lamentablemente, este esquema falla en la práctica, por dos razones:
-
Cuando el certificado del servidor no incluye una extensión Subject Alt Name , los clientes SSL tienen el hábito de usar el nombre común del subjectDN como sustituto. Según las reglas de X.509, el nombre común no está no cubierto por el Name Constraints de tipo dNSName . El uso del Nombre común está explícitamente permitido por RFC 2818 .
-
Nadie implementa soporte para Name Constraints . Si no marca la extensión como crítica, los clientes la ignorarán. Si marca la extensión como crítica, los clientes rechazarán el certificado. Por lo tanto, realmente no puedes usarlos.
La falta de soporte implica que nadie intenta realizar un alcance de los certificados con Name Constraints . Como nadie lo intenta, los implementadores no tienen incentivos para implementar el soporte.
La consecuencia general es que, actualmente, los CA no están incluidos en el ámbito. Por lo tanto, cualquier CA raíz en la que confíen los clientes SSL y cualquier CA intermedia emitida (directamente o no) por una de estas CA raíz, será técnicamente confiable para validar los certificados de servidor SSL para cada nombre de dominio posible.
Sin embargo, las CA rogue son una ocurrencia bastante rara. La razón es que un certificado falsificado, con un nombre falso, también apunta claramente a la CA que lo emitió. Falsificar certificados es muy riesgoso para un CA; Hay una casi certeza de ser atrapado después del hecho. La CA raíz se incluye en el sistema operativo y los navegadores mediante la firma de contratos que imponen sanciones graves por mal comportamiento; cuando la CA raíz emite certificados de sub-CA, nuevamente imponen contractualmente el mismo tipo de sanciones. Estamos hablando de millones de dólares aquí.
Los casos reales de certificados falsos se deben principalmente a compromisos, de naturaleza transitoria, y ocurren aproximadamente una vez al año.