¿Cómo verifica una CA RAÍZ una firma?


Por ejemplo, cuando se utiliza https, el navegador realiza una solicitud al servidor y el servidor devuelve su certificado, incluida la clave pública y la firma de CA.

En este punto, el navegador le pedirá a su CA que verifique si la clave pública dada realmente pertenece al servidor o no?

¿Cómo se realiza esta verificación por el cert Raíz en el navegador?

Para dar un ejemplo: Say serverX obtuvo un certificado de CA "RootCA". El navegador tiene una copia de RootCA almacenada localmente. Cuando el navegador pings serverX y responde con su clave pública + firma. Ahora la CA raíz utilizará su clave privada para descifrar la firma y asegurarse de que es realmente serverX?

¿Es así como funciona?

 25
Author: codeforester, 2009-02-26

4 answers

Su servidor tiene un certificado, que consiste en una clave privada y una pública. El servidor nunca entrega la clave privada, por supuesto, pero todos pueden obtener la clave pública. La clave pública está incrustada en un formato contenedor de certificado. Este formato contiene la dirección IP o el nombre de dominio del servidor, el propietario de esta dirección IP / nombre de dominio, una dirección de correo electrónico del propietario, etc.

Todo está firmado por una autoridad de confianza. La autoridad de confianza, también conocida como autoridad de certificación (CA) también tiene un par de claves privadas / públicas. Tú les das tu certificado, ellos verifican que la información en el contenedor es correcta y la firman por su clave privada, a la que solo ellos tienen acceso.

La clave pública de la CA está instalada en el sistema de usuario de forma predeterminada, la mayoría de las CA conocidas ya están incluidas en la instalación predeterminada de su sistema operativo o navegador favorito.

Cuando ahora un usuario se conecta a su servidor, su servidor utiliza la clave privada para firmar algunos datos, paquetes que firmaron datos junto con su clave pública y envía todo al cliente.

¿Qué puede hacer el cliente ahora? En primer lugar, puede usar la clave pública que acaba de enviar para verificar los datos firmados. Dado que solo el propietario de la clave privada es capaz de firmar los datos correctamente de tal manera que la clave pública puede verificar la firma, sabe que quien firmó este dato, esta persona es propietaria de la clave privada de la clave pública recibida. Hasta ahora muy bien. Pero lo que detiene a un hacker para interceptar el paquete, reemplazar los datos firmados con los datos que firmó usando un certificado diferente y también reemplazar la clave pública con su clave pública? Nada.

Es por eso que después de que se hayan verificado los datos firmados (o antes de que se verifiquen), el cliente verifica que la clave pública recibida tenga una firma de CA válida. Utilizando la clave de CA pública ya instalada, verifica que la clave pública recibida haya sido firmada por una CA conocida. De lo contrario, se rechaza (ya que un hacker puede haberlo reemplazado en el manera).

Por último, pero no menos importante, comprueba la información dentro del contenedor de clave pública. ¿La dirección IP o el nombre de dominio realmente coinciden con la dirección IP o el nombre de dominio del servidor con el que el cliente está hablando actualmente? Si no, algo es sospechoso!

La gente puede preguntar: ¿Qué impide a un hacker crear su propio par de claves y simplemente poner su nombre de dominio o dirección IP en el cert? Fácil: Si hace eso, ningún CA firmará su llave. Para obtener una firma de CA, debe demostrar que es realmente el propietario de esta dirección IP o nombre de dominio. El hacker no lo es, no puede probarlo, no obtendrá una firma. Así que esto no funcionará.

Bien, ¿qué pasa si el hacker registra su propio dominio, crea un certificado para eso y lo firma una CA? Esto funciona, hará que lo firmen, es su dominio, no hay problema. Sin embargo, no puede usar esto al hackear su conexión. Si utiliza este certificado, el navegador verá inmediatamente que la clave pública firmada es para dominio example.net, pero actualmente está hablando con example.com, no es el mismo dominio, por lo tanto algo es sospechoso de nuevo.

 58
Author: Mecki,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-07-25 13:48:00

El certificado del servidor está firmado con la clave privada de la CA. El navegador utiliza la clave pública de la CA para verificar la firma. No hay comunicación directa entre el navegador y CA.

El punto importante es que el navegador se envía con la clave de CA pública. En Firefox ver Herramientas- > Opciones - > Avanzado - > Cifrado - >ViewCertificates - > Autoridades. Así que el navegador sabe de antemano todas las CAS en las que puede confiar.

Si no entiendes esto, busca los conceptos básicos de Asymmetric Criptografía y Firmas Digitales.

 7
Author: user34005,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-26 08:28:09

Los certificados se basan en el uso de un cifrado asimétrico como RSA. Tienes dos claves, convencionalmente llamadas las claves privadas y públicas. Algo que encripta con la clave privada solo se puede descifrar usando la clave pública. (Y, en realidad, viceversa.)

Puedes pensar en el cert como si fuera un pasaporte o una licencia de conducir: es una credencial que dice "esto es lo que soy; puedes confiar en él porque me lo dio alguien (como Verisign) en quien confías."Esto se hace con un "firma", que se puede calcular utilizando la clave pública de la autoridad de certificación. Si los datos son los que obtuvo originalmente la CA, puede verificar el certificado.

El cert contiene información de identificación sobre el propietario del cert. Cuando lo recibe, utiliza la combinación de la clave que conoce de su autoridad de confianza para confirmar que el certificado que recibió es válido y que, por lo tanto, puede inferir que confía en la persona que emitió el certificado.

 2
Author: Charlie Martin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-26 08:26:47

Su navegador no le pide a la CA que verifique, sino que tiene una copia de los certificados raíz almacenados localmente, y utilizará el procedimiento criptográfico estándar para verificar que el certificado realmente es válido.

Esta es la razón por la que cuando uno mismo firma un certificado, su certificado no es válido, aunque técnicamente hay una CA para preguntar, podría copiar la CA auto firmada a su computadora y a partir de entonces confiaría en sus certificaciones auto firmadas.

CACert.org tiene este mismo problema, tiene certificados válidos, pero como los navegadores no tienen sus certificados raíz en su lista, sus certificados generan advertencias hasta que los usuarios descargan las CA raíz y las agregan a su navegador.

 0
Author: X-Istence,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-26 08:19:03