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?


7 Answers 7


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, 2013 at 18:54
  • 1
    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, 2013 at 19:08
  • 3
    Where is this additional information buried? I was looking at some certificates and it's all gibberish to me Dec 4, 2015 at 3:39
  • 7
    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, 2016 at 22:07
  • Is the certificate signed by a CA or the server being communicated with?
    – Olshansky
    Mar 29, 2017 at 2:54

These two pictures together explained everything to me:

Source: linuxvoice

enter image description here

Source: infosecinstitute

enter image description here

  • 5
    Relevant xkcd Apr 14, 2018 at 16:44
  • 2
    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.
    – galaxis
    Oct 13, 2018 at 18:04
  • 11
    The first link, to linuxvoice.com/…, gives a certificate error. Ironic.
    – Tobb
    Apr 29, 2019 at 12:32
  • 2
    Why does the server also verifies the client's certificate using the CA? Mar 16, 2022 at 3:04
  • 1
    @RonyTesler This is only a guess, but assume two servers are communicating, e.g., say this is a Github webhook connected to Discord, now both ends need to verify they are who they say they are. As galaxis said this is more formally known as a 2-way TLS authentication. It's probably not the case for normal users navigating websites using their browsers. (but again as I said, take these all from me with a grain of 🧂.)
    – aderchox
    Apr 11, 2023 at 2:52

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? Feb 11, 2016 at 21:09
  • No. a private key remains privet for A. Feb 12, 2016 at 0:25
  • So where is the private key of company A used?
    – sivann
    May 23, 2017 at 9:13
  • 4
    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. May 23, 2017 at 20:14
  • around once in two years I have to deal with certificates... this answer, coupled with this video helps me refresh my understanding.
    – Eugene
    Jul 21, 2020 at 22:21

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.


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


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


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: https://security.stackexchange.com/questions/172274/can-i-get-a-public-key-from-an-rsa-private-key
  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 hampster 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 wif it: enter image description here 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...cause 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: enter image description here 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 derrier...that is French for ;=)
  • So, if you have a .pem file with a private key, you don't need to specify a public key, right? It sometimes confuses me, and I end up with the question of if I need to add a BEGIN PUBLIC KEY/END PUBLIC KEY statement. With theCERTIFICATE and PRIVATE KEY statements is enough right?
    – S. Dre
    Feb 27, 2023 at 14:59
  • The PEM file is an instance of an .X509 certificate that vouches for a person or organization, and includes the public key of that person or organization. The latter certificate is then "signed" by a CA certificate to vouch for its authenticity. Therefore the PEM does not include the private key. That key is private to the person or organization. When a message intended for the person is encrypted with their Cert public key, they can then decrpyt it, after receipt.
    – Beezer
    Mar 19, 2023 at 19:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .