One SSL certificate for a varying number of multiple web-servers (not directly)

Question

First of all, I only used StackOverflow so far and was just guessing this is the right place for my question.

This is a fairly straight forward but not very simple situation, so I'll do my best to keep the explanation short.

---

We are building a mobile application that obtains content from web-servers. Majority of the content is 'protected' meaning that only authorized users can access it on a subscription bases. We need all communications between device and server (and between CMS user and server) to be encrypted.

There is one server for CMS and one for API. (Devices access content via API but CMS activity may become quite heavy sometimes so it's separated to not affect load on the API server + the API server is further load-balanced but this latter doesn't fall into the scope of my question.)

Both the CMS and the API servers need an SSL certificate which is quite costly especially considering that we release new versions frequently but, because it's not possible or we don't want to force high number of users to upgrade their client, different versions need to run in paralell. Differences between versions may be so major that handling different versions from within one CMS/API is out of question. This means 2 certificates (and of course 2 servers) per version. Some version, however, may be quite short lived but SSL certificates are minimum for one year so it's not cost effective.

---

We outlined a "strategy" and I'd like to ask for expert advice/opinions about the viability, efficiency and any drawbacks you may think of.

The idea is to have one server acting as a special "proxy", buy only one SSL certificate and install it on this server. Then, using Apache's mod_rewrite or possibly other techniques, implement a solution that allows all traffic (CMS and API) for all versions to hit this proxy and have (according to the above, not taking load-balancing into account for now) 2 nodes per application version behind it accessible only locally by the proxy.

The proxy would access the right node based on some parameters of the incoming request. For example, say the domain name is myapp.com, then we would have requests like

myapp.com/cms-1-2/...
myapp.com/api-1-2/...
myapp.com/cms-1-3/...
myapp.com/api-1-3/... and so forth.

This way, there's no need to buy more expensive certificates that include mutiple cnames or that are for physically different servers or buy new ones for new versions' servers.

Can you highlight any obvious drawbacks we didn't think of?

Answer 1

If I am understanding correctly, this is a common way Apache is used as a reverse proxy. You could just use mod_proxy_http (or mod_proxy_balancer if you need to load-balance your app servers) to do what you want to do. One thing that could be viewed as a drawback is that any time you need to add new ProxyPass & ProxyPassReverse endpoints to your apache configuration, you would need to restart Apache, (which could be disruptive to the site).

You could also buy a wildcard cert and deploy as many *.domain.com instances your CA's license for the wildcard certificate allows and spin them up and tear them down as often as you like.