¿Cuál es la diferencia entre un certificado y una clave con respecto a SSL?

Cada vez que trato de entender algo sobre SSL, siempre me resulta difícil hacer un seguimiento de a qué se refieren "clave" y "certificado". Me temo que muchas personas los usan de manera incorrecta o intercambiable. ¿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 debe usar el certificado y otros tipos de metadatos.

Normalmente, un certificado está firmado por una autoridad de certificación (CA) utilizando la clave privada de CA. Esto verifica la autenticidad del certificado.

Estas dos imágenes juntas me explicaron todo:

Fuente: linuxvoice

Fuente: infosecinstitute

Digamos que la compañía 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).

• La empresa A debe presentar una solicitud de certificado (CR) a una autoridad de certificación (CA) para obtener un certificado para su par de claves.
  
• La clave pública, pero no la clave privada, del par de claves de la empresa A se incluye como parte de la solicitud de certificado.
  
• Luego, la CA usa la información de identidad de la compañía A para determinar si la solicitud cumple con los criterios de la CA para emitir un certificado.
  Si la CA aprueba la solicitud, emite un certificado a la compañía A. En resumen, CA firma la clave pública de la compañía A con su clave privada (la de CA), que verifica su autenticidad.
  

Por lo tanto, la clave pública de la empresa A firmada con una clave privada de CA válida se denomina certificado de la empresa A.

Dejame explicarte con un ejemplo.

En la PKI normal basada en pares de claves, hay clave privada y clave pública.

En un sistema basado en certificados, hay clave privada y 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 el archivo de clave privada y el archivo de certificado, verá que el archivo de certificado contiene mucha información como se muestra a continuación.

Puede hacer coincidir su certificado generado (abierto por un editor de texto) y la clave privada (abierto por un editor de texto) desde este sitio: https://www.sslshopper.com/certificate-key-matcher.html

Si el certificado coincide con la clave privada del cliente, el cliente está seguro de que el certificado lo otorga el cliente o el agente de confianza (CA) del cliente.

Sin embargo, solo hay problemas con la clave privada y la comunicación basada en certificados .

Porque cualquiera puede generar su propio certificado y clave privada, por lo que un simple apretón de manos no prueba 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 hacer que el cliente tenga un conjunto de uno o más certificados de confianza. Si el certificado no está en el conjunto, no se puede confiar en el servidor .

Hay varios inconvenientes en este enfoque simple. Los servidores deberían poder actualizarse a claves más seguras con el tiempo ("rotación de claves"), que reemplaza la clave pública en el certificado por una nueva. Desafortunadamente, ahora la aplicación cliente debe 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 abordar estas desventajas, los servidores generalmente se configuran con certificados de emisores conocidos llamados Autoridades de certificación (CA). La plataforma host (cliente) generalmente contiene una lista de CA bien conocidas en las que confía. Similar a un servidor, una CA tiene un certificado y una clave privada. Al emitir un certificado para un servidor, la CA firma el certificado del servidor utilizando su clave privada. El cliente puede verificar que el servidor tenga un certificado emitido por una CA conocida por la plataforma.

Sin embargo, al resolver algunos problemas, el uso de CA introduce otro. Debido a que la CA emite certificados para muchos servidores, aún necesita alguna forma de asegurarse de estar hablando con el servidor que desea. Para solucionar esto, el certificado emitido por la CA identifica al servidor con un nombre específico como gmail.com o un conjunto de hosts con comodín como * .google.com.

El siguiente ejemplo hará que estos conceptos sean un poco más concretos. En el fragmento de abajo de una línea de comando, el comando s_client de la herramienta openssl analiza la información del certificado del servidor de Wikipedia. Especifica el puerto 443 porque ese es el valor predeterminado para HTTPS. El comando envía la salida de openssl s_client a openssl x509, que formatea la información sobre los certificados de acuerdo con el estándar X.509. Específicamente, el comando solicita 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 RapidSSL CA.

Como puede ver, debido a esta información adicional enviada por CA a los servidores, el cliente puede saber fácilmente si se está comunicando con su servidor o no.

Se obtiene un certificado SSL de una Autoridad de Certificación de confianza, que garantiza la conexión segura del sitio web. Los certificados SSL generalmente contienen el logotipo de autenticación y también las claves públicas necesarias para cifrar y descifrar los datos que se enviarán a la computadora. Funciones de claves SSL

Se pueden generar varias claves SSL durante una sesión. Se utilizan para cifrar y descifrar la información que se envía desde y hacia la computadora. Las claves se utilizan para verificar que la información no se haya modificado ni alterado.

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 los bancos y las empresas pueden renovar regularmente. Las claves SSL o las claves de sesión, por otro lado, se generan de manera única durante la sesión y se descartan cuando finaliza la sesión.

Leer más aquí

Bien, analicemos esto para que las personas no técnicas puedan entender.

Piensa en esto, de esta manera. Un certificado es como una caja de seguridad en su banco. Contiene muchas cosas importantes; generalmente cosas que contienen tu identidad. El certificado tiene una clave pública y necesita una clave privada para abrirlo.

Su caja de seguridad también tiene dos llaves para abrir, como un certificado.
Con una caja de seguridad, la clave del banco es como la clave pública, ya que permanece en el banco y la clave pública permanece con el certificado. Usted tiene la clave privada, que es necesaria para "obtener su certificado" y, en el ejemplo de la caja de seguridad, también se necesita su clave privada además de la clave pública.

Antes de que pueda abrir su caja de seguridad, primero debe verificar su identidad (como una solicitud de certificado); una vez que haya sido identificado, use su clave privada junto con la clave pública para abrir su 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 que pueda ser identificado (confiable) y tenga la clave correcta).