What is the difference between a certificate and a key with respect to SSL?
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?
16 Answers
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.
8These two pictures together explained everything to me:
Source: linuxvoice
Source: infosecinstitute
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.
6Let 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):
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:
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=*. (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CAYou 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.
0An 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.
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).
2
