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?

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

Answer 2

These two pictures together explained everything to me:

Source: linuxvoice

Source: infosecinstitute

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

Answer 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): https://getacert.com/index.html

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.

Answer 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

Answer 6

OK, let's break this down so that non technical people can understand.

Think of it like this. A Certificate is like a safety deposit box at your bank. It contains a lot of important stuff; generally stuff that contains your identity. The certificate has a public key and needs a private key to open it.

Your safety deposit box takes two keys to open too, just like a certificate.
With a safety deposit box, the banker's key is like the public key since it stays at the bank and the public key stays with the certificate. You have the private key, which is needed to "get your certificate" and in the example of the safety deposit box, your private key is needed in addition to the public key as well.

Before you can actually open your safety deposit box, you must first verify your identity (kind of like a certificate request); once you have been identified, you use your private key along with the public key to open your safety box. This is a bit like making your certificate request, and then getting your certificate from the certification authority (as long as you can be identified (trusted) and you have the right key).

Answer 7

The whole subject area is bamboozling. Several reasons for this:

1. Lack of understanding of what an RSA key is. Most examples start with creating a private key. You end up wondering, "So, where is the public key?" Read this post on the Security SE site.

2. Next, is all the PEM, JKS, PCKS12 etc. Would drive anyone mental understanding what the heck these are and how they are interchanged? They are different formats for storing keys and certificates. Don't stress. Have a beer and relax now.

   Okay… Download an ancient tool called: portecle its French for door key. Its a Java app and a Swing UI which is from the ice age… But it works and allows you to look inside different types of files, and to also use it to change JKS files to other formats and vice versa (but not all… See later)

3. Next, the next thing that is going to really drive you mental, is that portecle does not for example open a PEM file containing a cert or key or both. So, you start banging your head against the desk, you squeeze the hamster just a little too much, and then you discover: openssl and you wonder where the heck to get that from… Well, download Git, and make sure you get the console that comes with it:

   

   Right. Now you have access to openssl. Meanwhile you have aged a few years. The latter command comes with gitbash. It allows you to look at a PEM file internals… God help you with that one too… Because the verbosity is just mind blowing. Instead just use cat [yourfilenamehere].pem to look at the internals of a file, later lookup openssl commands.

4. Now, you have to understand the difference between a key and a certificate, for that you can look at this diagram:

   

   You now understand why a key is just a key (part of a cypher key pair) and encoded in base64, and why a certificate is what it is (oh before I forget, -des3 is an encryption switch for creating a key… There is about a zillion of them too… Hahahaha… Take a Tylenol…)

5. Good. Finally, take this brilliant example, and write a localhost integration test, to try it all out for yourself: https://www.section.io/engineering-education/how-to-get-ssl-https-for-localhost/

6. It has taken me, from scratch on and off about 10 days to try to wrap my brain around it all. Don't forget, you can sign a certificate with a private key. That is what a CA is for. Anyway, enough of my vernacular… I sincerely hope this helps!

7. Oh and get this right, in the above brilliant example, you can see, that simply adding a CA.pem to your browser (the one you created to self sign a server certificate) can just do away with ANY security issues, when reaching out to localhost… Security my derrière… that is French for it!