¿Qué problema habría con una clave privada abierta para que la usen los desarrolladores?

Tengo la sensación de que estás tratando de abordar el problema que tienes desde el extremo equivocado:

  

Siempre me cuesta crear una nueva clave para el desarrollo ...

No estoy seguro de lo que estás haciendo, lo que causa mucho dolor, pero si estás siguiendo los mismos pasos una y otra vez, podría ser realmente útil encontrar una forma de automatizar estos pasos por ti mismo.

  

En realidad, me parece más seguro para mí como desarrollador que crear un certificado autofirmado con herramientas disponibles públicamente y tener la llave en mi disco duro para que las pueda usar. Si alguien consiguió eso, podrían falsificar cualquier sitio web para mí porque tengo que confiar en él, ¿no?

Si interpreto esto correctamente, está creando un certificado de servidor autofirmado con restricciones básicas CA verdadero (es decir, este certificado puede usarse para emitir certificados). Es correcto que se pueda usar para crear más certificado y, por lo tanto, el acceso al certificado y su clave se pueden usar para administrar todos los sitios, siempre que haya importado este certificado como CA confiable (autoridad de certificación) en lugar de un certificado de servidor de confianza. Tenga en cuenta que solo agregar una excepción una vez que el navegador se queja no agregará este certificado como autoridad de certificación.

También significaría que el atacante debe tener acceso a su sistema en primer lugar, en cuyo caso podría hacer más daño. Sin embargo, este problema en particular se puede mitigar fácilmente:

• La mayoría de los navegadores (¿todos?) en realidad pueden importar un certificado de servidor autofirmado que tiene restricciones básicas CA falso. Sin embargo, existen herramientas que no pueden lidiar con esto y esperan que CA sea cierto en un certificado autofirmado.
• Uno podría crear una CA con su propia clave privada, dejar que emita algunos certificados de hoja (restricciones básicas CA falsas) con otra clave privada y luego desechar la clave privada de la CA. La CA aún puede importarse como confiable en el navegador para que todos los certificados emitidos por esta CA también sean confiables. Como la clave privada de la CA se elimina, no se pueden crear más certificados.

  

fakesite.com enviaría todos los subdominios a una página en el sitio web principal, lo que explicaría para qué sirve. El certificado real y la clave privada se pondrían a disposición en otros lugares, como en un repositorio de github.

No es una buena idea usar un dominio disponible públicamente para esto. El problema es que es inseguro de manera predeterminada, es decir, el navegador resolverá el dominio e intentará conectarse a él y no se detectarán ataques de personas en el medio al dominio ya que todos conocen la clave privada para montar ataques invisibles. Y luego el atacante podría hacer los ataques que ya has descrito y tal vez más.

Afortunadamente, la CA pública que ha emitido el certificado revocaría el certificado de todos modos si la clave privada se conociera públicamente y, por lo tanto, esta idea no funcionaría (siempre que los navegadores verifiquen la revocación, lo que muchos no lo hacen o no lo hacen). correctamente).

Pero la idea general podría modificarse para ser más segura. Si uno simplemente usa un dominio que nunca existirá públicamente, un navegador solo puede conectarse al dominio si el sistema está específicamente configurado para esto. RFC 2606 define algunos dominios de nivel superior que pueden usarse para esto, es decir, .example , .test , .invalid y .localhost . Al usar cualquiera de estos dominios de nivel superior, un atacante solo podría dañar los sistemas de desarrolladores que están configurados específicamente para resolver dichos dominios y que han importado explícitamente este certificado como un certificado de servidor confiable, en lugar de poder dañar sistemas arbitrarios.