¿Hay algún motivo legítimo para instalarse como CA raíz?

Se requiere una CA personalizada si desea usar https en su intranet corporativa. Las CA de terceros solo pueden otorgarle certificados para dominios públicos. No le darán certificados para intranet.local ni ningún otro nombre de host que solo se enrute en su propia red. Entonces, cuando desee tener un certificado para su intranet o para la interfaz web de sus propios servidores, debe agregar una CA personalizada y firmarla usted mismo.

Puede preguntarse "¿Por qué usaría https en mi propia red"? Actualmente hay una tendencia a implementar todo como una aplicación basada en navegador. Esto significa que cada vez más procesos se manejan a través de interfaces web internas, incluidas las sensibles. Por ejemplo, nuestra empresa está implementando actualmente una aplicación de intranet basada en la web para ver nuestras propias nóminas (y, con suerte, solo las nuestras). Pero en organizaciones más grandes, la red interna puede llegar a ser tan grande y compleja que ya no se puede hablar de una LAN privada. Escucharse de los atacantes internos se convierte en una posibilidad que no se puede hacer a mano, por lo que el cifrado interno se convierte en una precaución razonable.

Los certificados son una cuestión de confianza.

Se supone que los CA son globales de confianza, por lo que podemos confiar en ellos incluso si no nos conocemos.

En los casos en los que solo se está comunicando con personas que conoce o ... usted mismo, como cuando es responsable de una red de máquinas diferentes, puede optar por confiar más en sí mismo que en una CA que, de hecho, , no lo sabes.

Un ejemplo podría ser cuando desee crear túneles a través de openVPN entre las computadoras que administra.

Intencionalmente "espiando" a ti mismo para propósitos de depuración, utilizando herramientas de proxy como Fiddler o Charles para capturar el tráfico https.

Estas herramientas suelen ser utilizadas por los desarrolladores de aplicaciones móviles, entre otros, para depurar las comunicaciones cliente-servidor. Una CA raíz se puede generar e instalar en un dispositivo móvil, una computadora configurada como el proxy http de ese dispositivo y todo el tráfico web, incluidos los detalles de los encabezados, las cookies, etc. se mostrarán al desarrollador.

Esto es útil para comprender el rendimiento de las solicitudes de red, decidir si culpar al cliente o al servidor por un error o a la ingeniería inversa de las API existentes.

Otra respuesta (adicional) es que las CA privadas tienen un dominio de seguridad diferente al de las CA públicas.

Una CA pública certificará la información pública: el hecho de que el propietario de la clave privada coincidente tiene un derecho público particular en el momento de la solicitud. a ellos realmente no les importa la segregación interna y definitivamente no protegerán los recursos internos (por ejemplo, el ejemplo proporcionado por @Philipp sobre los nombres de host que no pertenecen al DNS público).

Una CA privada tiene que ver con la protección de sus recursos internos: está diseñada para tener un dominio de aplicación más limitado: solo funcionará dentro del contexto de su red. Por lo tanto, se puede utilizar para asegurar la comunicación interna y proporcionar autenticación interna que tenga poco o ningún significado fuera de la red.

Además, son un poco más seguros de usar: puedes delegar el acceso más fácilmente con ellos. Por ejemplo, el administrador de una sucursal local podría tener el derecho necesario para emitir certificados para los sistemas y las personas bajo su control sin tener que delegarle la identidad corporativa completa.

Otra razón por la que una organización podría querer instalar un certificado raíz es para el filtrado de contenido. Mi escuela secundaria tenía un filtro de contenido justo antes del firewall, cuyo objetivo era evitar que los estudiantes accedieran a varios tipos de contenido. Sin embargo, no hizo un buen trabajo de filtrado de las conexiones HTTPS; a veces se bloqueaba según la dirección IP, pero en algunos sitios solía ser muy pesado (bloqueando la dirección IP completa) y no se filtraba en absoluto. Otros (dando acceso completo, sin filtro). Por ejemplo, los estudiantes rápidamente se dieron cuenta de que podían acceder a Facebook si escribían https://facebook.com . (Creo que el filtro de contenido era lo suficientemente antiguo como para que tampoco admitiera la Indicación de nombre de servidor).

Poco antes de graduarme, instalaron un nuevo filtro de contenido que proporcionaba un filtrado completo en el tráfico HTTPS. Instalaron una CA raíz en todas las computadoras, y el firewall crearía certificados sobre la marcha para los sitios web de HTTPS. Esto permitió el bloqueo basado en URL (en lugar del bloqueo basado en el nombre de host mucho más grueso que habría tenido que usar si no hubieran falsificado los certificados), por lo que, por ejemplo, ahora podrían permitir que los estudiantes vean videos de YouTube mientras bloquean a otros.

Curiosamente, el firewall tenía la opción de detectar el tráfico en los sitios bancarios, junto con una gran advertencia para dejar la opción desactivada por seguridad. (Probablemente tenía una lista blanca de dominios financieros).

Si estuviera ejecutando una red corporativa y quisiera vigilar lo que hacían mis empleados, crearía un servidor de certificados y configuraría todas las computadoras cliente para que solo confiaran en los certificados de este servidor. Luego, este servidor emitiría sus propios certificados para cualquier sitio que mis empleados necesiten usar. Luego, mis empleados usarían felizmente su gmail, Facebook, etc. Sin saberlo, el certificado que está utilizando su navegador no lo emite una CA externa, sino mi propio servidor de CA de red interna. El servidor proxy de red puede registrar y monitorear su tráfico de red sin cifrar.

Tengo una opinión sobre esto (y es solo una opinión).

"La única razón que se me ocurre es forzar a las computadoras de la red a confiar en sus propios certificados autofirmados en lugar de firmarlos digitalmente por un CA de terceros".

Si solo agrega una CA raíz, es poco probable que se vea el certificado autofirmado en el sentido tradicional, es un certificado firmado por una CA interna (aunque ese certificado de CA se firmará automáticamente). A menos que coloques ese mismo certificado en cada caja, sería una idea muy estúpida. Simplemente firme el certificado correcto con él y luego vuelva a bloquear la CA, lo que nunca le dará acceso a la red y solicitudes de firma de sneakernet cuando sea necesario.

Además, su preferencia (por mí) a un certificado comodín como compromiso de un host solo puede llevar a la intercepción de ese host (lo que probablemente haría de todos modos) en lugar de todo lo que hay en ese dominio.

Finalmente, una CA de terceros es para mí una línea de confianza innecesaria en una red interna. Puede controlar sus propias políticas internas pero no las suyas; por supuesto, si están corruptas / comprometidas, todavía pueden arruinarlo a menos que confíe SOLAMENTE en su propia AC.Así que tengo sentimientos encontrados sobre este punto.

Si protege ese certificado de CA lo suficiente, no es menos seguro que un tercero y, en mi opinión, es más seguro que un certificado comodín.