If you're seeing this message, it means we're having trouble loading external resources on our website.

Si estás detrás de un filtro de páginas web, por favor asegúrate de que los dominios *.kastatic.org y *.kasandbox.org estén desbloqueados.

Contenido principal

Certificados digitales

El protocolo TLS se basa en cifrado de llave pública. La computadora remitente usa la clave pública de la computadora receptora cuando cifra datos. Sin embargo, antes que suceda eso, TLS requiere un paso que es crucial para su seguridad: el remitente debe verificar la identidad detrás de la llave pública.
Un certificado digital, también conocido como certificado de llave pública o certificado de identidad, prueba la propiedad de una llave de cifrado.

La necesidad de certificados

¿Qué pasaría si TLS no incluyera un paso de verificación de certificado?
Los atacantes han encontrado maneras de interceptar una solicitud de una computadora a otra en Internet, como por ejemplo a través de puntos de acceso deshonestos.
Desde aquí pueden lanzar un ataque de "hombre en medio" (MITM). Aunque se llama "hombre" en el ataque, los atacantes son de todas las edades y géneros. También puedes pensar en ello como un "enmascarado en medio".
Primero, durante el proceso de establecer una conexión segura con TLS, un atacante envía al cliente su propia clave pública en lugar de la clave pública del servidor.
Ilustración de interceptación activa de un paquete TLS sobre un punto de acceso deshonesto. Hay un servidor a la izquierda y una computadora portátil etiquetada como "Cliente" a la derecha. La parte superior está etiquetada "Lo que el cliente piensa que sucede". Contiene una flecha etiquetada con una clave de cifrado verde que va del servidor a un punto de acceso etiquetado como "punto de acceso legítimo". Otra flecha etiquetada de la misma manera va desde el punto de acceso legítimo al cliente. La parte inferior está etiquetada como "Lo que sucede en realidad". Contiene una flecha etiquetada con una llave verde que va desde el servidor a un atacante etiquetado "punto de acceso deshonesto". Otra flecha etiquetada con una llave roja va desde el punto de acceso deshonesto al cliente.
Después de eso, cada vez que el cliente cifra datos con la llave pública recibida, en su lugar cifra datos con la clave pública del atacante. El atacante puede descifrar el mensaje cifrado, cambiarlo a su gusto y cifrarlo de nuevo con la clave pública del servidor antes de enviar los datos al servidor.
Ilustración de interceptación activa sobre un punto de acceso deshonesto. A la izquierda, una computadora portátil tiene abierto un sitio web con un campo de contraseña lleno. Hay un servidor a la derecha. El área de arriba está etiquetada como "Lo que el cliente piensa que sucede" y contiene una flecha marcada como "# de cuenta: 25" que va de la portátil a un punto de acceso etiquetado como "punto de acceso legítimo". Otra flecha etiquetada con los mismos datos va desde el punto de acceso legítimo al servidor. El área inferior está etiquetada como "Lo que realmente sucede" y contiene una flecha etiquetada como "Id de cuenta: 25" que va desde la portátil a un atacante etiquetado "punto de acceso deshonesto". Otra flecha etiquetada con "Id de cuenta: 12" va desde el punto de acceso deshonesto al servidor.
Para prevenir un ataque de MiTM, el cliente necesita verificar la identidad detrás de una llave pública. Un certificado digital muestra la identidad detrás de una llave pública. Sin embargo, si cualquiera puede crearla, ¿cómo puede un cliente confiar en la legitimidad de un certificado digital? En TLS, los clientes confían en un certificado digital si fue generado por instituciones conocidas como autoridades de certificación.

Autoridades de certificación

