Loading
Upcoming Mandatory Changes to Public Key Infrastructure (PKI)Read More
Salesforce Enforces New Security Requirements in Summer 2026Read More

Salesforce SSL/TLS Certificate Trust: Supported Root CAs, Client Authentication, and Available Tools

Publish Date: Jun 11, 2026
Description

Salesforce trusts only root certificate authority (CA) certificates when handling SSL/TLS connections for outbound callouts and inbound integrations. This article explains which certificates are supported when Salesforce acts as a client (making outbound callouts), when Salesforce acts as a server (SSO/SAML), and how client authentication certificates are configured for mutual TLS (mTLS).
To review the current list of trusted root CAs for your org, append /cacerts.jsp to your Salesforce org hostname (for example: https://login.salesforce.com/cacerts.jsp).
If the root CA you plan to use is not in the supported list, raise a support request before using certificates chained to that root CA. Salesforce uses well-known CA trust stores such as the Mozilla Root Store and the Federal PKI graph as a baseline to evaluate requests to add root CAs. Presence in these trust stores does not guarantee acceptance — Salesforce evaluates each request on a case-by-case basis.

Resolution

Salesforce Acting as the Client

When sending outbound messages, delegated authentication requests, or Apex callouts to secure HTTPS endpoints, Salesforce trusts the target host only if it presents a certificate signed by a CA that is subordinate to one of the root CAs in the supported cacerts list. Self-signed certificates are not allowed for the target host in this scenario.
Salesforce requires certificate chains to include all intermediate certificates between the server or client certificate and the root certificate. Salesforce will not honor requests to add intermediate certificates to its trust list.
Note on Entrust Certificates: Certificates issued by Entrust are no longer trusted by major browsers. Before migrating to another CA, check if the new CA is supported by your Salesforce instance. Entrust certificates issued on or before November 11, 2024 continue to be accepted in Chrome until expiry. Mozilla browsers trust Entrust public TLS certificates issued on or before November 30, 2024 until expiry.
When using mutual authentication (2-way SSL/mTLS), Salesforce can present a self-signed certificate to the target host, provided that certificate has been configured (installed) in the target server's keystore.

Salesforce Acting as the Server

When a Salesforce org is Single Sign-On (SSO) enabled using SAML, the org plays the role of the Service Provider (SP). In this case, Salesforce acts as the server and the configured Identity Provider (IdP) acts as the client. In this scenario, the IdP is allowed to present a self-signed certificate.

Client Authentication

When sending outbound messages, delegated authentication requests, and SAML assertions (both SP-initiated and IdP-initiated flows), Salesforce presents the CA-signed or Self-Signed certificate configured under Setup > Security Controls > Certificate and Key Management > API Client Certificate.
For Apex callouts, you can specify which certificate Salesforce presents to the target host from the list at Setup > Security Controls > Certificate and Key Management. Use a Common Name for the cert that you control — for instance, something rooted in your own domain (for example, mycompany.com). There is no need to obtain a certificate in the salesforce.com domain.

Available SSL Tools

To verify the certificates returned during an SSL handshake, use the following OpenSSL command from the command line. Replace <host> and <port> with the target server's hostname and port number (typically 443 for HTTPS):

openssl s_client -showcerts -connect <host>:<port>

To decode and inspect SSL certificates, use SSLShopper Certificate Decoder.
To graphically view all certificates returned during the SSL handshake, use DigiCert SSL Checker.

Knowledge Article Number

000385468

 
Loading
Salesforce Help | Article