Customers who use the Salesforce serves the domain over HTTPS on Salesforce's servers using your HTTPS certificate option for their Salesforce Experience Sites or Salesforce Sites are actively being migrated from a legacy infrastructure to Salesforce Edge Network.
To provide the correct certificate for incoming custom domain requests, Salesforce Edge Network requires web browsers and API clients to include the SNI (Server Name Indication) extension in the TLS ClientHello message when requesting custom domains. SNI is a TLS (Transport Layer Security) extension that allows a client to specify the hostname it is attempting to connect to during the TLS handshake. TLS is the cryptographic protocol used to secure HTTPS connections.
For most Salesforce customers, certificate handling is transparent. Modern web browsers consistently include SNI in their TLS ClientHello messages as part of the TLS handshake with Salesforce Edge Network. In the absence of SNI, Salesforce Edge Network returns a default certificate that supports all .my.salesforce.com and .sandbox.my.salesforce.com hostnames. This may cause users to experience TLS handshake errors in the following scenarios:
In both situations, Salesforce returns an HTTPS certificate that does not cover the expected custom domain, resulting in an HTTPS certificate hostname mismatch error.
Users or API clients suddenly start receiving an error or exception in the TLS handshake. For example, an API client or third-party CDN reports an "SSLHandshakeException" after sending a request to a Salesforce custom domain that uses the Salesforce Cloud HTTPS option.
First, confirm if requests for custom domains are going to Salesforce Edge Network. Open a command prompt and run the appropriate DNS lookup command for your operating system.
On Mac (Terminal): Run the dig command with your fully qualified domain name (FQDN). Replace [YourFQDN] with your actual custom domain name, and [Your18charOrgId] with your 18-character Salesforce Org ID, which is visible at the top of the Add Domain page in Setup. You can also run the dig command against the full siteforce.com path format using your domain and Org ID.
On Windows (Command Prompt): Run the nslookup command with your custom domain FQDN. You can also use the full siteforce.com path format with your domain and Org ID.
If Salesforce Edge Network has been enabled for the custom domain, the output contains references to "edge" or "edge2." If SNI is being sent and you still see the issue, contact Salesforce Support to open a case.
The solution depends on where the error occurs.
Modify the API client caller to include SNI in its TLS ClientHello message. Most modern HTTP client libraries support SNI by default. Check your API client's documentation for instructions on enabling SNI for outbound HTTPS connections.
Some Salesforce Experience Sites use custom domains served by a third-party CDN that forwards requests to Salesforce servers. The error occurs between the CDN and Salesforce Edge Network when a user attempts to visit the site.
If the CDN's default error page does not mention the TLS error, check the CDN's error log. Otherwise, configure the CDN to include SNI when making a call to Salesforce Edge Network.
As an alternative, Salesforce provides the option to configure your CDN to communicate directly with the origin. Consider enabling the "A non-Salesforce host or service serves this domain over HTTPS" option to serve your custom domain instead of forwarding requests to Salesforce Edge Network.
Salesforce Edge Network Overview
Add Domain – Salesforce Help
Non-Salesforce HTTPS Domain Option
000389364

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.