31

What is the difference between a certificate and a private key?

In answering another question on this site, I wanted to point to a canonical answer to this question, but to my surprise I don't see one.

Users can be forgiven for getting these terms confused because many applications use the term "certificate" when they really mean "certificate + private key". It would be good to clear up the difference between the following file types: .crt, .pem, .p12, .pfx and why, for example, an application expecting a "client certificate" blows up when you give it a .crt file.

Here are some references that an answer could pull information from:

Mike Ounsworth
  • 58,107
  • 21
  • 154
  • 209
  • See https://crypto.stackexchange.com/questions/82135/difference-between-pem-vs-p12-vs-crt-vs-jks-vs-keystore-vs-pkcs-vs-x509-certific for links to several Qs that address this, although only 2 are here on security and IMO the best is the crypto one used as dupe. – dave_thompson_085 Sep 08 '21 at 03:08
  • Related: [What's the difference between X.509 and PKCS#7 Certificate?](https://security.stackexchange.com/q/73156/20935) – blong Sep 07 '22 at 16:04

2 Answers2

37

Every Private Key has a corresponding Public Key. The public key is mathematically derived from the private key. These two keys, together called a "key pair", can be used for two purposes: Encryption and Signing. For the purposes of certificates, signing is far more relevant.

A certificate is basically just a public key, which has been signed by someone else's private key. This forms the basis of public key infrastructure (PKI), which is explained in the articles linked in the question.

How do Certificates and Private Keys relate?

A certificate is just a "fancy" public key, which is related to a private key. You can do the same thing with a certificate as you can do with a public key.

If Bob gets the certificate of Alice, he can encrypt a message for Alice. Likewise, if Alice publishes some data and signs it with her private key, Bob can use Alice's certificate to see if it is really from Alice.

What are all those different file types?

  • .pem: A .pem is a de-facto file format called Privacy-Enhanced Mail. A PEM file can contain a lot of different things, such as certificates, private keys, public keys and lots of other things. A file being in PEM format says nothing about the content, just like something being Base64-encoded says nothing about the content.
  • .crt, .cer: This is another pseudo-format that is commonly used to store certificates. These can either be in the PEM or in the DER format.
  • .p12, .pfx: These are interchangable file extensions for the PKCS#12 format. Technically, PKCS#12 is the successor to Microsoft's PFX format, but they have become interchangable. PKCS#12 files are archives for cryptographic material. Again, what kind of material this contains is completely up to the user.

Wait, what!?

Yes, .crt, .pem, .pfx and .p12 can all be used to store certificates, public keys and private keys. From a purely technical standpoint, you can not tell what the semantic content of any of these files is just by their file extension. If you ever get confused, don't worry - you're not alone.

However, there are some common conventions that are being followed. .p12 and .pfx files are usually used to store a certificate together with the private key that corresponds to this certificate.

Likewise, .crt files usually contain single certificates without any related private key material.

.pem files are wildcards. They can contain anything, and it's not uncommon to see them used for all different kinds of purposes. Luckily, they are all plain text, and are prefixed in a human-readable way, such as

-----BEGIN CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
...

Why would an application not handle a .crt file if it wants a client certificate?

A certificate is just a public key, and thus by definition public. A client certificate is no different - just a public key by a person, machine or other "client", that is signed by some authority.

An application that wants a client certificate usually wants to use that certificate for something, such as to authenticate the client to a server. In order to do that, one needs the certificate and the corresponding private key.

So an application should really write "certificate plus private key", because the certificate alone is not enough to prove one's identity. It's actually the private key that does it.

To answer vitm's question: As the answer explains, a private key is always associated with a public key, and a certificate contains a public key, as well as other information regarding the individual holding the public key.

If a server program or client program want to use a certificate (e.g. a web server using a server certificate or a web browser using a client certificate), they need both the certificate and the private key.

However, that private key is never sent anywhere. The private key is used mathematically to decrypt messages, which are encrypted with the public key in the certificate - and to sign messages, which are verified using the public key in the certificate.

If I only had a certificate, without a public key, then I would not be able to act as the server or client, to whom the certificate relates to, as I could not sign messages or decrypt messages.

  • I wouldn't say that `.crt` or `.cer` are pseudo-formats and `.pem` is de-facto format. I would say opposite: `.crt` and `.cer` use exact binary format as specified in ASN.1 module (RFC 5280). PEM isn't used in transfer syntax during TLS negotiation, for example. Your statement is too arguable. – Crypt32 Mar 03 '20 at 21:17
  • 1
    @Crypt32 Wikipedia states that PEM is a de-facto format, so I stuck to that. I'm also not saying that RFC 5280 isn't an exact format, only that the file extensions were never formally tied to these formats. I've seen countless .crt files in real life that were actually .pem files –  Mar 04 '20 at 06:07
  • Ok, then Wikipedia's statement is arguable. On extensions -- fair anough. You say `PEM format says nothing about the content` -- aren't PEM header and footer intended to suggest about content type? – Crypt32 Mar 04 '20 at 07:12
  • 1
    @Crypt32 Yes, but that's not what I meant by that statement. What I meant is that you can't say "It's PEM, so it must be a private key". PEM can hold anything, so a file being in PEM format gives no indication about what the content is –  Mar 04 '20 at 07:15
  • You say `A file being in PEM format` -- I assumed that you talk about base64 with headers. You should rephrase to avoid ambiguities to `A file with .PEM extension ...`. – Crypt32 Mar 04 '20 at 07:19
  • 1
    Certificates ***CONTAIN*** public keys. Saying 'A certificate is just a "fancy" public key' is like saying 'A postmarked envelope is just a "fancy" letter'. Certs also contains data about the key, such as valid dates uses and whose key it is and who said so, just like envelopes say who the letter is from and when it was posted. However, the certificate itself isn't used in actual cryptographic (encryption or verification) operations just like an envelope isn't used when reading a letter. And, like a letter, you can transfer and store public keys without certificate (PGP does this). – CBHacking Jul 01 '21 at 00:35
  • "These two keys, together called a "key pair", can be used for two purposes: Encryption and Signing.": it can be used for key agreement as well (Diffie-Hellman). – ysdx Sep 07 '21 at 10:32
  • I have a question about the last block of client authentication. 1. For server authentication, the server must provide the client with its server certificate signed by the private CA key and this confirms its validity. How https works 2. You are claiming that for client authentication, the client must provide the server with not only its client certificate, but also its private key. Why can't the client act as a server in the first paragraph? – vitm Oct 19 '21 at 20:28
  • @vitm The client doesn't provide the private key - the client uses the private key. It works identically to how a server acts. –  Oct 19 '21 at 22:25
  • @MechMK1 you write "An application that wants a client certificate usually wants to use that certificate for something, such as to authenticate the client to a server. ". As I understand application use private key to sign own client certificate and so confirm that client has private key. But why It's not enough to have certificate signed by CA as for servers? – vitm Oct 20 '21 at 07:04
  • @vitm I edited my answer to hopefully explain. –  Oct 20 '21 at 11:05
  • @MechMK1 thanks a lot for clarification! – vitm Oct 20 '21 at 13:15
8

Certificate is a container that holds information about certificate holder/owner and public key. Private key is raw key material without any extra information. For example, from private key you can't extract information about owner of the key, or a certificate this private key is associated with. Certificate is often called as public certificate, because it contains only public key and public information.

Possessing the public certificate only doesn't prove certificate ownership. Only possession of private key that is associated with public key embedded in public certificate can prove certificate ownership.

About certificate types:

  • .crt and .pem are literally same thing. Just with different encoding used to store same information in file. .crt is often a pure pure binary copy of ASN.1-encoded certificate. .pem is same binary copy of certificate converted to base64 string and wrapped by PEM header and footer. They store only public certificate. No private key inside. See RFC 1421 for more details about PEM. You can open PEM in any text editor, copy/paste encoded certificate. It is hard to do with raw binary file, which .crt often is.

  • .p12 and .pfx are same thing. They represent a PKCS#12 container which is suitable to store both, public certificate and encrypted private key. PFX or P12 use binary file encoding. With PFX, you can store multiple certificates with associated private keys and optional certificate chains. Hence it is a container.

why, for example, an application expecting a "client certificate" blows up when you give it a .crt file.

as I said, having only public certificate (which .crt is) is not enough to prove the ownership of the certificate. When client authentication is used, client must prove that it owns the supplied certificate and it requires a private key to prove this ownership. Thus, client app must be able to access the private key associated with public certificate. Depending on client application, platform and other variables, it is done by having a .key file in a defined location, accessing PFX/P12 or other means provided by platform (read certificate and key from certificate store in Windows).

Community
  • 1
Crypt32
  • 5,901
  • 12
  • 24
  • 1
    +1 for clarifying that a certificate is a public key plus additional information. However, saying that `.crt` and `.pem` files are literally the same thing is not really true. While `pem` files should always come in PEM encoded format, `crt` (just like `cer` btw) can be in either PEM or DER encoded (=binary ASN.1) format, depending on the OS platform and/or application that created it. Conclusion: don't trust the file suffix too much. – not2savvy Apr 17 '20 at 13:46