The Series: Signed, Sealed, Certified (Part 2: A Key, or Not a Key? That is the Question)

Part 2: A Key, or Not a Key? That is the Question.

In the first installment, we cracked open a digital certificate and looked at the pieces inside: the subject, issuer, validity period, public key, signature, Key Usage, EKU, and the rest of the “supporting cast”.

Now we need to clear up one of the most common points of confusion around certificates:

A certificate is not a private key.

Now, they are closely related. They are frequently stored, moved, exported, and discussed together. That makes it easy to mentally bundle them into one thing. But…

They are not one thing.

To understand certificates properly, we need to separate five different pieces:

• The private key
• The public key
• The certificate
• The Certificate Signing Request (CSR)
• The PFX, or PKCS #12, file

Once those pieces click into place, a lot of certificate behavior starts making much more sense.

Let's start with the key pair. Before there is a certificate, there is usually a cryptographic key pair consisting of a private key and a public key.

The two keys are mathematically related, but they serve very different purposes.

The private key is the sensitive piece. It stays with the person, computer, server, application, or device that owns it and should be protected accordingly.

The public key is designed to be shared. Depending on the cryptographic operation involved, the public key can be used to verify something created with the corresponding private key or participate in other cryptographic processes.

The important part is this, and while self-explanatory, worth repeating:

The private key stays private. The public key does not.

I know it sounds obvious, but it becomes very important once certificate files start moving around.

So Where Does the Certificate Fit?

The certificate takes that public key and associates it with an identity.

In simplified form, it says: This public key belongs to this subject, for this purpose, during this period of time, and this issuer signed that claim.

The certificate contains the public key. It does not normally contain the private key.

That means you can freely distribute a public certificate without giving away the secret needed to prove ownership of the associated key pair.

To paint a clearer picture: this is why you can browse to a website and receive its certificate without compromising the web server. The server gives you the public/publicly accessible information. The private key stays protected on the server.

Proving You Have the Private Key

If the certificate contains only the public key, how does another system know the certificate holder actually possesses the private key?

The answer depends on the protocol (more on this later), but generally the holder has to perform a cryptographic operation that can only be completed using the corresponding private key.

Another party can then use the public key from the certificate to verify the result.

A certificate doesn't carry proof of possession around inside it. Possession is something that gets tested, live, and at the moment it's needed.

This has a name: proof of possession. You'll see the term again in TLS, in EAP-TLS, and in essentially every protocol that needs to test whether whoever handed you a certificate actually holds the matching private key. The certificate provides the public key and identity information needed for another protocol to test that possession when necessary. We will see this show up later in TLS, VPN authentication, EAP-TLS, and other technologies.

Lights, Camera, CSR!

How do we get from a key pair to a certificate?

One method is a Certificate Signing Request, or CSR. A CSR is a request asking a certificate authority to issue a certificate.

It commonly contains things such as: the public key, identity information, requested names, as well as information related to the desired certificate

The CSR is also signed using the corresponding private key. This helps demonstrate that whoever created the request possesses the private key associated with the public key in the request. The private key itself does not need to be sent to the certificate authority.

A simplified flow looks like this:

1. Generate a private key.
2. Derive the corresponding public key.
3. Create a CSR containing the public key and requested identity information.
4. Sign the CSR using the private key.
5. Send the CSR to a certificate authority.
6. The CA validates the request according to its policies.
7. The CA issues a certificate containing the public key.
8. The private key remains with the requester.

So the CA signs the certificate. It does not need your private key to do it.

One thing worth knowing before you lose time to it: the CA does not have to honor what you asked for. On an internal AD CS deployment, certificate templates are frequently configured to build the subject and SAN from Active Directory rather than from the request, so the names you carefully specified in your CSR can be replaced with the ones the CA thinks you should have. If the issued certificate doesn't have the names you expected, check the template before you check your CSR.

Then What Is a PFX?

