What Is a Private Key? SSL Private Keys Explained

What a private key actually is

Strip away the jargon and a private key is just a number — an extraordinarily large, randomly generated one. For an RSA key it's effectively a 2048-bit (or larger) integer; for an elliptic-curve key it's a smaller but equally random value tied to a specific curve. What makes that number special is the math wrapped around it: it was created as one half of a pair, and that pairing has a one-way property. You can hand out the public half freely, and no one can work backward from it to recover the private half in any practical amount of time.

Because it's "private," two rules follow automatically. First, it is generated by you (or by your hosting panel or tool) on your own machine, not handed to you by anyone else. Second, it is never transmitted — not to the CA, not to a browser, not across the network during a connection. The whole point of public-key cryptography is that you can prove you hold the private key without ever revealing it. If you want the broader theory behind why two keys are better than one, our guide to symmetric vs asymmetric encryption covers it; here we focus on the practical key file you actually have to manage.

The key pair: private vs public

A private key never exists alone. It's born alongside a public key, and the two are mathematically bound: whatever one of them transforms, only the other can reverse. The split in how you treat them is what makes the whole system work.

A useful way to picture it: the public key is a padlock you can mass-produce and hand to anyone, while the private key is the single key that opens every one of those padlocks. People can lock messages to you (encrypt with your public key), but only you can open them (decrypt with your private key). Run it the other way and you get signatures: you "lock" something with your private key, and anyone can confirm it was you by checking it opens with your public key. This is exactly the trust that a public key infrastructure (PKI) is built on.

Where your private key comes from

For website certificates, the private key is created at the same moment as your Certificate Signing Request (CSR). When you generate a CSR — in a browser-based tool, in your hosting control panel, or with a command like the one below — two things are produced together: the CSR you'll send to the CA, and the private key you keep.

# Creates a 2048-bit RSA private key (example.key)
# and a matching CSR (example.csr) in one step
openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.key -out example.csr

The example.key file is your private key. The CSR carries a copy of the public key plus your domain and organization details, all bundled into the PKCS #10 format the CA expects. Critically, the key never travels with the request — the CSR is the only thing that leaves your machine. For a full walkthrough with screenshots, see our CSR generation guide, and if you're choosing between RSA and an elliptic-curve key, our ECC vs RSA comparison explains the trade-offs.

Why the CA never sees your private key

This trips up almost everyone the first time: you buy a certificate from a certificate authority, but the CA plays no part in creating or holding your private key. Here's the actual sequence of what gets shared:

1. You generate the key pair locally. The private key is written to a file you control; the public key is embedded in a CSR.
2. You send the CSR (public key + domain details) to the CA. The private key stays behind.
3. The CA validates that you control the domain, then signs your public key into a certificate.
4. The CA returns the certificate. You install it next to the private key you kept, and your server pairs the two.

This is a security feature, not an oversight. If the CA never has your private key, then a breach of the CA can't leak it, a rogue employee can't copy it, and you never have to trust anyone else to keep your most sensitive secret. It also explains the hard truth behind lost keys: the CA literally cannot send you a copy of something it never received. The flip side is that the CA still vouches for the binding between your public key and your identity — the job described in our guide to what a certificate authority does.

What the private key does in a TLS connection

When a browser connects to your HTTPS site, the private key has one decisive job during the handshake: it proves your server is the legitimate owner of the certificate. In modern TLS 1.3, the server uses its private key to create a digital signature over the handshake. The browser verifies that signature using the public key in the certificate it just received. Only a server holding the matching private key could produce a signature that checks out — so a valid signature is proof you're talking to the real site and not an impostor presenting a stolen certificate.

That design has a valuable consequence called forward secrecy: because TLS 1.3 negotiates a throwaway session key for every connection rather than encrypting traffic directly with the private key, capturing today's encrypted traffic and stealing the private key later still won't decrypt past sessions. The step-by-step of how the key fits into the wider exchange is laid out in our guide to how SSL works.

Where the key lives and what it looks like

A private key is usually a small text file. In the common PEM format it's Base64 text wrapped between header and footer lines, and it's typically named with a .key or .pem extension:

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQ...
...several more lines of Base64...
-----END PRIVATE KEY-----

Where that file sits depends on your platform, and on some platforms it isn't a loose file at all:

• Linux (Apache/Nginx): a .key file, often under /etc/ssl/private/ or /etc/pki/tls/private/, referenced directly in the server config.
• Windows / IIS: the key is held in the system certificate store and is re-paired with the certificate when you "complete" the pending request — which is why importing a certificate on the wrong machine often leaves it "without a private key."
• Bundled with the certificate: in the PFX / PKCS#12 format the private key and certificate are packaged together in a single password-protected .pfx or .p12 file — handy for moving both between Windows servers.

One detail worth knowing: a certificate and a private key only work together if they came from the same pair. If you're ever unsure whether a key matches a certificate, you can compare their moduli with OpenSSL (or our SSL tools) — our OpenSSL cheat sheet shows the exact commands.

How to protect your private key

Because the private key is the one secret that the entire certificate depends on, protecting it is mostly about controlling who and what can read that file. A few habits cover the vast majority of real-world risk:

A natural question is how long a key should live. With certificate lifetimes shrinking — a 199-day maximum took effect in March 2026, with further cuts scheduled — you'll be renewing more often anyway, which is the ideal moment to rotate to a fresh key pair. Generating a new key at each renewal limits the blast radius of any exposure you never noticed.

What happens if you lose it

Losing a private key feels like a crisis, but the fix is routine. A certificate is only usable when paired with its matching key, so a certificate whose key is gone simply can't be installed — and since the CA never had the key, no one can regenerate the original. The answer is to reissue (sometimes called rekey) the certificate:

1. Generate a brand-new key pair and CSR on the server where the certificate will live.
2. Submit the new CSR to your CA through the reissue/rekey option in your account or panel.
3. Receive the reissued certificate — issued against the new public key, for the remaining validity of your order, typically at no extra cost.
4. Install it alongside the new key, and update every server or load balancer that used the old one.

The same reissue process is your emergency response if a key is ever exposed: generate a new pair, reissue, deploy, and (where supported) have the old certificate revoked so the compromised key can't be used. If you'd like the renewal angle in depth, our certificate renewal guide walks through generating a fresh CSR and key each cycle.