Home / server / Questions / 285680
Accepted
mdrozdziel
Asked: 2011-07-01 01:01:01 +0800 CST

What is the technology behind Hostname Based SSL (multiple ssl vhosts on single IP)?

  • 772

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?

apache-2.2 ssl web nginx heroku

2 Answers

  1. Best Answer

    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.

    • 7

  2. 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 1.2.3.4 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 1.2.3.4 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.

    • 0