Keys, Certificates and Trust

Chapter 3 of Securing Salesforce: Identity and Access, Part 1: Who Are You?, and chapter 12 of Integration Architect, Part 2: Designing Integrations That Work. It’s a shared chapter, the same in both courses.

Every identity mechanism, and every secure integration, rests on one question: why should one system believe another?

A sign-in through single sign-on, a token from an OAuth flow, a callout to a partner, a partner calling in: each one is a stranger at the door, saying who it is. This chapter is about how the door can tell. Not the settings, yet. The ideas underneath them: keys, signatures, certificates and the handshake. They’re the plumbing of the internet, and once you see them, every chapter after this one makes more sense.

The running story is a village sending gold to a town past bandits who read everything on the road. By module 4, the town becomes a real website, Steve’s Plumbing, and the village becomes your browser. Salesforce appears in every module, where the idea meets the platform.

The ideas in this chapter

• Assume every message can be read, and kept. Encrypt it with a published, tested algorithm and a long, random key, and be ready to replace both.
• Two keys that belong together. Lock with the public key, and only the private key opens it; lock with the private key, and anyone can check who sent it. The private key never leaves its owner.
• A hash is a fingerprint; a signature is a seal. Change one comma in a whole book and the hash changes completely. Lock the hash with a private key, and you prove who sent a message and that nobody changed it.
• Trust starts from something you already trust. A certificate is believed only when its chain of signatures leads up to a root already in your list. Hang up, and call the bank.
• Strangers agree on a key without sending it. The TLS 1.3 handshake makes the same session key on both sides, never sends it, and never reuses it, so yesterday’s conversations stay safe.
• Sometimes the client has to prove itself too. Two-way TLS checks the caller before anyone signs in. The client makes its own key pair, and the private key never travels.
• Every certificate expires. Public lifetimes are shrinking from 398 days to 47. Know where every certificate is, who renews it, and when.

The path through this chapter

Seven modules, each standing on its own.

1. The Bandits Are Listening. The bandits read everything; the cipher wheel; why a fixed wheel fails; a stronger algorithm, in the open; the key, and the two attacks; the problem that’s left.
2. Two Keys, Silver and Gold. Two keys that belong together; lock with silver, only gold opens; lock with gold, anyone opens; from silver and gold to public and private; what’s inside a certificate; where the private key lives on Salesforce.
3. The Seal on the Letter. The hash; any size in, the same size out; one character, a whole new hash; hashes retire too; the signature; checking it; signatures are everywhere.
4. Hang Up and Call the Bank. The certificate authority; built into your browser; the chain of trust; the look-alike; see it on Salesforce; the server is proved, you’re next.
5. The Handshake. The two hellos; the same key, made on both sides; proving it’s really Steve’s Plumbing; why the old handshake was retired; on Salesforce; a safe road.
6. Proving the Client Too. Two-way TLS; the server as its own certificate authority; who makes the key pair; calling out of Salesforce; calling into Salesforce; why it’s back in fashion.
7. Assume Every Certificate Expires. Not before, not after; why a certificate has an end date; reissuing; the shrinking lifetimes; how Salesforce issues and stores certificates; who hears about it; what breaks when one runs out.

In the Identity and Access course, chapter 4 takes these ideas into single sign-on. In the Integration Architect course, chapter 13 takes them onto the wire: who’s calling, which flow, and what to build on.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

• Where every key lives, who holds it, how it’s replaced, and that no one key opens everything.
• Which algorithms, hashes and protocol versions each system uses, and when the old ones retire.
• Check every signature, every time. Never turn off certificate checking to make something work.
• Which roots each system trusts, and never pinning a single certificate.
• One-way or two-way TLS for each connection, and the rules by direction on Salesforce.
• An owner and a date for every certificate, with renewals automated where you can.

Beyond the exam: an AI assistant can generate a key pair, a signing request and the configuration for a two-way TLS connection in seconds. What it can’t tell you is where that private key should live, who renews the certificate in 200 days, or whether a partner’s system still speaks an old protocol. Those are this chapter’s decisions, and they’re the ones that fail quietly, on a date.

Explore

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (opens in a new tab) (IETF, August 2018).
• Google Chrome Root Programs (opens in a new tab): how a browser decides which roots it trusts.
• Salesforce Help, Certificates and Keys (opens in a new tab): Certificate and Key Management in Setup.