The Chain of Trust

Module 4 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: When a website hands you a certificate with its name on it, why should you believe it?

Where we left off

In module 3 the village checked the town’s signature with the town’s public key, the one in the town’s certificate. The check works perfectly. But it only proves that the message matches that key.

And anyone can write a name on a certificate. The bandits can make their own key pair, write the town’s name on a certificate, put their own public key inside, and sign everything with their own private key. Every check from module 3 would pass.

So the question is no longer about mathematics. It’s about trust. Whose key is this, really?

Hang up and call the bank

Let me ask you something. Your phone rings. The caller says they’re from your bank, they know your name, your address, maybe even your last few purchases. And they ask for your account number. Do you give it to them?

Never. Because you don’t know who they are. They could know everything about you and still be a criminal.

So what do you do instead? You hang up. You find your bank’s phone number from somewhere you already trust: the back of your card, your bank’s own app. And you call them back. Now you know who you’re talking to.

That’s exactly the problem a browser has the first time it meets a website. A certificate shows up saying “I’m Steve’s Plumbing”. The browser has never met Steve’s Plumbing. So it needs to “call the bank”: check the claim with someone it already trusts.

From here on, the town becomes a real website: Steve’s Plumbing, at stevesplumbing.example. (.example is set aside for examples; no real site uses it.) The village becomes your browser.

The certificate authority

The someone the browser already trusts is a certificate authority, or CA: a company whose job is to check who owns a name and vouch for it.

Here’s how Steve’s Plumbing gets its certificate. It makes its own key pair and keeps the private key, just as in module 2. It sends its public key and its name to a certificate authority. The authority checks that Steve’s Plumbing really controls stevesplumbing.example. Then the authority signs Steve’s Plumbing’s certificate with the authority’s own private key.

Remember the two rows we left waiting in module 2’s certificate? Issuer is the authority’s name. Signature is the authority’s signature over everything else in the certificate, made exactly as in module 3: hash the certificate, lock the fingerprint with the authority’s private key.

Some authorities charge, a few hundred dollars a year or less; some are free. Either way, the certificate is only as good as the authority’s checks.

Built into your browser

Now, how does the browser “call the bank back”? You might think it contacts the authority every time. It doesn’t. Think about it: every browser in the world calling the authority for every website, all day long. Instead, the authority’s own certificate is already in your browser.

Every browser and operating system comes with a built-in list of certificate authorities it trusts. Google’s Chrome describes it this way: when it connects to a website, it “verifies the site’s certificate against a list of trusted CAs, known as a Root Store.” You’ve had this list all along without knowing it.

So when Steve’s Plumbing’s certificate arrives, the browser reads the Issuer, finds that authority’s certificate in its own list, takes the authority’s public key from it, and checks the signature. Match? The certificate is real. And it all happens locally, in milliseconds, with no call to anyone.

This is “trust, but verify” in practice. You have to start by trusting something. On the web, that something is the list in your browser.

The chain of trust

There’s one more layer, and you’ll see it the moment you open a real certificate.

The certificates in your browser’s list are root certificates. A root signs itself: nobody stands above it, which is why it has to be in the list already. Roots are too valuable to use every day. The rules the authorities work under don’t allow a root’s private key to sign a website’s certificate directly. So the root signs an intermediate certificate, and the intermediate signs the websites’ certificates.

That gives you a chain:

Link	Signed by	Where the browser gets it
Root certificate	itself	already in the browser’s list
Intermediate certificate	the root	sent by the website, with its own certificate
Steve’s Plumbing’s certificate	the intermediate	sent by the website

The browser checks each link with the public key of the link above it: Steve’s Plumbing’s signature with the intermediate’s public key, the intermediate’s signature with the root’s public key, and the root is in the list. One certificate checks the next, all the way up to something the browser already trusts. That’s the chain of trust.

Click to enlarge

The look-alike

Now let’s go back to the bandits. They make a certificate for stevesplumbing.example with their own public key inside. What happens when the browser gets it?

To be trusted, it needs a signature from an authority in the browser’s list. To get one, the bandits would have to prove to that authority that they control Steve’s Plumbing’s name, and they can’t. So they sign it themselves, or get it signed by someone not on the list. The browser follows the chain up and finds nothing it trusts at the top. It shows a warning and stops.

That warning page you’ve seen in your browser, the one that says the connection isn’t private? That’s the chain of trust doing its job. It’s the browser hanging up the phone.

See it on Salesforce

Let’s look at a real one. Open your Salesforce login page. Click the icon beside the address, and choose to view the certificate. You’ll find everything from this module and module 2:

• Issued to: the name the certificate covers.
• Issued by: the authority that signed it. Note its name; it’s in your browser’s list.
• The chain: most browsers show it as a short list or a little tree: the root at the top, an intermediate, then Salesforce’s own certificate.
• The dates: valid from, valid to.
• The public key and the signature algorithm.

Then ask yourself: when does this certificate expire, and what would happen to an integration that had copied this exact certificate into its own settings? Salesforce replaces its own certificates before they expire, and it “strongly recommends against certificate pinning” (holding on to one exact certificate) (Certificates in Salesforce (opens in a new tab), Salesforce Help, checked 2026-11-07). Trust the chain, not the single certificate. Module 7 comes back to this.

The server is proved; you’re next

Look at what we’ve built. Your browser now knows it’s really talking to Steve’s Plumbing, or to Salesforce, and not to a look-alike. That’s called one-way TLS: one side, the server, has proved who it is.

The server doesn’t know who you are yet. It will, once you sign in, through the front door (the Front Door chapter). That’s normal for the web: the certificate proves the server, and the sign-in proves you. Module 5 shows how those two layers fit together.

Two things come next. Module 5, the handshake, puts everything together, keys, certificates and signatures, to set up the shared key for the conversation. And module 6 answers the other direction: when the server needs to know who the client is, before anyone signs in.

What an architect decides here

• Trust starts from something you already trust. On the public web, that’s the browser’s list of authorities.
• Which roots a system trusts is a decision. Browsers decide for the public web. Inside Salesforce, the Certificate Trust Store holds extra roots you choose (module 7).
• Never turn off certificate checking to “make it work”. That’s giving your account number to the caller.
• Trust the chain, don’t pin the certificate. Certificates are replaced; chains are how you keep trusting the new one.

Explore

• Google Chrome Root Programs (opens in a new tab) (Google; read 2026-11-01)
• Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (opens in a new tab) (CA/Browser Forum, version 2.3.1, section 6.1.7; checked 2026-11-01)
• Salesforce Help, Certificates in Salesforce (opens in a new tab), checked 2026-11-07.