Find your content:

Search form

You are here

Sites/Portals and SSL


Most of my clients who ask for a public portal or site on salesforce want two things:

  1. SSL
  2. personally branded site

They like being able to manage everything through salesforce but they dont want their public image affected by salesforce specific url strings etc.

The solution I have typically put forth is to put an ngnix/apache proxy in front of the site.

This solution also allows for the url to go from this <customer.urn> => someting.<customer.urn>

does anyone have another solution that works for them, maybe something on platform?

Attribution to: ebt

Possible Suggestion/Solution #1

So for SSL with salesforce sites it seems that the way to go is still a reverse proxy.

Attribution to: ebt

Possible Suggestion/Solution #2

In Sites, there is a functionality to use a Custom Web Address which will let you specify your own domain. For example:

Instead of: "" You can use: ""

However, this solution doesn't allow SSL, meaning you can't do https. If you go to the https custom url, e.g. "", then you'd get a certificate warning.

I know there are a few pilot customers who are working with Salesforce to trial a SSL version of the custom web address. Your clients should talk with their Salesforce reps to find out if they can do this for their sites.

Attribution to: Addison

Possible Suggestion/Solution #3

The historic difficulty with allowing SSL with custom web addresses is that the SSL negotiation takes place based on IP addresses. Thus the SSL certificate has to be bound to a specific IP address and presented when a client makes an SSL connection to that IP address. Name based hosting, which allows a site to represent itself as a custom address is a feature of HTTP(S), as the name is encoded in the HTTP request headers, but these aren't presented until the SSL connection is established. Thus SFDC would need to provide a unique IP address to for every site that used SSL and custom web addresses, something that is unlikely to scale.

Server Name Identification solves this problem by adding the hostname to the SSL handshake, but for this to work both the browser and server need to support it and a lot of older browsers don't. The problem here is that if the browser doesn't support SNI, it gets the default certificate for that IP addresses, which raises a security alert, which is probably a worse user experience than using

Attribution to: Bob Buzzard
This content is remixed from stackoverflow or stackexchange. Please visit

My Block Status

My Block Content