Public and Private Keys
Module 2 of 7 in the shared chapter Keys, Certificates and Trust, chapter 3 of Securing Salesforce: Identity and Access and chapter 12 of Integration Architect. Each module stands on its own.
The question this module answers: How can two sides that have never met share a secret, when every message between them can be read?
Where we left off
Section titled “Where we left off”In module 1, the village learned to encrypt its messages. Every message on the road can be read and copied by the bandits, so the village scrambles each one with a strong, public algorithm and a long, secret key. The bandits copy the encrypted text and learn nothing.
But there was a catch. The town has to hold the same key to read the message. One key, used to lock and to unlock: that’s symmetric encryption.
So here’s my question. What is the problem with one key, when the two sides are far apart?
The key has to be shared. And the only road between the village and the town belongs to the bandits. If the rider carries the key, the bandits copy it, and every message they ever took can now be read.
Think of the village as your browser and the town as a website it has never visited. Or Salesforce, calling a system on the other side of the world for the first time. They have never met. There’s no one to carry the key safely. How do they start?
Two keys that belong together
Section titled “Two keys that belong together”This is where the experts in cryptography come back into the story, the same smart PhDs who gave us the strong algorithms. They came up with a new idea, and it’s a strange one the first time you hear it.
An algorithm with two keys. Not two copies of one key: two different keys, made together, as a pair. One key locks, and the other key unlocks. And it works both ways round.
Here’s the rule. If a message is locked with the first key, only the second key can unlock it. If it’s locked with the second key, only the first key can unlock it. Once a message is locked with one key, it cannot be unlocked with that same key.
Because the two keys are different, this is called asymmetric encryption, the opposite of module 1’s symmetric, one-key encryption.
Let’s give the two keys names. One is the silver key: this is the public key, and it’s meant to be given out. The other is the gold key: this is the private key, and it never leaves its owner. Locked with silver, only gold opens it. Locked with gold, only silver opens it.
Who makes the pair? The side that will keep the gold key. The town makes both keys, keeps the gold one, and the gold key never travels. Not on the road, not with a rider, not ever.
How the mathematics does this is the experts’ work, and you don’t need it to design with it. What you need is the rule, and what each direction gives you.
Here’s the rule as a picture, with no village and no bandits yet: one key encrypts, the other decrypts, in either direction.
Lock with silver, only gold opens
Section titled “Lock with silver, only gold opens”So the town does something that sounds wrong after module 1. It sends its silver key out on the road, on purpose. It tells the world: here is my public key, take a copy.
The bandits stop the rider and copy the silver key, just as they copy everything. Now, what can the bandits do with it?
They can lock a message to the town, like anyone else can. But they can’t open one. A message locked with the silver key opens only with the gold key, and the gold key is in the town.
So the village takes Gold leaves Friday by the mountain road and locks it with the town’s silver key. The rider carries it. The bandits stop him, copy the locked message, and try their copy of the silver key on it. Nothing. The silver key that locked it can’t unlock it. The rider rides on, and the town opens the message with its gold key.
Think about what just happened. The village and the town never met. Nobody carried a secret key down the road. And still the village sent the town a secret the bandits can’t read. Anyone, even a stranger the town has never heard of, can now send the town a secret.
Lock with gold, anyone opens
Section titled “Lock with gold, anyone opens”Now turn it around. The town locks a message with its gold key and sends it to the village.
Who can read it?
When I asked this in a class, the first answer was “only the town”. Look at the rule again. Locked with gold, only silver opens it. And who has the silver key? The village. And the bandits. And anyone else who asked for a copy, because the town gave it to the world.
So a message locked with the gold key is not a secret at all. Anyone can open it.
Then why would the town ever do it? Here’s the clever part. Only one place in the world holds the gold key. If the town’s silver key opens a message, that message must have been locked with the town’s gold key. So it must have come from the town. Not secret, but proof of who sent it.
Hold on to that. In module 3, that proof becomes a signature, and it’s the root of almost everything in identity.
We’re building a bridge, and we’re halfway there.
Both directions, side by side
Section titled “Both directions, side by side”This is the part people most often get backwards, so let’s put the two directions next to each other.
You’ve seen the mechanism. Here are the same two rows, told with the village, the town and the bandits:
| Locked with | Opened with | Who can read it | What it gives you | |
|---|---|---|---|---|
| The village to the town | the town’s silver key | only the town’s gold key | only the town | a secret, to whoever holds the gold key |
| The town to the village | the town’s gold key | the silver key | anyone with the silver key | proof it came from the town |
Same two keys, two different messages, two directions, two different results. Lock with silver for a secret; lock with gold for proof.
Not quite there yet
Section titled “Not quite there yet”Let’s go back to the town and play the whole story through, frame by frame: the town makes its pair, the silver key goes out, a secret travels one way, proof travels the other.
Now let’s add up what the village has.
- It can send the town a secret. Lock with silver; only gold opens. In fact anyone with the silver key can: we now have a one-way encrypted path to whoever made the pair and kept the gold key. That’s important, and the rest of this chapter builds on it.
- It can tell that a message came from the town. Lock with gold; silver opens, and only the town could have locked it.
That’s a real piece of the puzzle. But can the town send the village a secret?
No. Anything the town locks with its gold key, anyone with the silver key can open, and the bandits have the silver key. The secrets go one way: from the village to the town, and not back. We’re not quite there yet.
There’s one more thing. Two keys are slower to use than one shared key; symmetric encryption is much faster for the work of encrypting every message. So the two keys are rarely used for the messages themselves. But a one-way secret is enough for something very useful: the village can make a fresh shared key and send it to the town, locked with the town’s silver key. Then both sides hold the same key, and the bandits never saw it. That’s where the puzzle is going, and module 5, the handshake that protects the web, puts it together.
A little math
Section titled “A little math”The two-key mathematics works very differently from module 1’s algorithms, and it needs much longer keys for the same strength. The US standards body NIST publishes a table that compares them: a two-key RSA key of 3072 bits is rated about as strong as a 128-bit AES key. Salesforce’s own certificates use keys of 2048, 3072 or 4096 bits. So when you see a 2048-bit key next to a 128-bit key, the bigger number isn’t the stronger key. They’re measured on different scales.
From silver and gold to public and private
Section titled “From silver and gold to public and private”Silver and gold have done their job. From here on, let’s use the names you’ll see everywhere else: the silver key is the public key, and the gold key is the private key. Same two keys, same rule. Locked with the public key, only the private key opens it. Locked with the private key, the public key opens it, and that proves who locked it.
Now, how does the town actually hand out its public key? Not as a bare key. A key on its own is just a very long number, and a number doesn’t say whose it is. So the town puts its public key in a small document with its name on it. That document is a digital certificate.
The certificate and the private key belong together, as a pair. The certificate holds the public key and goes out to the world. The private key is its partner: it never goes in the certificate, and it never leaves the town. When people say “install the certificate” on a server, they mean the pair: the certificate the world sees, and the private key kept hidden beside it.
What’s inside a certificate
Section titled “What’s inside a certificate”Let’s open one up. Here’s an example certificate for the town’s website, town.example, with the parts that matter now. (.example is a name set aside for examples; no real site uses it.)
| Field | Example | What it means |
|---|---|---|
| Subject | town.example | Who this certificate is for: whose public key this is |
| Other names | town.example, www.town.example (opens in a new tab) | Every name the certificate covers |
| Public key | RSA, 3072 bits | The silver key itself, the long number the world uses |
| Valid from | 2026-11-01 | The first day it can be used |
| Valid to | 2027-05-19 | The last day. Every certificate is made to expire (module 7) |
| Serial number | 04:A1:9C:… | A unique number, so this one certificate can be named |
| Issuer | (someone who vouches for the town) | Who says this really is the town’s key. That’s module 4 |
| Signature | (a long string of characters) | The issuer’s proof that nothing in here was changed. That’s module 3 |
Look at the first three rows: a name, and a public key. That’s the heart of it. A certificate says, “this public key belongs to this name”. The rest says for how long, and who stands behind the claim.
You can open real ones yourself. Most browsers let you click the icon beside the address and view the site’s certificate. Try it on a site you use every day, and you’ll find these same fields. The format is a standard called X.509 (the IETF’s RFC 5280).
Where the private key lives on Salesforce
Section titled “Where the private key lives on Salesforce”You’ll meet this pair the first time you open Certificate and Key Management in Setup. When you create a self-signed certificate there, Salesforce makes the key pair inside your org: the certificate and its private key.
The certificate you download, a .crt file, holds the public key. You can hand it to any system you like; that’s what it’s for. The private key stays in the org. It leaves only if someone exports a keystore: Salesforce lets you “export all your certificates and private keys into a keystore” to “move keys from one organization to another” (Certificates and Keys (opens in a new tab), Salesforce Help, checked 2026-11-07). So treat an exported keystore file like the private key itself.
So the keystore export is the moment to watch. Sharing the certificate is not a leak; it’s the public key, made to be shared. Exporting the keystore takes the private key out of the org. Module 7 shows how Salesforce stores and replaces both.
The question that’s left
Section titled “The question that’s left”One more question, and it’s the one the bandits are already asking.
The village locked its secret with the public key in “the town’s” certificate. But where did the village get that certificate? It came down the road, past the bandits. And a certificate is only a document: anyone can write “town.example” on one, and put their own public key inside.
What if the bandits stopped the rider, kept the town’s certificate, and handed on one of their own instead, with the town’s name on it, their own public key inside, and the private key to match in their pocket? The village would lock its secret with the bandits’ public key, believing it was the town’s. The bandits would open it, read it, lock it again with the town’s real public key, and send it on. The town would never know.
That’s called a man-in-the-middle attack: someone sitting between the two sides, pretending to each one to be the other.
So how does the village know the certificate really belongs to the town, and that nobody changed it on the way? Two keys can’t answer that on their own. First, module 3 gives us the tool: hashes and signatures, built from the “proof it came from the town” we found above. Then module 4, “Hang up and call the bank”, shows who vouches for a certificate, and why we believe them.
What an architect decides here
Section titled “What an architect decides here”- The private key never leaves its owner. Where it lives, and who can export it, is the design decision.
- Public keys are meant to be shared. Handing out a certificate is not a leak.
- A certificate is a public key with a name on it. It goes out to the world; its private key stays home.
- A public key is only useful if you know whose it is. Who vouches is module 4.
- Two keys are a piece of the puzzle, not the whole answer. One-way secrets and proof of the sender; the handshake in module 5 finishes it.
Explore
Section titled “Explore”- NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1 – General (opens in a new tab) (NIST, May 2020; Table 2, comparable strengths; checked 2026-11-01)
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile (opens in a new tab) (IETF, May 2008; checked 2026-11-01)
- Certificates and Keys (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-10-31)