This is where things get interesting (if they aren't already).

If a normal certificate does not contain the private key, how do we move a certificate and its private key from one system to another?

One common answer is a PFX file. You'll probably see or have seen:

• PKCS #12
• .pfx
• .p12

A PFX is a container. Unlike a normal public certificate file, a PFX can contain:

• The certificate
• The associated private key
• Intermediate certificates
• Additional certificates in the chain

Because a PFX may contain a private key, it needs to be treated very differently from a normal public certificate.

This warrants repeating. A PFX may contain a private key, therefore, it needs to be handled differently compared to a normal public certificate.

A bit deeper: A .cer file generally contains only the public certificate and may therefore be safe to distribute publicly. A .pfx file can contain the private key and must be treated as sensitive material.

That is also why PFX files are commonly protected with a password.

The password protects the container. It is not the private key, and it is not a substitute for protecting the key afterward. The moment that PFX is unpacked onto a system, the password has done its entire job, and whatever guards the key from that point on is the operating system's problem, not the file's.

When the Error Message Lies

Here's a failure scenario where the error message is a bit dishonest.

You export a PFX with OpenSSL 3.x. You hand it to someone on an older Windows box. The Certificate Import Wizard tells them: "The password you entered is incorrect."

The password…is fine (You know it is. You triple checked.) OpenSSL 3 defaults to AES256-SHA256 for PKCS #12, and Windows versions before Windows 11 and Server 2019 don't support that algorithm for PFX import. Microsoft's own guidance is to fall back to 3DES-SHA1 for anything that has to land on an older machine. Newer Windows reads both, so the older format is the safe default when you don't control the destination.

Certificate File Versus Certificate Identity

This is where terminology can become messy. Trust me bro, someone is gonna ask you for the cert and mean something completely different.

"Send me the certificate."

But that begs the question: what do they actually need?

They might mean:

• The public certificate
• The certificate plus its chain
• The certificate and private key
• A CSR
• A PFX
• A root certificate
• or an intermediate certificate

The above are NOT interchangeable. The filename extension can provide clues, but even that is not always enough to tell you exactly what is inside.

When working with certificates, a rephrasing of the question is: What cryptographic material does the receiving system actually need?

If it only needs to trust or validate something, the public certificate may be enough. If it needs to actively authenticate as that identity, it will usually need access to the corresponding private key as well.

The Private Key Is the Important Part

Unfortunately, like all good things in this cruel, cruel world - certificates expire. Hark! ‘Tis joyous to know that certificates can often be reissued. Public certificates can usually be downloaded, distributed, and installed again.

But, but, but the private key is different.

If a private key is lost and there is no valid backup or recovery mechanism, the certificate may become useless for the purpose that requires that key. If the private key is stolen, the problem is even worse.

An attacker possessing that private key may be able to impersonate the certificate holder or perform operations that were supposed to be limited to the legitimate owner.

That is why private-key protection matters so much. Depending on the environment, private keys might be protected using:

• Operating system key stores
• TPMs
• Hardware Security Modules
• Smart cards
• Password-protected containers
• Key vaults
• Non-exportable key policies

We will get deeper into key protection later.

For now, the important lesson is that protecting the certificate and protecting the private key are not the same security problem.

Why This Matters in the Real World

A surprising number of certificate problems become much easier to understand once you ask whether the private key is actually present.

A certificate may appear correctly in the certificate store and still fail, for reasons including:

• The private key was never imported
• The private key was deleted
• The service account cannot access the private key
• The certificate was exported without the private key
• The wrong certificate and private key were paired
• The application is looking in a different key store
• The key was generated as non-exportable and someone is trying to move it
• A PFX was imported incorrectly

In Windows, one of the first things worth checking when troubleshooting certificate authentication is whether the certificate actually has an associated private key. Self-explanatory, but also worth repeating. A great man told me in order to remember something, you need to hear it seven, zeven, sieben, sette, siedem, sete, siete (7) times. Sometimes…just having the certificate is not enough.

Putting the Pieces Together

Here is a "definition of terms" in plain language:

• Private key: The secret cryptographic key controlled by the owner.
• Public key: The shareable half of the key pair.
• Certificate: A signed document that associates the public key with an identity and other information.
• CSR: A signed request containing the public key and requested identity information, used to ask a CA for a certificate.
• PFX: A portable container that can hold the certificate, private key, and potentially additional certificates.

DIAGRAM: simplified certificate lifecycle. THIS IS AI GENERATED BECAUSE MS PAINT IS A TERRIBLE MEDIUM FOR VISUALIZATION…sometimes

The Finale

A digital certificate and a private key are partners, but they are NOT the same thing.

1. The certificate is designed to be shared.
2. The private key is designed to remain secret.
3. The certificate tells others which public key belongs to an identity.
4. The private key allows the owner to prove that the identity is actually theirs.

The CSR and PFX are different pieces of the lifecycle that help us request, issue, transport, and use those cryptographic materials.

Curtain Call

We can take another step forward. I'll throw an homage to Sanderson here: "What's the most important step a man can take?"

...the next step. A Certificate Is a Claim, Not Trust. In keeping with my usual sense of prose, I will come up with a better title, maybe.

Just because someone hands you a certificate does not mean you should implicitly trust.

If you're still managing to follow along, I just want to say thank you for sticking with it.