Recomendaría el uso de una raíz completamente separada para los certificados externos e internos, para evitar cualquier fuga de información sobre hosts o usuarios internos, a través de Root01, pero también para evitar cualquier confianza implícita por parte del software dañado. Al utilizar 2 raíces separadas para uso externo e interno, no es posible que ninguna confianza se filtre de los certificados Externos a los Internos, sin importar qué tan roto esté el software.
Normalmente, si tenemos rutas de certificación que se parecen a esto:
Root01 --> SubCA01 -> Cert01
Root01 --> SubCA02 -> Cert02
Y SubCA02 se importa como de confianza. En una implementación de PKI válida, Cert01 no debe ser confiable. Pero como sabe, con la codificación perezosa, el software defectuoso y el análisis intrépido de certificados, es posible que la confianza se filtre desde el subCA02 a Root01 y, por lo tanto, la filtración haga que Cert01 sea confiado por alguien que no debería confiar en ese cert, si el La implementación de PKI está muy rota y, por ejemplo, asume que cualquier certificado superior es de confianza automática. Sí, es muy inverosímil, pero es mejor tener en cuenta cualquier software dañado utilizando en su lugar raíces completamente separadas.
También agregaría una restricción básica PathLength = 0, lo que evitaría que el certificado de CA se use para firmar otros certificados de CA, además de la restricción de nombre.
Como sabrá, hay muchos programas defectuosos y un ataque de escalada de privilegios (como lo llama cuando alguien logra firmar un certificado que infringe las restricciones), por ejemplo, si dicho certificado PolicyExt01 se utiliza para firmar una CA subordinada, que a su vez está firmando un certificado S / MIME.
Algunos programas defectuosos solo comprueban, por ejemplo, las restricciones de nombres "1 nivel Profundo", y agregar una restricción de Pathlength causaría que las cadenas más largas fallaran en lugar de ser aceptadas como confiables.
Entonces me gustaría hacer esto:
Root01 (Name constraints = [email protected], PathlenConstraint=0, EKU=Message signing)
Root02 (Internal applications, not trusted by 3rd parties...)
Y luego compartir el certificado Root01 con aquellos terceros que deberían confiar en él, mientras instala tanto Root01 como Root02 en todas las computadoras internas de la Compañía.
Root01 y Root02 son certificados de CA raíz autofirmados.
Al usar Namingconstraint, solo pondría una restricción de nombre de Email@@domain.com, y luego pondré todas las demás restricciones de nombre (IP, DNS, UPN, URI) como comodín excluido, para evitar que se use un certificado como para por ejemplo, un certificado SSL de un sitio web, si un navegador o una implementación de SSL no puede analizar las marcas de uso clave.
Una buena idea también es probar su configuración, preferiblemente exportando el certificado de CA raíz y la clave privada a una computadora segura fuera de línea, y luego intentar firmar certificados "inválidos" con esto. Luego pruebe los certificados "inválidos" con el software cliente común para asegurarse de que las restricciones están activando y marcando el certificado como no confiable.
Personalmente, no conozco ninguna configuración explícita que pueda causar un ataque de "escalada de privilegios", pero, como usted sabe, hay muchas implementaciones SSL rotas y software PKI, por lo que es mejor prevenir que curar y restringir los certificados como tanto como sea posible, y también use raíces separadas para evitar cualquier pérdida de confianza entre los certificados por el software MUY roto.