Un servidor que quiere comunicarse de manera segura sobre TLS se registra con una autoridad de certificación. La autoridad verifica su propiedad del dominio, firma el certificado con su propio nombre y llave pública, y envía el certificado firmado de vuelta al servidor.
Un modelo de certificado que se asemeja a los certificados entregados a personas que ganan premios. La parte de arriba dice "Certificado de Autenticidad". Debajo de ello, dice "Esto reconoce que khanacademy.org es el orgulloso propietario de esta clave pública:" y luego tiene una larga cadena hexadecimal. En la parte inferior, una línea para la firma está etiquetada como "Autoridad de Certificación" y tiene la firma "Autoridad de Certificación GoDaddy. Otra línea está etiquetada como "Fechas de validez" y tiene "10/13/2018 - 11/18/2020".
Cuando el cliente inspecciona el certificado, puede ver que una autoridad de certificación da fe de la autenticidad de la llave pública. Pero todavía tiene una decisión que tomar: ¿confía en esa autoridad de certificación?
Los clientes generalmente tienen incluidos una lista de autoridades de certificación confiables. Por ejemplo, un iPhone Apple con iOS 10 confía en esta lista de autoridades de certificación.
Los usuarios de Apple deben entonces confiar que Apple va a monitorear continuamente la lista, para asegurar que cada autoridad de certificación verifica dominios correctamente.
Puedes imaginar una cadena de confianza del usuario al servidor:
Una ilustración de la cadena de certificación de confianza. Inicia con un icono etiquetado como "usuario" a la izquierda. Una flecha etiquetada como "confianza" del icono del usuario a un icono de un celular etiquetado como "cliente" . Otra flecha etiquetada como "confianza" fluye del icono del cliente a un icono de una computadora etiquetada "autoridad de certificación". Una flecha final fluye del icono de autoridad de certificación a un icono de una computadora etiquetada como "servidor".
En cada punto, la confianza puede romperse. Si el usuario no confía en el cliente, puede cambiar la lista por defecto de autoridades de certificación de confianza del cliente . Si un cliente ya no confía en una autoridad de certificación, la eliminará de la lista. Si una autoridad de certificación ve un comportamiento sospechoso desde un servidor, puede revocar su certificado.

Autoridades intermedias de certificación

En realidad hay varios niveles de autoridades de certificación: la autoridad de certificación raíz y la autoridad de certificación intermedia.
La CA (autoridad de certificación) raíz no emite directamente ningún certificado digital para los servidores. Sólo emite certificados digitales para CAs intermedias que actúen en su nombre. Las CAs intermedias pueden o emitir certificados digitales para otra CA intermedia o directamente para un servidor.
Por lo tanto, hay otra cadena de confianza, desde la CA raíz hasta el servidor:
Una ilustración de la cadena de confianza de autoridades de certificación. Comienza con un icono de servidor etiquetado como "CA Raiz" a la izquierda. Hay una flecha etiquetada como "confianza" de ese icono a otro icono de servidor etiquetado "CA Intermedia" . Otra flecha etiquetada como "confianza" fluye de ese icono a otro icono de servidor etiquetado como "CA Intermedia". Una flecha final fluye de ese icono a un icono de servidor etiquetado como "Servidor".
Las capas de autoridades de certificación aumentan la seguridad del sistema. Si una CA raíz descubre que una CA intermedia ha sido comprometida por un atacante, invalida los certificados de esa CA, pero sigue confiando en los certificados de sus otras CA intermedias.
🔍 Puedes ver la cadena por ti mismo cuando revisas el certificado de un sitio web seguro en el navegador. Si haces clic en el candado junto a la URL, el navegador debe ofrecerte una forma de inspeccionar los certificados.
Captura de pantalla de los certificados emitidos para el sitio web de Khan Academy. Muestra una lista anidada con "GlobalSign Root CA" en la parte superior, luego "GlobalSign CloudSSL CA", luego "khan.map.fastly.net".
La cadena de confianza para KhanAcademy.org incluye una CA intermedia.

🙋🏽🙋🏻‍♀️🙋🏿‍♂️¿Tienes alguna pregunta sobre este tópico? Nos encantaría contestarte; ¡simplemente pregunta en el área de preguntas abajo!

¿Quieres unirte a la conversación?

¿Sabes inglés? Haz clic aquí para ver más discusiones en el sitio en inglés de Khan Academy.