SaaS companies like ours often offer white labelling with “vanity domains” to their clients, so that the services that they provide are essentially invisible to client end-users.
You can see this concept in action here – the guide you’re looking at is a Nickelled guide, served from Nickelled servers, but appearing as if it belongs to one of our favorite clients, Gumtree. Note the specific subdomain - guides.gumtree.com is an address that’s set up to redirect straight to Nickelled.
Look hard, and you’ll realize this is all over the web – from landing page software to survey software to fundraising software to CRM systems to help desk software to human resource management systems.... The list goes on.
Look a bit closer though, and you’ll notice a real problem:
As the world has transitioned to SSL, whitelabelled domains have been left behind.
A large number of these services don’t support secured domains, because of the technical complexity of doing so – SSL requires the presence of a certificate when a request is made, which essentially assures the browser that it is communicating with the server it thinks it is.
Fail to include an SSL certificate, and your clients’ pages will display with this error:
Google in particular has been ruthless about mandating SSL through its two huge products (Search and Chrome), confirming earlier this year that it would prioritize secure websites over insecure websites in search results, as well as loudly blocking insecure sites in Chrome. Worst case, pages end up looking like this:
We hit this problem at Nickelled about four months ago, and our infrastructure team initially sketched out three tried-and-tested options which are commonly used by SaaS businesses:
- We ask our clients for an SSL certificate and host it on our servers
- We ask our clients to set up a “reverse proxy” on their servers which secures the connection and then forwards the request to our servers once it’s secured
- We build an in-product integration to an SSL/TLS certificate provider to allow us to create SSL certificates when clients request custom domains - our estimation was that this would probably take about two weeks of development time, which works out as an investment of about $25k.
None of these options seemed particularly appealing, requiring effort on our clients’ side, our side, or both. Number one would have required development but also appeared to be a compliance nightmare (sharing SSL certificated is risky, as if an organization has access to the SSL/TLS certificates for Google, for instance, it can pretend to be Google anywhere on the web).
Technical nb: It quickly became apparent that this solution would not work for us because existing cloud load balancers and CDNs lack the visibility and control required to manage SSL at the volumes we required, and in a way that avoided a considerable operational burden on our tech team!
Number two was quickly rejected, not least by one client who was less than enthused about including “set up a reverse proxy” in his dev team’s latest sprint!
Building an integration ourselves seemed like the most obvious option – until we delved a little bit further into things. Not only would we need to figure out how to provision these certificates, we’d have to write logic for setting up the domains to look for. We’d need to handle errors from clients who’d misconfigured their DNS setup, and we’d likely need the ongoing time of a CSR to support clients in getting things set up with the new system. It was possible, but it didn’t seem like the best solution.
Delving further into our requirements, we realized that the ideal SSL/TLS solution for SaaS would have to meet some tough requirements:
- We should not have to store wildcard SSL certificates
- Our clients should not have to build any infrastructure
- Ideally, they should not have to make any configuration changes to get SSL to work
- The solution should work for a large number of clients who have already pointed their domains at our non-secure endpoint (so we don’t need to ask them all to go back and reconfigure DNS settings)
- We shouldn’t need to provision new infrastructure
- There must be zero downtime for the existing non-secure connections
- The solution should be scalable
- Provisioning should be automatic
None of the options laid out above would have worked, so we ended up building a fourth solution – and we’re calling it Qloaked.
Qloaked blends elements of solutions two and three above to create a service that can handle both insecure and secure requests, provision SSL/TLS certificates on the fly, and automatically redirect all traffic to a secure connection once one can be offered.
Most importantly, it requires zero changes from clients to get it to work. Clients were already pointing their vanity domains at a destination such as clients.nickelled.com and could continue to do so.
However, we could then forward these requests through to Qloaked, which can relay them insecurely until it has generated an SSL/TLS certificate, at which point it will force all traffic to use https, securing the vanity domain connection with no changes required by anybody.
For the technically-minded readers: yes, what we’ve built is essentially a reverse-proxy-as-a-service, with some clever tweaks to handle multiple hosts and end points.
Qloaked constantly listens for traffic passing through the server, paying attention to the hostname it’s originating from. When it detects that a new host (essentially, a new white label client of ours) has entered the mix, it automatically tries to provision an SSL/TLS certificate for that host, ticking the required checkboxes from the provisioning authority. When the certificate is provisioned, it seamlessly moves traffic across to a secured connection.
Building it, it became clear that connections secured this way offer some valuable advantages over what most SaaS providers can offer right now.
Qloaked connections are more secure, thanks to the 90-day validity and automatic rotation of certificates provisioned though LetsEncrypt. Nobody needs to worry about the liability of handling SSL/TLS certificates. And perhaps most importantly, the service is essentially invisible to a SaaS company’s clients and their end-users (even during setup) – some neat auto-detection technology means that zero configuration is required, so new clients can be on-boarded immediately without the help of a CSR.
We’ve now rolled out Qloaked to secure the majority of Nickelled’s whitelabelled clients, and we’re in talks with several other SaaS companies to secure their client sites and landing pages too. To better respond to the interest we’ve had, we’ve set up a landing page at www.qloaked.com – check it out and let us know what you think.
If you think we can help you, get in touch - email email@example.com and we’ll be happy to have a chat about making the web a safer place for you and your clients.