Skip to content
SteveTechArcSteveTechArc Courses

Two-Way TLS

Module 6 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: The handshake proves the server is real. When does the server need to know who the client is, before anyone signs in, and how does it find out?

Who’s on the road

Section titled “Who’s on the road”

At the end of module 5, the handshake had built a safe road. Your browser knew for certain it was talking to Steve’s Plumbing. Steve’s Plumbing knew someone was at the other end, but not who, until you signed in.

Most of the time, that’s fine. The road is private, and then you sign in: a username, a password and a second factor through the front door (the Front Door chapter), single sign-on, or an OAuth flow. The server learns who you are inside the secure connection, at the application level.

But think about the highest level of security you could ask for. What if the server wouldn’t even talk to you, wouldn’t even show you a sign-in page, unless it already knew which machine was calling? Before any username. Before any password.

That’s two-way TLS.

Two-way TLS

Section titled “Two-way TLS”

In ordinary, one-way TLS, the server shows its certificate and the client checks it. In two-way TLS, the server also asks the client for a certificate, during the same handshake. The client sends its certificate, and proves it holds the matching private key by signing the handshake, exactly as the server did in module 5, just in the other direction.

Now both sides are proven before a single byte of real data moves. You’ll also hear it called mutual TLS, or mTLS.

Where would you want that? Anywhere the information is extremely sensitive: a financial trading application, say. And very often between systems, in integrations, where there’s no person to type a password at all. One system calls another, and the server wants to know, at the very first step, that the caller is a machine it issued a certificate to.

The server as its own certificate authority

Section titled “The server as its own certificate authority”

So where does the client’s certificate come from?

The server’s own certificate comes from a public certificate authority, as in module 4, because the whole world’s browsers need to trust it. But the server’s clients are a different matter. Steve’s Plumbing knows its own clients: its own staff’s machines, its partners’ systems. It doesn’t need the whole world to vouch for them. It can vouch for them itself.

So Steve’s Plumbing becomes its own certificate authority, just for its clients. It makes its own root certificate, and signs a certificate for each client. It can issue as many as it likes, for free. And when a client presents one, Steve’s Plumbing can check it instantly against its own root, because it issued it. No one else is involved.

One word of care here. You’ll often hear these client certificates called “self-signed”. Strictly, the root is the self-signed one; each client’s certificate is signed by that root. It matters when you read a system’s error messages, so it’s worth saying the right way.

Who makes the key pair

Section titled “Who makes the key pair”

Now a question with a right answer that has changed over the years. Who makes the client’s key pair?

The older way: the server made the whole thing, the certificate and the private key, and then had to get both to the client safely. Not by email. On a thumb drive, by hand, installed on the client’s machine. Installing that certificate gave the client the private key that nobody else should have. It worked. But the private key was made in one place, copied, carried and installed in another. For a while, it existed in two places at once.

Today’s way: the client makes its own key pair and keeps its private key. It sends the server only a certificate signing request: its name and its public key, and nothing secret. The server’s certificate authority signs that request and sends back the finished certificate. The certificate is public, so it can travel any way you like.

The private key never leaves the client. It’s the rule from module 2, the gold key never leaves home, applied to the client.

Two-way TLS: proving the client Three areas from left to right: the client (a system calling in), the network (the road) and Steve's Plumbing. In the first frame, the client makes its own key pair and keeps its private key, which never leaves; it sends a signing request, with its name and public key and nothing secret, across the network to Steve's Plumbing, which has its own certificate from a public authority for the world. In the second frame, Steve's Plumbing acts as its own certificate authority, with its own root just for its clients: it signs the request and sends back the client certificate, which is public and can travel; the client installs it beside its own private key. In the third frame, in every handshake, the client presents its certificate and signs the handshake with its private key, and that proof crosses the network. In the last frame, Steve's Plumbing checks the client against its own root and checks the signature: both sides are now proven. Underneath: the client makes its own key pair and sends only a signing request; the server, as its own certificate authority, signs it; in every handshake, the client proves it holds the private key. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-05", "id": "DGM-IAM-TR-09", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE CLIENT: A SYSTEM CALLING IN THE NETWORK: THE ROAD STEVE'S PLUMBING 1. Makes its own key pair keeps its private key · it never leaves Signing request the client's name and public key · nothing secret Steve's Plumbing its own certificate from a public authority, for the world 2. Its own certificate authority its own root, just for its clients · signs the request The client certificate signed by Steve's Plumbing's own root · public, can travel Installs the certificate beside its own private key 3. In every handshake presents its certificate · signs the handshake with its private key The client's proof its certificate and its signature 4. Checks the client against its own root · and the signature: both sides proven sends arrives signs and sends back arrives sends arrives The client makes its own key pair and sends only a signing request. The server, as its own certificate authority, signs it. In every handshake, the client proves it holds the private key. HOW TO READ IT the two ends the server's own certificate authority proving it holds the private key the check passes: both sides proven © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Calling out of Salesforce

