Hola, ¿qué tal? Bienvenida o bienvenido a entrenamiento de Aruba Network Escentials. Mi nombre es Ricardo Cobos, y en este video profundizaré en certificados digitales, especÃficamente, hablaré del Chain of Trust o la cadena de confianza y también de cómo es que los dispositivos validan los certificados digitales que reciben, utilizando la llave pública de la autoridad que los firmó. Retomando un poco los temas que ya platicamos, nosotros sabemos que los certificados digitales contienen información del dispositivo que es dueño de ese certificado digital, pero también contiene información sobre la validez del certificado, quién lo generó y también la llave pública del dueño de ese certificado. De esa manera es que esa llave pública nosotros la podemos utilizar para cifrar información haciendo túneles unidireccionales. Sin embargo, es importante entender que la validación de ese certificado lleva varios pasos, por ejemplo, en este caso nosotros sabemos que este servidor tiene un certificado digital que fue firmado por el Issuing CA, que, a su vez, tiene un certificado firmado por el Intermediate y que al final también tiene un certificado digital firmado por el Root CA. En este caso, entendiendo esto como contexto, cuando el servidor envÃa su certificado digital al usuario, dado que, posiblemente este usuario está accediendo a algún servicio que requiere autenticación con certificados digitales, cuando el usuario se conecta con el servidor y este envÃa su certificado, vamos a colocarlo aquÃ, este envÃa su certificado digital, lo que ocurre es que el usuario tiene que validar ese certificado y la manera en la que lo va a validar es revisando que está firmado por una autoridad confianza, entonces, ese usuario va a validar que el certificado que el servidor está enviando fue firmado por el Issuing CA, pero, a su vez, el usuario tiene que tener certeza de que el certificado digital de Issuing CA fue, a su vez, firmado por una autoridad de confianza. Es por eso que ahora el usuario va a validar el certificado de Issuing CA con el Intermediate y, posteriormente, también tiene que validar que el certificado, el Intermediate, fue firmado por una autoridad de confianza, en este caso, la raÃz. Y al final del dÃa, el usuario, para que todo eso funcione, lo que requiere es el certificado digital, por lo menos, el certificado digital del Root CA, instalado en su base de datos. Este certificado digital, tiene que estar guardado en algo que nosotros llamamos "Trust Store", en el sistema operativo del equipo de cómputo de este usuario. Es de esta manera, cómo realmente el usuario podrÃa validar, tanto en certificado del servidor como del Issuing CA, como del Intermediate CA, y del Root CA. Dado que todo esto es lo que se conoce como Chain of Trust o la cadena de confianza, es prácticamente, una dependencia de confianza de el certificado que el cliente recibe sobre otro certificado de la autoridad que lo firmó. Y ese, a su vez, de otro certificado que lo firmó, asà sucesivamente, hasta llegar a la autoridad raÃz, la cual es implÃcitamente de confianza para el usuario, porque este certificado ya está configurado o instalado en su equipo. Vamos a ver esto más a detalle. En este slide que tenemos aquÃ, tenemos a Alice y Bob queriendo establecer una comunicación, pero antes quieren validar su identidad y, del mismo modo, quieren también asegurar o generar una conexión segura. Lo que sucede es que Alice, primero envÃa su certificado digital, en este caso, y es importante entender como Alice es quien envÃa el certificado digital, entonces, Bob es quien tiene que validar su autenticidad. Una vez que explique este proceso, se debe asumir que después Bob va a hacer lo mismo, Bob va a enviar su certificado digital y Alice tendrá que validar. Sin embargo, esta segunda parte no lo voy a explicar, se va a asumir. Luego, volvamos al inicio, Alice envÃa su certificado digital, Aquà tenemos el Alice's cert y, opcionalmente, también podrÃa enviar el certificado digital de la autoridad que lo firmó, el Intermediate. En este caso, aparentemente, nada más, tenemos una PKI, una "publique key infrastructure", con dos niveles de su jerarquÃa, que serÃa el Root CA, Intermediate y, al final, lo que tenemos son los certificados de los usuarios. Entonces, Alice envÃa su certificado digital y el certificado del Intermediate. Aquà se asume que Bob ya conoce o confÃa en la autoridad raÃz, o sea, el certificado digital de la autoridad raÃz ya está instalado en el Trust Store del equipo de cómputo de Bob. En este caso, lo que Bob hará es comenzar a analizar el certificado de Alice. En el paso número uno, se va a asegurar que, efectivamente, el certificado que recibe es de Alice y después verá quién es quién lo firmó. Realmente aquÃ, Bob tendrá que hacer toda esta revisión. Él va a verificar si, efectivamente, es un certificado de Alice y, por cierto, fue firmado por una autoridad intermediaria, y esa autoridad intermediaria agregó su firma aquÃ. Recuerden que la firma no es otra cosa más que el hash de todo el certificado digital cifrado con la llave privada de la Intermediate CA, en este caso. Entonces, cuando ella sabe quién es el Intermediate CA, lo que Bob quiere hacer es validar esta firma. Luego, entonces, va a utilizar el certificado digital del Intermediate CA, que está recibiendo también por parte de Alice, y lo que revisará es que Issuer name, del certificado de Alice, hace match con el subject name del certificado digital, de la autoridad intermediaria y, efectivamente, hace match. Con esto, lo que Bob hará es buscar la llave pública de este certificado y con esta llave pública procederá a tomar la firma del certificado de Alice y descifrará esa firma, lo que lo va a llevar al hash del certificado de Alice. En otras palabras, si nosotros lo vemos desde otro punto de vista, cuando Bob recibe el certificado de Alice, él observa la firma, observa quién lo firmó, el Intermediate CA, y entonces, sustrae la llave pública del Intermediate CA y realiza el proceso de descifrado de esta firma, lo cual tenemos aquÃ, y como resultado, lo que se obtiene es el hash del certificado digital de Alice. Después, el equipo de Bob tomará el certificado de Alice y también obtendrá su hash, y si el resultado que él obtiene haciendo hash de ese certificado, junto con el valor obtenido después de descifrar la firma, si estos dos valores coinciden, entonces, efectivamente, ese certificado le pertenece a Alice y fue firmado por este Intermediate CA. Sin embargo, aquà tenemos un detalle; Bob tiene que también validar que este certificado, el Intermediate CA, fue firmado por alguna autoridad en la cual él confÃa. Y sucede que quien firmó ese certificado es el Root CA, del cual él ya tiene un certificado. Entonces, ahora él podrÃa realizar una segunda validación que tenemos a continuación, donde... Al observar el "Intermediate CA", él puede ver que fue firmado por el "Root CA". Por consecuencia, aquà tenemos el certificado de ese "Root CA" y Bob utilizará la llave pública del "Root CA" para descifrar la firma del certificado de la autoridad "Intermediate". En otras palabras, tomará la llave pública del certificado digital de aquel que firmó el certificado del "Intermediate CA", hará el proceso de descifrado y obtendrá un "hash". Después, Bob tomará todo el certificado y aplicará un "hash" de manera paralela. Y si estos dos valores coinciden, entonces, lo que podemos concluir es que Bob confÃa en el certificado de este "Intermediate CA" porque fue firmado por una autoridad en la cual ya él confÃa; y, a su vez, podemos asumir que Bob puede confiar en el certificado de Alice y, con eso, concluir que le pertenece a ella, porque este certificado digital fue firmado por una autoridad en la cual también ya él confÃa. Básicamente, este "Trust Chain" o "Chain of Trust" requiere una validación continua y recursiva de los certificados. Una vez más, el usuario va a validar el certificado que recibe utilizando la llave pública de la autoridad que lo firmó y, para saber que podemos utilizar o confiar en esa llave pública, ese usuario también tiene que tener certeza que el certificado de esa autoridad fue, a su vez, firmado por otra autoridad en la cual él ya confÃa y para asegurarnos que esa autoridad es de confianza, también, se tiene que validar que fue firmado, a su vez, por la autoridad raÃz. Aunque en este ejemplo, con Alice y Bob, solamente utilizamos dos niveles en la jerarquÃa en la autoridad raÃz, el "Intermediate" y luego, al final, el certificado del usuario, la realidad de las cosas, es que esto podrÃa tener hasta los tres niveles de jerarquÃa como la topologÃa que te mostré hace un minuto. Ahora, como punto importante, es saber dónde se instalan los certificados digitales de las autoridades de confianza en los equipos de cómputo de los usuarios. En el caso de Windows, existe una consola de gestión que se llama "Certificate Manager" y esta es utilizada para poder gestionar los certificados digitales que están instalados en el sistema operativo. Y aquà vemos que hay varios "folders" y que, además, se separan por usuario. Con el usuario actual que está logueado en la sesión de Windows podemos ver que hay varios directorios, pero hay uno llamado "Trusted Root Certificate Authorities" y, después, hay otro que se llama "Certificados" o "Certificates". AhÃ, en esa parte, es donde se encuentran todos los certificados de las autoridades en las cuales este dispositivo confÃa. Tú puedes agregar certificados ahà manualmente o pueden ser distribuidos a través de polÃticas de "Active Directory" si este equipo Windows perteneciera a algún dominio de "Active Directory", a algún dominio de AD. Siempre y cuando el usuario reciba certificados digitales que fueron firmados por estas autoridades certificadoras o por autoridades intermediarias que obtuvieron, a su vez, sus certificados de estas CA, entonces, el cliente podrá confiar en el certificado digital que recibe. En el caso de la infraestructura de Aruba, los certificados digitales en los "Mobility Controllers" y "Mobility Conductors" se instalan en el "Trusted CA Certificate"; en el caso de los switches, se instalan en el "Trust Anchor Profile". Muy bien. ¿Qué otros parámetros debemos validar cuando se reciben certificados digitales o qué otros aspectos el equipo de cómputo valida? Como ya sabemos, tiene que validar que fue firmado por una autoridad de confianza. También tiene que validar que esos certificados no han expirado. Es por eso que tener un valor de reloj preciso es importante en los equipos de cómputo y en los equipos de infraestructura de red como un todo. También se tiene que validar que los certificados no hayan sido revocados. Esto sucede si la llave privada de algún certificado que tenga que ver con el "Trust Chain" de confianza ha sido comprometida; si alguna llave privada ha sido comprometida o la autoridad, como un todo, fue comprometida o el cliente tiene un certificado digital que fue comprometido, ese certificado se colocará en algo llamado "Certificate Revokation List", los cuales son creados por las autoridades certificadoras y, básicamente, lo que nos dice es que si el certificado digital que el cliente tuviera que validar, ya sea el de algún servidor o el de alguna autoridad intermedia, termina estando en esta lista, entonces, se asume que ha sido comprometido y que no se puede confiar en él. También, es importante saber que el certificado se puede utilizar para lo que se está proponiendo, porque hay certificados digitales para validar la identidad de usuarios, para validar la identidad de servidores, para firmar código o para firmar otros certificados. El certificado que se está recibiendo debe decir especÃficamente cuál es el uso válido y nosotros tenemos que compararlo con el motivo por el cual lo estamos recibiendo y si hace "match", se puede confiar en él. Si no hace "match", debemos ignorar esa conexión. Y, finalmente, los certificados digitales tienen algo llamado como "Name" y "Subject Alternative Name", que es el "Fully Qualified Domain Name" o el nombre de dominio junto con el nombre de servidor al cual le pertenece ese certificado; es el "Subject". En ese caso, si nosotros estamos realizando una conexión con algún servidor, vamos a precisar la página de tu banco y en el URL tú escribes "mibancopuntocom". Esperamos que el certificado digital que nosotros recibamos tenga en el "Common Name" o en el "Subject Alternative Name" la misma cadena de caracteres, "mibancopuntocom". De esa manera, yo puedo tener certeza de que el certificado digital que estoy recibiendo es realmente enviado por aquel dispositivo con el cual yo inicialmente me querÃa conectar. Si yo llegara a escribir en la URL del navegador "mibancopuntocom", pero recibo un certificado digital con un "Subject Alternative Name" o con un "Common Name" muy raro que, realmente, no hace "match" con eso, algo asà como "sitiosospechosopuntocom" o algo tal vez no tan evidente, sino, "mibancoo", con doble o, "puntocom", entonces, yo ya puedo tener certeza de que alguien acaba de redireccionar mi conexión y me está intentando inyectar un certificado que no pertenece al servidor al cual originalmente me querÃa conectar. En ese caso, recibiré un "warning" de este tipo que dice "Tu conexión no es privada". Por ejemplo, la firma es válida, el perÃodo es válido y otros criterios son válidos, sin embargo, el "Subject Alternative Name", en otras palabras, la identidad, que se está incluyendo en el certificado, no es precisamente el dominio o la URL del banco o del sitio al cual yo me querÃa conectar. En ese caso, no hay más remedio que cerrar la PC o el navegador, porque, como ya comenté, fuimos redirigidos y posiblemente están queriendo realizar un "Man-in-the-middle-attack". Con esto doy por terminado el video. Espero que lo hayas disfrutado. Te veo en el siguiente.
