Configuring Cloudflare for SaaS
If there are multiple proxied DNS records for one zone, Cloudflare must prioritize which record controls the zone settings and associated origin server. Adding a new custom hostname may take priority over your current settings or cause your settings to no longer apply. To prevent overriding or voiding your settings, review
Step 1 — Create fallback origin and CNAME target
The fallback origin is where Cloudflare will route traffic sent to your custom hostnames (must be proxied).
We suggest using a domain other than your main company domain (example.cloud instead of example.com) to lower risk and add flexibility to your custom hostname management.
- A proxied A or AAAA record pointing to the IP address of your fallback origin (where Cloudflare will send custom hostname traffic).
- A CNAME record that points your CNAME target to your fallback origin (can be a wildcard such as
Enable Custom Hostnames for your zone:
- If you are an Enterprise customer, upgrade your zone to an Enterprise plan and contact your Customer Success Manager to enable Cloudflare for SaaS Certificates.
- If you are not an Enterprise customer, go to SSL/TLS > Custom Hostnames to enable Cloudflare for SaaS.
Set the Fallback Origin via either the dashboard or API.
Using the dashboard
- Navigate to SSL/TLS > Custom Hostnames.
- In the Custom Hostnames card, enter the hostname for your fallback origin.
- Click Add.
Step 2 — Review validation and verification options
Each Custom Hostname requires successful Certificate Validation and Hostname Verification.
- : Upon successful validation, the certificates are deployed to Cloudflare’s edge network.
- : Upon successful validation, Cloudflare proxies traffic for this hostname.
Depending on which method you select for each of these options, additional steps might be required for you and your customers.
Step 3 — Issue certificate
Once your account has been provisioned, you are ready to issue certificates.
For each custom hostname certificate you request, Cloudflare issues two certificates that are bundled in chains that maximize browser compatibility (unless you ). The primary certificate uses a P-256 key, is SHA-2/ECDSA signed, and will be presented to browsers that support elliptic curve cryptography (ECC). The secondary or fallback certificate uses an RSA 2048-bit key, is SHA-2/RSA signed, and will be presented to browsers that do not support ECC.
Once issued, certificates are valid for one year. Renewals depend on your chosen method for .
Using the dashboard
app.customer.com and set the relevant options, including:
Step 4 — Monitor and view certificates
Once you issue certificates, Cloudflare will initiate the domain validation process using the method you specified.
With a CNAME in place, the entire process — from validation to issuance to edge deployment — completes in approximately 90 seconds.
Monitor certificate status
Once domain validation has been completed, the certificates will be issued and distributed to Cloudflare’s edge.
$ openssl s_client -servername app.example.com -connect $CNAME_TARGET:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep app.example.com
Step 5 — Have customer create a CNAME record
Your customer needs to set up a CNAME record at their DNS provider that points to your . For an existing site, ensure your custom hostname and certificate are verified and valid prior to completing this step. Shifting traffic before the certificate has been issued may cause an insecurity in your domain.
app CNAME john.customers.saasprovider.com
This routes traffic from
app.customer.com to your origin.
Step 6 — Offboard custom hostnames
As a SaaS provider, you must remove a customer’s custom hostname from your zone if they decide to churn. This is especially important if your end customers are using Cloudflare because if the custom hostname changes the DNS target to point away from your SaaS zone, the custom hostname will continue to route to your service. This is a result of the .