If you've read one of my previous articles I developed a bespoke CMS a few years back for our agency which has worked extremely well for both our agency and the clients we have, a long story short - it allows us to build web sites quickly, easily and with whatever a client needs much faster than we used to.
However, one of the major problems was creating and managing SSL certificates for the new web sites we created. Initially it was a manual process and we wanted a far better solution and so we created our own SSL/reverse proxy server.
How it works
Our bespoke CMS gives every web site a temporary sub-domain depending on which reseller is using our CMS. Let's say we have a new reseller called Blue Pixel and they have our CMS platform running under the domain blue-pixel.com. Every site created will get a new sub-domain such as marys-berries.blue-pixel.com and the site can be used if they wish as-is. If the client wants to use a real domain such as marys-berries.com the client will point the domain to our SSL/reverse proxy server.
Client domain > SSL/reverse proxy server > CMS platform
Once the traffic starts to flow from the client domain to our proxy server it will attempt to create a new SSL certificate and once generated (a matter of seconds) the traffic is then pushed on to the CMS platform, all subsequent traffic is pushed to the CMS platform without delay.
Our proxy server continually monitors the status of generated SSL certificates and when required will automatically renew them behind the scenes.
A problem and a solution
This is how we generally work. We have a problem which needs a solution, how can we get a quick win to take the pressure off and how can we build something for the longer term.
In this scenario we created the proxy server but manually added the domains to the configuration file when a new site was created for our quick win.
Later, we added an admin area within the proxy server to allow us to manage the domains and where they were pointed. So for example, we have and "endpoint" for every reseller which is where the traffic eventually gets pushed to, in this case the reseller was Blue Pixel (blue-pixel.com). Each endpoint then has multiple domains, one (or more) for each web site created on the CMS platform.
We then changed the proxy server to check with the admin to see if the domain was a valid domain and which endpoint it belonged to. This allowed us to forward any domains to the proxy server but it would only generate SSL certificates and forward traffic for these valid domains.
This allows us to tell clients to point their domains to the proxy server once we have set it up in the admin area, once the DNS has updated the site is automatically served with an SSL certificate and traffic is forwarded to the correct end point.
What's next?
The admin area is now open to the public to allow them to use the service for their multi-tenant platforms (ssl-saas.com) and a new API has been built to allow the CMS platform or other platforms to automatically add endpoints and domains.
