Study guide

Study guide for the shared chapter Keys, Certificates and Trust: chapter 3 of Securing Salesforce: Identity and Access and chapter 12 of Integration Architect. Read the seven modules first; this page helps you check what stuck.

About this study guide. It’s built only from this chapter’s own content and the published Salesforce exam guides’ lists of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter is the ground under both courses: how one system can believe another. For the Identity and Access Management exam, it’s the objective on how trust is established between two systems (IDC-3). For the Integration exam, it supports the security mechanisms of a design (DES-5) and security for inbound and outbound integrations (BLD-5). The questions rarely ask about mathematics. They ask what a certificate proves, which key goes where, and what breaks when one expires.

For the Exam

Tick them off as you go. Each one links to where it’s taught.

Keys and ciphers (IDC-3)

I assume every message on the network can be read and kept, so it’s encrypted. (The bandits read everything)
I know encryption is a public, tested algorithm plus a secret key, and that the key is what must stay secret. (The key, and the two attacks)
I know algorithms retire, and keys should be long, random, rotated, and not used for everything. (A stronger algorithm, in the open)
I know the problem a shared key leaves: getting it to the other side safely. (The problem that’s left)

Public and private keys (IDC-3, DES-5)

I know a key pair: lock with the public key and only the private key opens it; lock with the private key and anyone with the public key can check who sent it. (Both directions, side by side)
I know a certificate is a public key with a name on it, and can read its main fields: subject, issuer, validity dates, public key, signature. (What’s inside a certificate)
I know the private key never leaves its owner; in Salesforce it stays in the org unless someone exports a keystore. (Where the private key lives on Salesforce)

Hashes and signatures (IDC-3, DES-5)

I know a hash takes no key, always gives the same fixed size, can’t be reversed, and changes completely when one character changes. (The hash, One character, a whole new hash)
I know a digital signature is the hash locked with the private key, checked with the public key, and proves who sent it and that it wasn’t changed, not that it’s secret. (The signature, Checking the signature)
I know SHA-1 is being retired in favour of SHA-256 and stronger. (Hashes retire too)
I know where Salesforce uses signatures: SAML assertions, the JWT bearer flow, and the HMAC signature in the OAuth token response. (Signatures are everywhere)

The chain of trust (IDC-3, BLD-5)

I know a certificate authority checks who owns a name and signs the certificate. (The certificate authority)
I know the browser checks the chain locally against its own root store: site, intermediate, root. (Built into your browser, The chain of trust)
I know a look-alike certificate fails because its chain doesn’t reach a trusted root. (The look-alike)
I never turn off certificate checking, and never pin a certificate: Salesforce replaces its own. (See it on Salesforce)

The handshake (IDC-3, DES-5)

I can walk through the TLS 1.3 handshake: two hellos with key shares, the same session key made on both sides and never sent, the server’s certificate and signature, then the conversation. (The two hellos, The same key, made on both sides)
I know forward secrecy: stealing the private key later opens nothing from the past; that’s why the old RSA key exchange was retired. (Why the old handshake was retired)
I know Salesforce strongly recommends TLS 1.3, and keeps TLS 1.2 because it meets forward secrecy. (On Salesforce)
I know one-way TLS proves the server; the sign-in proves the user, at the application level. (A safe road)

Two-way TLS (BLD-5, DES-5)

I know two-way (mutual) TLS proves the client in the handshake, before anyone signs in. (Two-way TLS)
I know the client makes its own key pair and sends only a signing request, so the private key never travels. (Who makes the key pair)
Calling out: the other system’s authority signs Salesforce’s request, and the certificate goes on the named credential. (Calling out of Salesforce)
Calling in: public roots only, a Mutual Authentication Certificate, an API Only user with Enforce SSL/TLS Mutual Authentication, port 8443. (Calling into Salesforce)

Certificates expire (IDC-3, BLD-5)

