Introducing SSL for SaaS

If you’re running a SaaS company, you know how important it is that your application is performant, highly available, and hardened against attack. Your customers—and your revenue stream—depend on it. Putting your app behind a solution such as Cloudflare is an obvious move for your own infrastructure, but how do you securely (and easily) extend these benefits to your customers?

If your customers interact with your app on your domain and don’t care about branding under their custom or “vanity” domain (or aren’t paying you for the ability to do so), the solution is straightforward: onboard your domain to Cloudflare and serve the app at either https://app.yourcompany.ltd or https://yourcustomer.yourcompany.ltd. But if your customers want to host your application, portal, content management solution, etc. on their own domain for improved SEO and discoverability, e.g., https://app.yourcustomer.site the solution is not so easy.

Until today, your best bet was to ask them to CNAME over to your infrastructure, have them generate a private key and CSR, send the latter to a CA for signing, and then securely provide you with the key material (and again upon renewal). Or maybe you have engineering resources to spend and can build and maintain a solution to generate and securely store private keys, acquire and renew certificates, and push them to a CDN so TLS can be terminated in a performant manner (i.e., as close to your customers’ users as possible). Whichever route you choose, the technical complexity and burden of maintenance is high—either for your customers or your engineering and support teams.

SSL for SaaS was built with these difficulties in mind, and solves them with the simplicity that you and your customers expect. With SSL for SaaS, you can now send a single API call as part of your onboarding workflow and extend all the benefits of Cloudflare to these custom domains. All your customer has to do is add the initial CNAME into your domain.

Once the CNAME is in place and the API call is made, Cloudflare takes care of the rest. We’ll provision the hostname at our edge for forwarding on to your specified origin, acquire SSL certificates to enable HTTPS and HTTP/2, and sit in front of any DDoS or L7 attacks that may target your customers. All the benefits of Cloudflare, including CDN and content optimization, are extended to your customers’ hostnames without them having to do anything other than adding a DNS record.

Imagine that your company offers a support application that customers can white label and serve from their own domain. Whichever hostname they choose, e.g., support.yourcustomer.site or help.yourcustomer.site, you should instruct them to CNAME to a hostname of your choosing, e.g., whitelabel.yourcompany.ltd.

This white label hostname should be set up within your DNS dashboard as an A/AAAA or CNAME record pointing to your origin. Alternatively, you can use a pool of origins to load balance across. Once that record is in place, you can start instructing customers to CNAME their custom hostname to it. Or if your customers already have CNAME records in place, we can mirror that existing structure so that you don’t have to go back to your customers and request they make a change.

In the example below, we show how support.yourcustomer.site, a hostname of your customer with a CNAME pointing to whitelabel.yourcompany.ltd, can be provisioned and live at our edge with SSL certificates in just a couple of minutes.

Confirm the customer's CNAME is in place

$ dig CNAME +short support.yourcustomer.site
whitelabel.yourcompany.ltd.

Alternatively, you can add the CNAME after requesting certificate issuance, but it’s faster if you have it in place to begin with. If you need the certificates issued and live prior to your customer pointing their hostname over, consider using email-based validation.

Demonstrate basic HTTP connectivity (and show expected HTTPS error)

With the CNAME in place, we show that HTTP connectivity to our origin is returned as expected and that HTTPS fails (again, expected) due to a certificate error. The reason the connection fails is that Cloudflare is serving the wildcard certificate for *.yourcompany.ltd, as you haven’t yet told us to get a certificate for app.yourcustomer.site.

$ curl http://support.yourcustomer.site
Hello, support.yourcustomer.site! This response is being served from whitelabel.yourcompany.ltd.

$ curl https://support.yourcustomer.site 2>&1|grep chain
curl: (60) SSL certificate problem: Invalid certificate chain

Make single API call to request SSL certificate issuance

Now that the customer CNAME is in place, all you need to do is send us a single API call with the custom hostname to let us know we should expect to terminate TLS traffic there. We’ll take care of the rest.

