Además, ¿no complica los posibles escenarios de revocación en el sentido de que si un host se ve comprometido, entonces todos deberán modificarse?
Cuando la clave privada (para la cual está asociado el certificado) está comprometida, se revocan los certificados para esa clave.
Si el certificado se aplica o no a un solo dominio, muchos nombres alternativos de sujetos (SAN), o es un certificado comodín; todavía es un certificado único y no complica el proceso de revocación.
Y suponiendo que hay otros certificados para el mismo dominio (s), si son de diferentes claves privadas no destacadas, entonces estos no se verán afectados por la revocación del certificado mencionado anteriormente. A pesar de la superposición de nombres de dominio.
Seguro que esto es una fuga de información que permite a un posible pirata informático obtener más información sobre su organización de la que usted desea.
Es bastante posible que una SAN incluya un subdominio que no se pueda encontrar de otra forma, excepto por Brute Force. Creo que en este caso particular, estos subdominios probablemente se encuentren fácilmente por otros medios.
Incluso si se pretendía que fueran secretos, los diseñadores de software no deberían confiar en el secreto de su nombre de host. Esto se almacena en el historial del navegador, se sincroniza con la nube y probablemente se envía por correo electrónico a los compañeros de trabajo.
Por lo tanto, el hecho de que SAN enumere estos dominios podría ahorrarle al atacante algún tiempo para encontrar subdominios, la publicación de esta información no se considera una vulnerabilidad.
El verdadero riesgo de vulnerabilidad estaría en la aplicación, y ahí es donde debería estar el enfoque de seguridad.
