Cada vez que intento entender algo sobre SSL siempre me resulta difícil saber a qué se refieren “clave” y “certificado”. Me temo que mucha gente los utiliza de forma incorrecta o indistinta. ¿Existe una diferencia estándar entre una clave y un certificado?
Un certificado contiene una clave pública.
El certificado, además de contener la clave pública, contiene información adicional como el emisor, para qué se supone que se utiliza el certificado y otros tipos de metadatos.
Normalmente, un certificado está firmado por una autoridad de certificación (CA) utilizando la clave privada de la CA. Esto verifica la autenticidad del certificado.
Estas dos imágenes juntas me lo explicaron todo:
Fuente: linuxvoice
Fuente: infosecinstitute
Supongamos que la empresa A tiene un par de claves y necesita publicar su clave pública para uso público (también conocido como ssl en su sitio web).
Así, la clave pública de la empresa A firmada con una clave privada válida de la CA se denomina certificado de la empresa A.
Permítanme explicarlo con un ejemplo.
En una PKI normal basada en un par de claves, hay una clave privada y una clave pública.
En un sistema basado en certificados, hay una clave privada y un certificado. El certificado contiene más información que la clave pública.
Demostración (Puede generar un certificado y una clave privada): http://www.selfsignedcertificate.com/
Puede descargar abrir el archivo de la clave privada y el archivo del certificado, verá que el archivo del certificado contiene mucha información como se muestra a continuación.
Usted puede coincidir con su certificado generado (abrir por un editor de texto), y la clave privada (abrir por un editor de texto) de este sitio: https://www.sslshopper.com/certificate-key-matcher.html
Si el certificado coincide con la clave privada del cliente, el cliente está seguro, que el certificado es dado por el cliente o dado por el agente de confianza del cliente (CA).
Sin embargo, hay problemas en la comunicación basada sólo en la clave privada y en el certificado.
Porque, cualquiera puede generar su propio certificado y clave privada, por lo que un simple apretón de manos no demuestra nada sobre el servidor, aparte de que el servidor conoce la clave privada que coincide con la clave pública del certificado. Una forma de resolver este problema es que el cliente tenga un conjunto de uno o más certificados en los que confía. Si el certificado no está en el conjunto, el servidor no es de confianza.
Este sencillo enfoque tiene varias desventajas. Los servidores deberían poder actualizarse a claves más fuertes con el tiempo (“rotación de claves”), lo que sustituye la clave pública del certificado por una nueva. Lamentablemente, ahora la aplicación cliente tiene que actualizarse debido a lo que es esencialmente un cambio de configuración del servidor. Esto es especialmente problemático si el servidor no está bajo el control del desarrollador de la aplicación, por ejemplo, si es un servicio web de terceros. Este enfoque también tiene problemas si la aplicación tiene que hablar con servidores arbitrarios como un navegador web o una aplicación de correo electrónico.
Para solucionar estos inconvenientes, los servidores suelen estar configurados con certificados de emisores conocidos llamados Autoridades de Certificación (CA). a plataforma anfitriona (cliente) suele tener una lista de CAs conocidas en las que confía. Al igual que un servidor, una CA tiene un certificado y una clave privada. Cuando emite un certificado para un servidor, la CA firma el certificado del servidor utilizando su clave privada. El cliente puede entonces verificar que el servidor tiene un certificado emitido por una CA conocida por la plataforma.
Sin embargo, aunque resuelve algunos problemas, el uso de CAs introduce otro. Dado que la CA emite certificados para muchos servidores, todavía se necesita alguna forma de asegurarse de que se está hablando con el servidor que se desea. Para solucionar esto, el certificado emitido por la CA identifica el servidor con un nombre específico como gmail.com o un conjunto de hosts con comodines como *.google.com.
El siguiente ejemplo concretará un poco más estos conceptos. En el siguiente fragmento de una línea de comandos, el comando s\client de la herramienta openssl busca la información del certificado del servidor de Wikipedia. Especifica el puerto 443 porque es el predeterminado para HTTPS. El comando envía la salida de openssl s_client a openssl x509, que formatea la información sobre los certificados según el estándar X.509. Específicamente, el comando pide el asunto, que contiene la información del nombre del servidor, y el emisor, que identifica la CA.
$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
Puede ver que el certificado fue emitido para servidores que coinciden con *.wikipedia.org por la CA RapidSSL.
Como puede ver, gracias a esta información adicional enviada por la CA a los servidores, el cliente puede saber fácilmente si se está comunicando con su servidor o no.
Un certificado SSL se obtiene de una Autoridad de Certificación de confianza, que avala la conexión segura del sitio web . Los certificados SSL suelen contener el logotipo de autenticación y también las claves públicas necesarias para cifrar y descifrar los datos que se van a enviar al ordenador. Funciones de las claves SSL
Durante una sesión se pueden generar varias claves SSL. Se utilizan para cifrar y descifrar la información que se envía desde y hacia el ordenador.Las claves se utilizan para verificar que la información no ha sido modificada o manipulada.
Diferencia del ciclo de vida
Los certificados duran más que las claves SSL. Los certificados SSL se obtienen de la Autoridad de Certificación, que puede ser renovada regularmente por los bancos y las empresas. Las claves SSL o claves de sesión, en cambio, se generan de forma única durante la sesión y se descartan cuando ésta finaliza. Lea más aquí
Bien, vamos a desglosar esto para que los no técnicos puedan entenderlo.
Piénsalo así. Un certificado es como una caja de seguridad en tu banco. Contiene un montón de cosas importantes; generalmente cosas que contienen tu identidad. El certificado tiene una clave pública y necesita una clave privada para abrirlo.
Tu caja de seguridad también necesita dos llaves para abrirse, igual que un certificado.
Con una caja de seguridad, la llave del banco es como la clave pública, ya que se queda en el banco y la clave pública se queda con el certificado. Tú tienes la clave privada, que es necesaria para “obtener tu certificado” y en el ejemplo de la caja de seguridad, tu clave privada es necesaria además de la clave pública.
Antes de que puedas abrir realmente tu caja de seguridad, primero debes verificar tu identidad (algo así como una solicitud de certificado); una vez que te han identificado, utilizas tu clave privada junto con la clave pública para abrir tu caja de seguridad. Esto es un poco como hacer su solicitud de certificado, y luego obtener su certificado de la autoridad de certificación (siempre y cuando usted puede ser identificado (de confianza) y usted tiene la clave correcta).