I know every certificate has “not before” and “not after”, and is reissued, usually with a new key pair, not extended. (Not before, not after, Replacing one: reissuing)
I know public lifetimes are shrinking: 398 days, then 200 from 2026-03-15, 100 from 2027-03-15, 47 from 2029-03-15. (The public lifetimes are shrinking)
I know Salesforce’s self-signed and CA-signed certificates, and who gets the expiry warnings. (How Salesforce issues and stores certificates, Who hears about it)
I know what stops when a certificate runs out: single sign-on, signed tokens, two-way TLS and callouts. (What breaks when one runs out)

Beyond the Exam

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

Where every private key lives is a design decision. Know who can export it.
Check every signature, every time.
Trust the chain, never pin the certificate.
Know every connection’s TLS version, on both sides.
The client makes its key pair. Signing requests, not delivered private keys.
Every certificate has an owner and a date, and renewals are machine work now.

Words to Know

Term	In one line
Algorithm, key	The public recipe; the secret that makes it yours
Public key, private key	The one you share; the one that never leaves home
Certificate	A public key with a name on it, signed by someone who vouches
Hash	A fixed-size fingerprint of any message; no key
Digital signature	A hash locked with the private key
HMAC	A hash with a shared secret mixed in
Certificate authority	Checks who owns a name and signs the certificate
Root store	The roots a browser or system already trusts
Chain of trust	Each certificate checked by the one above it, up to a root
TLS handshake	How two strangers agree on a session key
Forward secrecy	A stolen key later opens nothing from the past
Two-way TLS (mTLS)	The client proves itself in the handshake too
Certificate signing request	A name and a public key, sent to be signed
Keystore	A file that holds certificates and their private keys

Check Yourself

Short scenarios in the style of the course. Decide your answer before you open it.

1. A partner asks you to email them your org's certificate for an integration. Is that a leak?

No. A certificate holds the public key, and public keys are meant to be shared. The private key stays in the org; only an exported keystore carries it. Reread Where the private key lives on Salesforce.

2. A message arrives with a valid signature. Does that mean nobody else could read it?

No. A signature proves who sent it and that it wasn’t changed. If it must also be secret, it must be encrypted as well. Reread Checking the signature.

3. A developer turns off certificate checking on a callout "to make it work in test". What do you say?

Never. Without the check, anyone with a look-alike certificate can take the call. Fix the trust instead, for example by adding the right root. Reread The look-alike.

4. An old client hard-coded Salesforce's certificate. One morning every call fails. Why?

Salesforce replaced its certificate, as it does before they expire, and it recommends against pinning. Trust the chain to the root, not one certificate. Reread See it on Salesforce.

5. A server's private key was stolen today. Can the attacker read last year's recorded conversations?

Not with TLS 1.3, or TLS 1.2 with forward secrecy: the session keys were never sent. With the old RSA key exchange, yes, which is why it was retired. Reread Why the old handshake was retired.

6. A partner system must call Salesforce's API with two-way TLS using a certificate from its own private authority. Will Salesforce accept it?

No. Calling in, Salesforce accepts client certificates that chain to a public root, uploaded as a Mutual Authentication Certificate, for an API Only user, on port 8443. Reread Calling into Salesforce.

7. Your team plans to send a partner a client certificate and its private key on a thumb drive. What's the better way?

The partner makes its own key pair and sends a certificate signing request; your authority signs it and sends back the certificate, which is public. The private key never travels. Reread Who makes the key pair.

8. Single sign-on stops for everyone on a Monday morning. Nothing was changed. Where do you look first?

An expired certificate: the identity provider’s signing certificate, or the one Salesforce checks it with. Certificates stop working on their “not after” date, all at once. Reread What breaks when one runs out.

Explore

Salesforce Certified Platform Integration Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-01). Always check the current version before you book an exam; the Identity and Access Management exam has its own guide.
RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (opens in a new tab) (IETF, August 2018).