curl -sXPOST -H "X-Auth-Key: [YOUR KEY]" -H "X-Auth-Email: [YOUR EMAIL]" -H "Content-Type: application/json" https://www.cloudflare.com/api/v4/zones/[YOUR ZONE ID]/custom_hostnames \
-d '
{ "hostname": "support.yourcustomer.site",                         
      "ssl": {
        "method":"http",
        "type":"dv"
      }
}' 

Demonstrate your customer’s site is accessible over HTTPS

That’s it! Within a couple of minutes we’ll have validated that hostname with our CA partner, requested two types of certificates be issued—SHA-2/ECDSA signed for modern browsers that support elliptic curve cryptography and SHA-2/RSA to maintain compatibility with older browsers—and pushed it to all 110+ PoPs that comprise our edge.

$ curl https://app.yourcustomer.site
Hello, app.yourcustomer.site! This response is being served from whitelabel.yourcompany.ltd.

Your customer’s customers can now securely access their white labeled version of your application over HTTPS and take advantage of all the benefits it enables, such as the HTTP/2 protocol. These certificates and their keys are issued uniquely to your customer’s hostname (i.e., not co-located with any other customers), and served globally from a PoP close to your customer’s visitors.

Yes, we encourage you to use the Full or Strict SSL mode so that traffic sent to your origin utilizes HTTPS. This option can be configured in the Crypto tab of your zone. If you’re using Strict mode, you must ensure that the certificates on your origin contain a Subject Alternative Names (SAN) that matches your customer’s hostname, e.g. support.yourcustomer.site. Our Origin CA product can be used to generate these certificates for use with Strict mode.

Certificates are typically validated, issued, and pushed to our edge within a few minutes. You are able to monitor progress through the various states—Initializing, Pending Validation, Pending Issuance, Pending Deployment, Active—by making a GET call.

$ curl -sXGET -H "X-Auth-Key: [YOUR KEY]" -H "X-Auth-Email: [YOUR EMAIL]" https://www.cloudflare.com/api/v4/zones/[ZONE ID]/custom_hostnames?hostname=support.yourcustomer.site

{
  "result": {
    "id": "cdc2a12a-99b3-48b8-9039-ad1b48c639e5",
    "hostname": "support.yourcustomer.site",
    "ssl": {
      "id": "3463325d-8116-48f3-ab4e-a75fb9727326",
      "type": "dv",
      "method": "http",
      "status": "active"
    }
  },
  "success": true
}

No, we take care of all of this for you. The certificates we issue are valid for one full year (365 days) and will be renewed automatically at least 30 days prior to expiration. These certificates are uniquely issued in your customer’s hostname and, so as long as the CNAME is still in place, we can continue to easily renew by demonstrating “domain validation control” of that hostname. If the customer has churned, we encourage you to send us a DELETE request so we can pull the certificate from the edge and not attempt to renew.

With the exception of protecting your customers’ DNS infrastructure (unless they’re also using us for authoritative nameservice), the short answer is: all of them. Once their traffic is pointed to your white label hostname, we are able to provide our industry leading DDoS protection, CDN, WAF, HTTP/2, load balancing, and more.

These days not providing SSL for customers’ hostnames puts you (and them) at a competitive disadvantage. Besides protecting website visitors’ privacy and preventing unscrupulous ISPs or adversaries from modifying your application in transit, HTTPS delivers meaningful benefits that result in higher SEO and discoverability; from a rankings perspective, Google penalizes sites that don’t have HTTPS as well as sites that load slowly. Using SSL for SaaS is the easiest way to make your customers sites accessible via HTTPS and consequently reduce page load time by enabling HTTP/2. Reduced page load time also results in higher conversion rates.

Additionally, because SSL for SaaS is built on Cloudflare’s industry leading SSL/TLS implementation, your customers will benefit from all of the work we’ve done to make HTTPS fast, secure, and reliable such as deploying OCSP stapling, implementing TLS 1.3 (and 0-RTT), and optimizing TLS over TCP. Most importantly, by terminating these TLS connections as physically close to your customers as possible (as opposed to directly on your origin), your customers will benefit from the most interconnected network on the internet.

In some cases, you may have already pieced together a solution internally based on customer provided key material. Or your customer is using their desired hostname with a competitor (or internal solution) that provides HTTPS and cannot tolerate a short maintenance window.

