What is the difference between a certificate and a key with respect to SSL?

Question

Whenever I try to understand anything about SSL I always have a hard time keeping track of what "key" and "certificate" refer to. I fear many people use them incorrectly or interchangeably. Is there a standard difference between a key and a certificate?

Solution 1

A certificate contains a public key.

The certificate, in addition to containing the public key, contains additional information such as issuer, what the certificate is supposed to be used for, and other types of metadata.

Typically, a certificate is itself signed by a certificate authority (CA) using CA's private key. This verifies the authenticity of the certificate.

Solution 2

These two pictures together explained everything to me:

Source: linuxvoice

Source: infosecinstitute

Solution 3

Lets say company A has a key pair and needs to publish his public key for public usage (aka ssl on his web site).

• Company A must make a certificate request (CR) to a certification authority (CA) to get a certificate for his key pair.
  
• The public key, but not the private key, of company A's key pair is included as part of the certificate request.
  
• The CA then uses company A's identity information to determine whether the request meets the CA's criteria for issuing a certificate.
  If the CA approves the request, it issues a certificate to company A. In brief CA signs company A's public key with his(CA's) private key, which verifies its authenticity.
  

So company A's public key signed with a valid CA's private key is called company A's certificate.

Solution 4

Let me explain with an example.

In normal key-pair based PKI, there are private key and public key.

In a certificate-based system, there are private key and certificate. Certificate holds more information than the public key.

Demo (You can generate a certificate and private key): http://www.selfsignedcertificate.com/

You can download open the private key file and certificate file, you see certificate file contains much information as shown below.

You can match your generated certificate (opening by a text editor), and private key (opening by a text editor) from this site: https://www.sslshopper.com/certificate-key-matcher.html

If the certificate matches client's private key, the client is sure, that certificate is given by the client or given by client's trusted agent (CA).

However, there are problems in only private key and certificate-based communication.

Because, anyone can generate their own certificate and private key, so a simple handshake doesn't prove anything about the server other than that the server knows the private key that matches the public key of the certificate. One way to solve this problem is to have the client have a set of one or more certificates it trusts. If the certificate is not in the set, the server is not to be trusted.

There are several downsides to this simple approach. Servers should be able to upgrade to stronger keys over time ("key rotation"), which replaces the public key in the certificate with a new one. Unfortunately, now the client app has to be updated due to what is essentially a server configuration change. This is especially problematic if the server is not under the app developer's control, for example, if it is a third party web service. This approach also has issues if the app has to talk to arbitrary servers such as a web browser or email app.

In order to address these downsides, servers are typically configured with certificates from well-known issuers called Certificate Authorities (CAs). he host-platform (client) generally contains a list of well known CAs that it trusts. Similar to a server, a CA has a certificate and a private key. When issuing a certificate for a server, the CA signs the server certificate using its private key. The client can then verify that the server has a certificate issued by a CA known to the platform.

However, while solving some problems, using CAs introduces another. Because the CA issues certificates for many servers, you still need some way to make sure you are talking to the server you want. To address this, the certificate issued by the CA identifies the server either with a specific name such as gmail.com or a wildcarded set of hosts such as *.google.com.

The following example will make these concepts a little more concrete. In the snippet below from a command line, the openssl tool's s_client command looks at Wikipedia's server certificate information. It specifies port 443 because that is the default for HTTPS. The command sends the output of openssl s_client to openssl x509, which formats information about certificates according to the X.509 standard. Specifically, the command asks for the subject, which contains the server name information, and the issuer, which identifies the 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

You can see that the certificate was issued for servers matching *.wikipedia.org by the RapidSSL CA.

As you can see, because of this additional information sent by CA to Servers, the client can easily know whether it is communicating with its server or not.

Solution 5

An SSL certificate is obtained from a trusted Certification Authority, which vouches for secure connection of the website . SSL certificates usually contain the logo of authentication and also the public keys necessary to encrypt and decrypt data that is to be sent to the computer. SSL Keys Functions

Several SSL keys can be generated during a session. They are used to encrypt and decrypt the information being sent to and from the computer.The keys are used to verify that the information has not been modified or tampered with.

Lifecycle Difference

Certificates last longer than SSL keys. SSL certificates are obtained from Certification Authority, which can be renewed regularly by banks and businesses. SSL keys or session keys, on the other hand, are uniquely generated during the session and discarded when the session ends.

Read more here

View more solutions

Comments

[Zoredache]

Certs used for SSL is heavily based on PKI en.wikipedia.org/wiki/Public-key_cryptography

[drs]

@Zoredache If a certificate typically only has a public key, is there a good name to call .p12 or .pfx files that contain certificates and private keys together?

[Zoredache]

A pkcs12 is an archive format. It may contain a key, or maybe not. I usally try to always be specific when refering about what a particular file contains, or just say pkcs12 file.

[CodyBugstein]

Where is this additional information buried? I was looking at some certificates and it's all gibberish to me

[Tola Odejayi]

Does Company A any point associate its (Company A's) private key with its (Company A's) certificate?

[Mohsen Heydari]

No. a private key remains privet for A.

[Timo]

<PiratesOfTheCarribean>So we're going after this key!</PiratesOfTheCarribean> (Read: You're not making any sense at all...)

[LawrenceC]

The gibberish you are looking at is Base64 encoding. It's done that way probably for a similar reason that email attachments are converted to that - basically to ensure they can transport through protocols and mechanisms designed for ASCII only without casual modification and without worrying about things like newlines, brackets, etc. The openssl command can decode and parse these or you can use an online utility such as this: lapo.it/asn1js

[Olshansk]

Is the certificate signed by a CA or the server being communicated with?

[LawrenceC]

Signed by CA. The server is configured with the certificate itself, which has the public key, and the private key which is not shared or part of the certificate, but it doesn't itself sign anything.

[sivann]

So where is the private key of company A used?

[Mohsen Heydari]

After above formalities. Company A will have a valid SSL certificate on his web site. Any visitor (browser) communicating the web site will use the certificate public key to encrypt his message. Company A having the private key of the SSL certificate is the only one who can decrypt the message.

[Marinos An]

Technically this means you can generate a keypair without a certificate. Later you can generate one or more certificates out of this keypair.

[SIGSTACKFAULT]

Relevant xkcd

[galaxis]

Nice. 1 clarification: the 1st pic is standard (1-way) TLS auth; the 2nd, mutual (2-way) auth. And 1 extra call-out in the 1st one would further help explain how the trust is actually established (all in that 1 friendlier-looking pic): after the client gets the server's public key cert, the client verifies that the CA that signed the server's cert is contained in the client's private list of trusted CAs (establishing that now it also trusts that CA). Then, it's safe to send the server the session key, w/ which each can now both encrypt and decrypt subsequent communications.

[DimiDak]

I guess company A is a male.

[Julien]

A digital certificate certifies the ownership of a public key by the named subject of the certificate. - from Wikipedia ;-)

[Tobb]

The first link, to linuxvoice.com/…, gives a certificate error. Ironic.

[Eugene]

around once in two years I have to deal with certificates... this answer, coupled with this video helps me refresh my understanding.

[David Spector]

I can't agree. It makes sense to me.

[Rony Tesler]

Why does the server also verifies the client's certificate using the CA?