111

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?

99

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.

  • 4
    @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? – drs Jul 15 '13 at 18:54
  • 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. – Zoredache Jul 15 '13 at 19:08
  • 2
    Where is this additional information buried? I was looking at some certificates and it's all gibberish to me – CodyBugstein Dec 4 '15 at 3:39
  • 3
    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 – LawrenceC Sep 25 '16 at 22:07
  • Is the certificate signed by a CA or the server being communicated with? – Olshansk Mar 29 '17 at 2:54
42

These two pictures together explained everything to me:

Source: linuxvoice

enter image description here

Source: infosecinstitute

enter image description here

  • 1
    Relevant xkcd – SIGSTACKFAULT Apr 14 '18 at 16:44
  • 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. – user1172173 Oct 13 '18 at 18:04
  • The first link, to linuxvoice.com/…, gives a certificate error. Ironic. – Tobb Apr 29 at 12:32
35

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.

  • Does Company A any point associate its (Company A's) private key with its (Company A's) certificate? – Tola Odejayi Feb 11 '16 at 21:09
  • No. a private key remains privet for A. – Mohsen Heydari Feb 12 '16 at 0:25
  • So where is the private key of company A used? – sivann May 23 '17 at 9:13
  • 2
    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. – Mohsen Heydari May 23 '17 at 20:14
  • I guess company A is a male. – DimiDak Nov 2 '18 at 16:54
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. enter image description here enter image description here

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.

3

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

1

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
    <PiratesOfTheCarribean>So we're going after this key!</PiratesOfTheCarribean> (Read: You're not making any sense at all...) – Timo Jun 23 '16 at 13:45
-2

Browser and server communication

HandShake:

  • Client Sends a random number along with supported Encryption
  • Server Sends its Certificate with supported Encryption. And the random number client has is encrypted with its private key and send back. The certificate contains Public key. Issuer of the Certificate or (CA), Expiration etc.
  • Client Verifies the certificate send by the server.

All PC comes with a list of CA whom they trust like VeriSign or DigiCert. These are ROOT CA.All root CA are self Signed. To understand. It's like If I trust Server A and Server A knows Server B then Server A can Vouch that This is Server B who he says to be. And way Server A vouch is by providing the Certificate to Server B. This certificate is actually Singed by Private Key of CA in our case Server A. who's public signature is already on our PC with which I can verify the authenticity of the certificate provided by Server B.

  • The Client Verifies the message or random number it has sent before, with the Public key( received in the Certificate).

  • Now client checks if the certificate is valid by sending an OCSP request and checking in the CRL DB.

  • Now if Certificate has not been revoked a session key pair will be established with which an encryption tunnel is established now all the traffic is encrypted.

All CSR Requests are signed by Intermediate Certificates, not Root CA directly to reserve integrity of the ROOT CA so that they are not compromised.

  • 1
    I understand it doesn't directly answer the question but please do comment when downvoting. – Kid101 Apr 14 '18 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.