For these cases, we have extended the two alternative “pre-validation” methods available in Dedicated Certificates to our SSL for SaaS offering: email and CNAME. Simply change the SSL method in the API call above from “http” to “email” or “cname” and send the request. See the API documentation for more information.

An email will be sent to the WHOIS contacts at your customer’s domain with a link to a simple page that we host. (This page can optionally be branded and hosted on your domain.) Once the “Approve” button is clicked, we’ll issue the certificate and push it to our edge automatically.

The other alternative method, CNAME token, is typically used when you control DNS for the vanity names (some of our SaaS customers, especially those providing website building and hosting services, allow the custom domain to be registered as part of the workflow).

Lastly, you are free to serve the HTTP token returned by the “http” validation method on your origin (instead of letting us insert it during the reverse proxy) and our automated retry queue will detect it once it is in place. If you’d like to tell us once it’s in place and have us retry immediately, you can always send a PATCH to the endpoint with the same SSL body as you sent during POST and we’ll immediately check for it.

Any SaaS application that allows customers to “bring your own domain” should be a great fit for SSL for SaaS. Some examples:

• Content management solutions such as generic website builders, blogging and static hosting platforms, image and photo sharing sites, and industry-specific site builders, e.g., education, healthcare, real estate, wedding, etc.

• eCommerce platforms that facilitate the selling of goods or services online.

• Web portals such as support, collaboration, and marketing/landing sites.

• Platform-as-a-service companies that allow customers to serve applications using their own hostname.

Sure, it’s definitely possible. But before doing so, make sure you have answers to the following questions:

From how many locations around the world will I be able to terminate TLS? What sort of performance will my customers see?Acquiring certificates is easy when compared with distributing them around the world and making them available as close to your customers’ visitors as possible. The further a visitor’s request has to travel, the slower the page load time will be. With TLS 1.2 an initial TLS handshake requires 2 round trips; if this handshake can only end up at a few locations, performance will suffer (unless all users are physically close to those locations and routed appropriately).

What happens if my customer gets DDoS’ed? How will this impact my infrastructure? When serving as your own frontline TLS termination point, all traffic destined for your customers’ hostnames will end up at your network perimeter. If a customer is under attack and this traffic exceeds your capacity, other customers may suffer.Terminating your customers’ traffic at our edge allows our DDoS protection services to handle attacks of any size, passing only legitimate traffic to your origin. We recommend that you install a certificate on your origin and configure the origin requests to utilize TLS.

How will I securely store and use my customers’ private keys? Private keys need to be stored securely, encrypted whenever at rest, and never written to disk in plaintext. Encrypting them is easy, but decrypting them on the fly is hard as it either requires manual effort or considerable engineering work.Cloudflare has experience generating and protecting private keys for millions of domains through our Universal SSL, Dedicated Certificates, and (now) SSL for SaaS products.

Does my HTTPS offering (whether from origin or another provider) support the performance-critical functionality enumerated on sites like istlsfastyet.com? If you’re rolling your own TLS configuration, make sure that you support all the extensions and related enhancements that make TLS fast and secure such as TLS 1.3 and HTTP/2 (enabled via the ALPN TLS extension).

What will I do if my CA encounters issues? Can my CA support my scale? When your implementation calls for onboarding large numbers of customers in an automated fashion, ensure that you’re able to failover to a different CA if one has issues or cannot keep up with the scale of your requests.

How often must I renew? What if something goes wrong? If you are issuing short-lived certificates and must renew frequently, you should make sure that this renewal process is monitored and maintained. HSTS settings may prevent a website from being loaded if the certificate has expired.

What is my plan for reissuing en masse if the next Heartbleed occurs? Related to renewals are reissuances in light of security concerns. If you were running an OpenSSL-based crypto stack when Heartbleed occurred, you needed to regenerate all of your keys and request reissuance of certificates.

If you’re not already a Cloudflare customer, give us your name and contact info and someone on our team will reach out to you; be sure to mention SSL for SaaS in the request. If you’re an existing Cloudflare customer, ask your Customer Success Manager.