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

127

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?

drs
fuente
Los certificados utilizados para SSL se basan en gran medida en PKI en.wikipedia.org/wiki/Public-key_cryptography
Zoredache

Respuestas:

115

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.

LawrenceC
fuente
44
@Zoredache Si un certificado generalmente solo tiene una clave pública, ¿hay un buen nombre para llamar a los archivos .p12 o .pfx que contienen certificados y claves privadas juntas?
Dres
Un pkcs12 es un formato de archivo. Puede contener una clave, o tal vez no. Normalmente trato de ser siempre específico al referirme a lo que contiene un archivo en particular, o simplemente decir pkcs12 file.
Zoredache
2
¿Dónde está enterrada esta información adicional? Estaba buscando en algunos certificados y es todo un galimatías para mí
CodyBugstein
3
El galimatías que estás viendo es la codificación Base64. Se hace de esa manera, probablemente por una razón similar por la cual los archivos adjuntos de correo electrónico se convierten a eso, básicamente para garantizar que puedan transportarse a través de protocolos y mecanismos diseñados para ASCII solo sin modificación casual y sin preocuparse por cosas como líneas nuevas, corchetes, etc. El opensslcomando puede decodificar y analizar estos o puede utilizar una utilidad en línea como esta: lapo.it/asn1js
LawrenceC
¿El certificado está firmado por una CA o el servidor con el que se está comunicando?
Olshansk
58

Estas dos imágenes juntas me explicaron todo:

Fuente: linuxvoice

ingrese la descripción de la imagen aquí

Fuente: infosecinstitute

ingrese la descripción de la imagen aquí

Andrejs
fuente
1
Relevante xkcd
SIGSTACKFAULT
Agradable. 1 aclaración: la primera foto es la autenticación TLS estándar (1 vía); La segunda, mutua (2 vías) autenticación. Y 1 llamada adicional en el primero ayudaría a explicar cómo se establece realmente la confianza (todo en esa 1 imagen de aspecto más amigable): después de que el cliente obtiene el certificado de clave pública del servidor, el cliente verifica que la CA que firmó el El certificado del servidor está contenido en la lista privada de CA de confianza del cliente (estableciendo que ahora también confía en esa CA). Entonces, es seguro enviar al servidor la clave de sesión, con la cual cada uno puede cifrar y descifrar comunicaciones posteriores.
user1172173
El primer enlace, a linuxvoice.com/… , muestra un error de certificado. Irónico.
Tobb
37

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.

Mohsen Heydari
fuente
¿La Compañía A en algún momento asocia su clave privada (Compañía A) con su certificado (Compañía A)?
Tola Odejayi
No. Una clave privada sigue siendo privada para A.
Mohsen Heydari
Entonces, ¿dónde se utiliza la clave privada de la empresa A?
sivann
2
Después de los trámites anteriores. La empresa A tendrá un certificado SSL válido en su sitio web. Cualquier visitante (navegador) que comunique el sitio web utilizará la clave pública del certificado para cifrar su mensaje. La empresa A que tiene la clave privada del certificado SSL es la única que puede descifrar el mensaje.
Mohsen Heydari
Supongo que la compañía A es un hombre.
DimiDak
5

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. ingrese la descripción de la imagen aquí ingrese la descripción de la imagen aquí

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.

Uddhav Gautam
fuente
3

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í

Shekhar
fuente
2

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).

lwood
fuente
3
<PiratesOfTheCarribean> ¡Entonces buscamos esta clave! </PiratesOfTheCarribean> (Leer: No tiene ningún sentido ...)
Timo