Section titled “Calling out of Salesforce”

Now Salesforce. Start with the direction where Salesforce is the client: Salesforce calls out to another system, call it System B, and System B requires two-way TLS.

This is the pattern from this module exactly, with System B as the certificate authority and Salesforce as one of its clients:

  1. In Setup, Certificate and Key Management, Salesforce makes a key pair and a signing request. The private key stays in the org.
  2. System B’s certificate authority signs the request.
  3. You upload the signed certificate back into Salesforce.
  4. On each callout, Salesforce presents that certificate in the handshake.

There’s a simpler arrangement too. Salesforce’s own documentation puts it this way: “If you’re connecting to a third party and using a self-signed certificate, share the Salesforce certificate with them so that they can add the certificate to their keystore” (Using Certificates (opens in a new tab), Apex Developer Guide, Winter ‘27, checked 2026-10-31). Then System B trusts that one certificate directly.

Named credentials are where you attach the client certificate to the callout. And since the Winter ‘27 release, named credentials can also trust a server whose own certificate comes from a private certificate authority, not just a public one (Expand Integrations with Named Credentials Support for Custom CA Certificates (opens in a new tab), Winter ‘27 release notes, checked 2026-10-31).

Calling into Salesforce

Section titled “Calling into Salesforce”

Now turn it around: another system calls into Salesforce, and Salesforce requires two-way TLS. Here, Salesforce is the server, and the rules are stricter.

  • Public authorities only. The client’s certificate must chain to a root that Salesforce trusts, and it must be marked for client authentication. A certificate signed by the client’s own private root, or a self-signed one, isn’t accepted for this.
  • For the API, not the browser. It’s for system-to-system API connections. Signing in through a browser with a certificate is a separate feature (the Identity and Access course, chapter 15).
  • The setup, in short: upload the client’s certificate as a Mutual Authentication Certificate; give an API Only user the Enforce SSL/TLS Mutual Authentication permission; and the client connects to your My Domain address on port 8443.

Salesforce then checks twice: once in the handshake, that the chain leads to a trusted root; and again, that the certificate matches the one you uploaded for that user.

If you saw an older demo where a self-signed certificate was required on a profile for people signing in, this is the current picture: public roots, API Only users, port 8443.

Why it’s back in fashion

Section titled “Why it’s back in fashion”

For years, the usual way to lock down an integration user was to allow only certain IP addresses. On Hyperforce, Salesforce notes that IP addresses “change regularly”, and it presents mutual TLS as the alternative to IP allowlisting (Enhance Integration Security with mTLS for Salesforce and MuleSoft (opens in a new tab), Salesforce Developers Blog, October 2025, checked 2026-10-31). Prove the machine with a certificate, not with where it’s calling from.

And one dated change to watch. From 2026-06-15, Google’s Chrome Root Program began phasing out “multi-purpose roots”: the public roots Chrome trusts are for server certificates only, and new intermediate certificates under them may assert only server authentication (Chrome Root Program Policy (opens in a new tab), version 1.8, checked 2026-11-07). So public authorities are moving client certificates to separate hierarchies, and one certificate that does both jobs is on its way out. Plan separate certificates for each job.

What’s left

Section titled “What’s left”

You now have every piece: shared keys, key pairs, signatures, certificates and the chain, the handshake, and trust in both directions. One thing is true of every certificate in this chapter, on both sides: it has an end date. Module 7 is about what happens when it arrives.

What an architect decides here

Section titled “What an architect decides here”
  • One-way or two-way? Two-way TLS for system-to-system integrations that must prove the caller before anything else, and anywhere a stolen password alone mustn’t be enough.
  • The client makes its key pair. Signing requests, not delivered private keys.
  • Know the rules by direction. Calling out: the other system’s authority, or Salesforce’s own certificate. Calling in: public roots only, API Only users, port 8443.
  • One certificate per job. Client and server certificates are separate, and since 2026-06-15 public authorities are splitting them anyway.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.