Well known PaaS provider Heroku offers multiple solutions to SSL problem. One of those is a product called Hostname Based SSL

This is not SNI. They claim it works on every browser in any configuration but has other drawbacks, mainly (quoting the docs):

  • Hostname based SSL will not work with root domains as it relies on CNAME aliasing of your custom domain names.

  • Hostname SSL works with one domain only. For example, www.domain.com would work, but if a second certificate for secure.domain.com is added to the application it will not work.

  • Our hostname-based SSL offering currently strips some HTTP headers; this can be a problem when your app needs to look at the IP of the client, for instance.

Using this custom build solution Heorku can serve multiple SSL sites on a single IP address and as they claim it will work across anything.

Can anyone explain technical side of this solution and technology behind this product?

2 Answers 2


It's not quite what you think. Heroku is not serving up multiple SSL certs on a single IP address. If you perform an nslookup against different Hostname SSL deployments, for example, you will find that they each point to a different Amazon ELB. Therein lies the secret sauce.

When a customer requests Hostname-based SSL, an ELB is provisioned for them and the customer is asked to CNAME to that ELB's hostname. Those ELBs connect back into the Heroku routing mesh as appropriate.

I hope that clears some things up. Feel free to ask more questions.

  • Well, everything adds up pretty nicely here. SSL hosts are indeed pointed to ELBs and the pricing of SSL Hostname resembles the ELB price list as well. Thank you for the clarification. No magic here unfortunately. Explanation and price for IP based SSL on Heroku mislead me a bit and suggested that Hostname SSL is some kind of trick. What it is in reality - just a fancy way of getting another IP address pointed towards a single EC2 instance.
    – mdrozdziel
    Jul 2, 2011 at 8:01

I do not know, so I have to speculate. This could work as a result of an interaction between Heroku's own DNS servers and HTTP servers. The flow might go like this:

  1. The client is requesting https://www.yourdomain.com
  2. The client's DNS resolver resolves www.yourdomain.com as a CNAME to a RR on heroku's name servers (e.g. app1234.apps.heroku.com)
  3. The client's DNS resolver queries the A RR for app1234.apps.heroku.com from the name server for apps.heroku.com
  4. The name server for apps.heroku.com hands out an address and notifies the corresponding web server of a client at IP address requesting the host www.yourdomain.com
  5. The client initiates an SSL connection handshake to app1234.apps.heroku.com
  6. The HTTPS server, knowing that the client at is going to request www.yourdomain.com as the site, selects the correct certificate for www.yourdomain.com and proceeds with the SSL handshake

The flow might break in some scenarios, especially with many requests for different sites originating from a single IP address (as would be the case for clients behind a proxy or a NAT gateway), but this could be "evened" out by spreading the requests for different destination hosts from a single source IP among many HTTPS servers, so a single HTTPS server would not have any ambiguity when deciding which certificate to choose for a given client.

  • +1 As a theory, sounds pretty reasonable.
    – Chris S
    Jun 30, 2011 at 17:37
  • Not sure how you expect the DNS resolver to pass the IP address of the client to the name server.
    – mr-euro
    Nov 7, 2011 at 20:08
  • This would obviously need modifications of the DNS server software and some side-channel protocol for communicating with the web server software. It would also be evil(tm) and would need some cludges to work around DNS caching.
    – the-wabbit
    Nov 11, 2011 at 20:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .