The Transport Layer Security (TLS) protocol serves as a prevalent mechanism for encrypting communications across networks and is fundamental to the operation of Hypertext Transfer Protocol Secure (HTTPS). As the successor to the now-obsolete Secure Socket Layer (SSL) standard, TLS has become integral to secure network communications.
By default, one-way (standard) TLS is implemented without necessitating additional configuration within a Salesforce organization, thereby facilitating HTTPS communication through web browsers and ensuring HTTPS encryption for both inbound and outbound integrations with external systems.
In contrast, Mutual TLS introduces an elevated level of trust verification through client authentication for inbound integrations. The configuration of Mutual TLS within Salesforce can be accomplished by adhering to the specific procedural steps delineated in the subsequent sections.
It is essential to recognize that both TLS and Mutual TLS provide security at the network layer and are not inherently linked to user authentication processes. Typically, integrations secured by TLS or Mutual TLS are expected to additionally mandate user authentication. This user authentication process is conducted over HTTPS, often utilizing an OAuth flow or a similar authentication mechanism to ensure robust security measures are in place.
Standard TLS (One-Way)
Transport Layer Security (TLS) operates at the network layer and serves as a precursor to all HTTPS traffic, which includes user authentication processes. The client in this context may be either a web browser or a client application engaged in server-to-server integration.
One-way TLS is instrumental in safeguarding against server impersonation, as it allows the server to authenticate its identity to the client by demonstrating possession of its private key. The primary objective of this protocol is to establish a secure connection between the client and the server through the creation of cryptographic keys that ensure the protection of data during transmission.
The session key necessary for HTTPS is derived from a combination of the pre-master key, as well as random numbers generated by both the client and server. Both parties are required to have access to these elements in order to produce matching keys. The server’s identity is confirmed by its capability to decrypt the pre-master secret, thereby generating a session key that corresponds with the one created by the client.
When Salesforce functions as the client (for example, during an Apex callout), it is imperative that Salesforce only accepts a certificate signed by a Certificate Authority (CA) from the server. Conversely, when Salesforce acts as the server (such as in an Apex REST service), it presents its own CA-signed certificate. This certificate is managed by Salesforce and is independent of the customer’s organization.
Mutual TLS
Mutual Transport Layer Security (MTLS) enhances security by necessitating that the client authenticate its identity to the server, in addition to the server validating its identity to the client. This mechanism effectively ensures that the appropriate server application is accessible exclusively by the designated client applications. This is particularly pertinent in the context of Software as a Service (SaaS) applications, which often share the same infrastructure, domain name, and IP ranges, thereby mitigating risks associated with attacks that exploit alternative instances of public cloud applications.
MTLS, typically implemented at the network layer, is frequently utilized in conjunction with OAuth authentication and authorization flows, which occur at the application layer. This combination provides an additional layer of security. In this framework, the client’s identity is established through the server’s verification of the signature contained within the CertificateVerify message, which reflects the transcript of interactions up to that point and is signed with the client’s private key. Similar to one-way TLS, the server’s identity is verified through its ability to generate a corresponding session key.
When Salesforce operates as the client (for instance, during an Apex callout), it will only trust a certificate that has been signed by a Certificate Authority (CA). Salesforce has the capability to present either a CA-signed or a self-signed certificate. For Apex and Named Credentials callouts, any certificate within the organization can be specified. However, for outbound messages, SAML assertions, AJAX proxies, and delegated authentication, the certificate utilized will be the one designated as the API Client Certificate in the Certificates and Key Management section.
Conversely, when Salesforce functions as the server (for example, in an Apex REST service), it will only accept a CA-signed certificate from the client. This certificate must be uploaded to the organization’s truststore, which serves as the repository for accepted MTLS certificates. Salesforce will present a certificate that is CA-signed and managed independently by Salesforce, distinct from the customer’s organization.
To facilitate a connection, a client must access the My Domain login URL via port 8443. To establish MTLS with Salesforce serving as the server, the following steps should be undertaken: Submit a support ticket to Salesforce; grant the “Enforce TLS/SSL Mutual Authentication” and “API Only User” permissions to the Integration User; and upload the client’s CA-signed certificate to the Mutual TLS section under Certificate and Key Management in Setup, effectively integrating it into the Salesforce organization’s truststore.
