Know more about all the SSL certificates that are supported by Salesforce

Salesforce acting as the client

When sending outbound messages, delegated authentication requests or Apex callouts to secure/SSL endpoints (e.g. https://myintegration.acme.com), a Salesforce.com organization (acting as the client) will trust the target host (that will act as the server) only if it presents a certificate signed by a certification authority (CA) that is subordinate to one of the root CAs included in the list shown in the cacerts.jsp link provided below. In other words, in this scenario self-signed certificates are not allowed to be used by the target host.

Salesforce trusts only root certificate authority (CA) certificates, with few historical exceptions. Salesforce's certificate trust policy is to require server and client certificate chains to include all intermediate certificates that exist between the server or client certificate and the chain's root certificate. Salesforce will not honor requests to add intermediate certificates to its trust list. Salesforce trusts many generally trusted root certificates, but not all.

To review the current list of supported root certificates you can append /cacerts.jsp to your Salesforce organization hostname https://login.salesforce.com/cacerts.jsp(e.g. https://trailhead.my.salesforce.com/cacerts.jsp). If the root certificate authority (CA) that you are planning to use for your service is not supported, raise a support request to Salesforce before starting to use the certificates chained to this root CA. Salesforce will use well known CA trust stores such as Mozilla's Root Store and the Federal PKI graph as a baseline to evaluate requests to add root CAs. You must note that the presence of a root CA in one of these well known trust stores does not guarantee that your request will be accepted. Salesforce will evaluate your request and make a decision on a case-by-case basis. Additionally, test in a sandbox environment before making a change to production. SSL/(m)TLS Connections will fail if a root CA is not trusted by your Salesforce instance.

Certificates issued by Entrust, a prominent Certificate Authority (CA), are no longer trusted by well-known internet browsers. Before you migrate to another CA, check if the new CA is supported by your Salesforce instance. Certificates from Entrust issued on or before November 11, 2024 will continue to be accepted in Chrome browsers until expiry. Mozilla browsers will trust Entrust public TLS certificates that were issued on or before November 30, 2024 until expiry.

When using mutual authentication/2-way SSL, Salesforce.com can present a self-signed certificate to the target host (that must present a CA signed certificate to Salesforce), provided that this certificate has been configured in the target host (installed in the target server's keystore).

Salesforce acting as the server

When a Salesforce organization is Single Sign On enabled using SAML, the organization 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, and it's allowed to present a self-signed certificate.

Client authentication

When sending outbound messages, delegated authentication requests, and SAML assertions (both in the SP and IdP initiated flows), Salesforce will present the CA-signed or Self-Signed certificate configured under Setup | Security Controls | Certificate and Key Management | API Client Certificate.

On the other hand, Apex callouts may specify which certificate (from the list found at Setup | Security Controls | Certificate and Key Management) will Salesforce present to the target host. You need to use a Common Name for the cert that you control - for instance something rooted in your own domain (e.g. mycompany.com). There is no need to try and get a certificate in the salesforce.com domain.

Available SSL tools

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