Virtual hosts work based on host/server names. Examples of hostnames are example.com, eazybusiness.com, and blogger.com. The hostname provided by the client browser determined what one of its web sites the webserver servered to that client.
In order for a website to be able to offer the security of HTTPS, it must provide its own unique SSL certificate. This SSL cert is proof of the site's authenticity, and forms part of the protocol used to secure the communication between a user's browser client and the webserver.
The conflict between virtual hosts and HTTPs lies in the fact that the SSL protocol (the 's' in HTTPs) does not include the need for the client to pass the hostname to the server during initiation. This missing information means that if a webserver hosts multiple websites, each with their own SSL certificate, it does not know which SSL certificate to use.
Recently browsers and websites have starting supporting a technology called SNI. SNI enables the hostname to be included part of the SSL protocol. SNI works, and solves the conflict perfectly, but unfortunately the prevelance of older browsers makes using it impractical.
An alternative solution is to use multi-domain certificates. Using multi-domain certs means that all the web sites sharing a webserver can also share the one certificate. The webserver then only has the one certificate to use, and so does not need to know information about the hostname when establishing an SSL connection. This solution works, but these certificates can be expensive and come with a number of limitations:
- There is generally a limit to the number of websites a multi-domain cert can accomodate (usually around 100)
- Multi-domain certificates do not accomodate wild-card certificates
An third possible solution to this problem is to use a proxy, and have each website operate on a different port. My next post will contain a solution to the multiple https websites on Amazon's AWS.