diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/index.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/index.mdx index d4e19f5db05f2f2..4d1dcee460c4b66 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/index.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/index.mdx @@ -11,7 +11,7 @@ Before Cloudflare can proxy traffic through a custom hostname, we need to verify :::note -If a custom hostname is already on Cloudflare, using the [pre-validation methods](/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/pre-validation/) will not shift the traffic to the SaaS zone. That will only happen once the [DNS target](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#step-3--have-customer-create-cname-record) of the custom hostnames changes to point to the SaaS zone. +If a custom hostname is already on Cloudflare, using the [pre-validation methods](/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/pre-validation/) will not shift the traffic to the SaaS zone. That will only happen once the [DNS target](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#3-have-customer-create-cname-record) of the custom hostnames changes to point to the SaaS zone. ::: diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/realtime-validation.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/realtime-validation.mdx index 3169dcf03cc8ea5..df9d0ac76c3b9dc 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/realtime-validation.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/realtime-validation.mdx @@ -11,7 +11,7 @@ head: import { Render } from "~/components" -When you use a real-time validation method, Cloudflare verifies your customer's hostname when your customers adds their [DNS routing record](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#step-3--have-customer-create-cname-record) to their authoritative DNS. +When you use a real-time validation method, Cloudflare verifies your customer's hostname when your customers adds their [DNS routing record](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#3-have-customer-create-cname-record) to their authoritative DNS. ## Use when @@ -25,7 +25,7 @@ To avoid any chance of downtime, use a [pre-validation method](/cloudflare-for-p ## How to -Real-time validation occurs automatically when your customer adds their [DNS routing record](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#step-3--have-customer-create-cname-record). +Real-time validation occurs automatically when your customer adds their [DNS routing record](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#3-have-customer-create-cname-record). The exact record depends on your Cloudflare for SaaS setup. diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/remove-custom-hostnames.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/remove-custom-hostnames.mdx index b1b38bf6fa518fc..bdeb36e3a6ea897 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/remove-custom-hostnames.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/domain-support/remove-custom-hostnames.mdx @@ -15,7 +15,7 @@ As a SaaS provider, your customers may decide to no longer participate in your s If your customer's domain is also using Cloudflare, they can stop routing their traffic through your custom hostname by updating their Cloudflare DNS. -If they update their [`CNAME` record](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#step-3--have-customer-create-cname-record) so that it no longer points to your `CNAME` target: +If they update their [`CNAME` record](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#3-have-customer-create-cname-record) so that it no longer points to your `CNAME` target: - The domain's traffic will not route through your custom hostname. - The custom hostname will enter into a **Moved** state. diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/reference/troubleshooting.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/reference/troubleshooting.mdx index b1d1c8b135ef411..d42520bd3969566 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/reference/troubleshooting.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/reference/troubleshooting.mdx @@ -32,7 +32,7 @@ Cloudflare returns a 1016 error when the custom hostname cannot be routed or pro There are three main causes of error 1016: 1. Custom Hostname ownership validation is not complete. To check validation status, run an API call to [search for a certificate by hostname](/cloudflare-for-platforms/cloudflare-for-saas/start/common-api-calls/) and check the verification error field: `"verification_errors": ["custom hostname does not CNAME to this zone."]`. -2. Fallback Origin is not [correctly set](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#step-1--create-fallback-origin). Confirm that you have created a DNS record for the fallback origin and also set the fallback origin. +2. Fallback Origin is not [correctly set](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#1-create-fallback-origin). Confirm that you have created a DNS record for the fallback origin and also set the fallback origin. 3. A Wildcard Custom Hostname has been created, but the requested hostname is associated with a domain that exists in Cloudflare as a standalone zone. In this case, the [hostname priority](/ssl/reference/certificate-and-hostname-priority/#hostname-priority-cloudflare-for-saas) for the standalone zone will take precedence over the wildcard custom hostname. This behavior applies even if there is no DNS record for this standalone zone hostname. In this scenario each hostname that needs to be served by the Cloudflare for SaaS parent zone needs to be added as an individual Custom Hostname. diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/custom-certificates/certificate-signing-requests.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/custom-certificates/certificate-signing-requests.mdx index 59ffa73528ef2ce..22ed60af7bcd10a 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/custom-certificates/certificate-signing-requests.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/custom-certificates/certificate-signing-requests.mdx @@ -21,7 +21,7 @@ Once the CSR has been generated, provide it to your customer. Your customer will ## Generate the private key and CSR -### Step 1 — Build the CSR payload +### 1. Build the CSR payload All fields except for organizational\_unit and key\_type are required. If you do not specify a `key_type`, the default of `rsa2048` (RSA 2048 bit) will be used; the other option is `p256v1` (NIST P-256). @@ -48,7 +48,7 @@ EOF )) ``` -### Step 2 — Generate a CSR +### 2. Generate a CSR Now, you want to generate a CSR that you can provide to your customer. @@ -92,11 +92,11 @@ curl https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_csrs \ --data "$request_body" | jq .result.csr | perl -npe s'/\\n/\n/g; s/"//g' > csr.txt ``` -### Step 3 — Customer obtains certificate +### 3. Customer obtains certificate Your customer will take the provided CSR and work with their CA to obtain a signed, publicly trusted certificate. -### Step 4 — Upload the certificate +### 4. Upload the certificate Upload the certificate and reference the ID that was provided when you generated the CSR. diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/custom-certificates/uploading-certificates.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/custom-certificates/uploading-certificates.mdx index 47cbbd3a0e4cbe1..470fb838440b18b 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/custom-certificates/uploading-certificates.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/custom-certificates/uploading-certificates.mdx @@ -15,7 +15,7 @@ For use cases and limitations, refer to [custom certificates](/cloudflare-for-pl :::caution -You can only use one of the different [supported types](/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/custom-certificates/#limitations). For example, you cannot upload an `SHA256WithRSA` + `ECDSAWithSHA256` certificate. +You can only use one of the different [supported types](/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/custom-certificates/#limitations). For example, you cannot upload an `SHA256WithRSA` + `ECDSAWithSHA256` certificate. ::: ## Upload certificates @@ -32,7 +32,7 @@ The call below will upload a certificate for use with `app.example.com`. Note that if you are using an ECC key generated by OpenSSL, you will need to first remove the `-----BEGIN EC PARAMETERS-----...-----END EC PARAMETERS-----` section of the file. -#### Step 1 — Update the file and build the payload +#### 1. Update the file and build the payload @@ -52,7 +52,7 @@ EOF )) ``` -#### Step 2 — Upload your certificate and key +#### 2. Upload your certificate and key Use a [POST request](/api/operations/custom-hostname-for-a-zone-create-custom-hostname) to upload your certificate and key. diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/txt.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/txt.mdx index 9019399c777886b..818a28a4a326e42 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/txt.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/txt.mdx @@ -30,7 +30,7 @@ This means that - if you choose to use wildcard custom hostnames - you will need --- -### Step 1 - Get TXT tokens +### 1. Get TXT tokens Once you [create a new hostname](/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/issue-certificates/) and choose this validation method, your tokens will be ready after a few seconds. @@ -48,21 +48,21 @@ Once you [create a new hostname](/cloudflare-for-platforms/cloudflare-for-saas/s -### Step 2 - Share with your customer +### 2. Share with your customer You will then need to share these TXT tokens with your customers. -### Step 3 - Add DNS records (customer) +### 3. Add DNS records (customer) -### Step 4 (optional) - Fetch new tokens +### 4. (Optional) Fetch new tokens Your DCV tokens expire after a [certain amount of time](/cloudflare-for-platforms/cloudflare-for-saas/reference/token-validity-periods/), depending on your certificate authority. -This means that, if your customers take too long to place their tokens at their authoritative DNS provider, you may need to [get new tokens](#step-1---get-txt-tokens) and re-share them with your customer. +This means that, if your customers take too long to place their tokens at their authoritative DNS provider, you may need to [get new tokens](#1-get-txt-tokens) and re-share them with your customer. --- diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/waf-for-saas/index.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/waf-for-saas/index.mdx index 620511e3344b3b7..52466e896f2c142 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/waf-for-saas/index.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/waf-for-saas/index.mdx @@ -26,7 +26,7 @@ curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_hostnames" \ --data '{"Hostname":"example.com"}, "Ssl":{wildcard:false}}' ``` -## Step 1 - Associate custom metadata to a custom hostname +## 1. Associate custom metadata to a custom hostname To apply WAF to your custom hostname, you need to create an association between your customer's domain and the WAF configuration that you would like to attach to it. Cloudflare's product, [custom metadata](/cloudflare-for-platforms/cloudflare-for-saas/domain-support/custom-metadata/) allows you to do this via the API. @@ -68,7 +68,7 @@ curl --request PATCH \ This assigns custom metadata to your custom hostname so that it has a security tag associated with its ID. -## Step 2 - Trigger security products based on tags +## 2. Trigger security products based on tags 1. Locate the custom metadata field in the Ruleset Engine where the WAF runs. This can be used to trigger different configurations of products such as [WAF custom rules](/waf/custom-rules/), [rate limiting rules](/waf/rate-limiting-rules/), and [Transform Rules](/rules/transform/). diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/waf-for-saas/managed-rulesets.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/waf-for-saas/managed-rulesets.mdx index 9e2b3e8374c7944..5cc6b4d12329053 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/waf-for-saas/managed-rulesets.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/waf-for-saas/managed-rulesets.mdx @@ -25,11 +25,11 @@ Customers can automate the [custom metadata](/cloudflare-for-platforms/cloudflar *** -## Step 1 - Choose security tagging system +## 1. Choose security tagging system 1. Outline `security_tag` buckets. These are fully customizable with no strict limit on quantity. For example, you can set `security_tag` to `low`,`medium`, and `high` as a default, with one tag per custom hostname. -2. If you have not already done so, [associate your custom metadata to custom hostnames](/cloudflare-for-platforms/cloudflare-for-saas/security/waf-for-saas#step-1---associate-custom-metadata-to-a-custom-hostname) by including the `security_tag`in the custom metadata associated with the custom hostname. The JSON blob associated with the custom hostname is fully customizable. +2. If you have not already done so, [associate your custom metadata to custom hostnames](/cloudflare-for-platforms/cloudflare-for-saas/security/waf-for-saas/#1-associate-custom-metadata-to-a-custom-hostname) by including the `security_tag`in the custom metadata associated with the custom hostname. The JSON blob associated with the custom hostname is fully customizable. :::note @@ -41,7 +41,7 @@ After the association is complete, the JSON blob is added to the defined custom *** -## Step 2 - Deploy Rulesets +## 2. Deploy Rulesets 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and navigate to your account. diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/apex-proxying/setup.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/apex-proxying/setup.mdx index 11a81039f37cc68..b23dc4fb2bd28a7 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/apex-proxying/setup.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/apex-proxying/setup.mdx @@ -23,7 +23,7 @@ To set up Cloudflare for SaaS for [apex proxying](/cloudflare-for-platforms/clou
-### Step 1 - Get IP range +### 1. Get IP range With apex proxying, you can either [bring your own IP range](/byoip/) or use a set of IP addresses provided by Cloudflare. @@ -37,7 +37,7 @@ These IP addresses are different than those associated with your Cloudflare zone ::: -### Step 2 - Create fallback origin +### 2. Create fallback origin @@ -47,7 +47,7 @@ These IP addresses are different than those associated with your Cloudflare zone -### Step 3 - Have customer create DNS record +### 3. Have customer create DNS record To finish the custom hostname setup, your customer can set up either an `A` or `CNAME` record at their authoritative DNS provider. @@ -73,7 +73,7 @@ example.com. 60 IN A 192.0.2.1 #### `CNAME` record -If your customer uses a `CNAME` record at their authoritative DNS, they need to point their hostname to your [`CNAME` target](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#step-2-optional--create-cname-target) [^1]. +If your customer uses a `CNAME` record at their authoritative DNS, they need to point their hostname to your [`CNAME` target](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#2-optional-create-cname-target) [^1]. diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/worker-as-origin.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/worker-as-origin.mdx index 5f46c8e6e76f013..cf1e0d8790c230a 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/worker-as-origin.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/worker-as-origin.mdx @@ -12,7 +12,7 @@ description: Learn how to use a Worker as the fallback origin for your SaaS zone If you are building your application on [Cloudflare Workers](/workers/), you can use a Worker as the origin for your SaaS zone (also known as your fallback origin). -1. In your SaaS zone, [create and set a fallback origin](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#step-1--create-fallback-origin). Ensure the fallback origin only has an [originless DNS record](/dns/troubleshooting/faq/#what-ip-should-i-use-for-parked-domain--redirect-only--originless-setup): +1. In your SaaS zone, [create and set a fallback origin](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#1-create-fallback-origin). Ensure the fallback origin only has an [originless DNS record](/dns/troubleshooting/faq/#what-ip-should-i-use-for-parked-domain--redirect-only--originless-setup): * **Example**: `service.example.com AAAA 100::` diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/common-api-calls.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/common-api-calls.mdx index 2dab702908e354e..6e1e43c857a5654 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/common-api-calls.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/common-api-calls.mdx @@ -22,7 +22,7 @@ As a SaaS provider, you may want to configure and manage Cloudflare for SaaS [vi ## Fallback origins -Our API includes the following endpoints related to the [fallback origin](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#step-1--create-fallback-origin) of a custom hostname: +Our API includes the following endpoints related to the [fallback origin](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#1-create-fallback-origin) of a custom hostname: * [Get fallback origin](/api/operations/custom-hostname-fallback-origin-for-a-zone-get-fallback-origin-for-custom-hostnames) * [Update fallback origin](/api/operations/custom-hostname-fallback-origin-for-a-zone-update-fallback-origin-for-custom-hostnames) diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started.mdx index 519af8ddc8dee32..321e0ab208c377d 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started.mdx @@ -20,13 +20,13 @@ import { Example, Render } from "~/components"
-### Step 1 — Create fallback origin +### 1. Create fallback origin -### Step 2 (optional) — Create CNAME target +### 2. (Optional) Create CNAME target -The `CNAME` target — optional, but highly encouraged — provides a friendly and more flexible place for customers to [route their traffic](#step-3--have-customer-create-cname-record). You may want to use a subdomain such as `customers..com`. +The `CNAME` target — optional, but highly encouraged — provides a friendly and more flexible place for customers to [route their traffic](#3-have-customer-create-cname-record). You may want to use a subdomain such as `customers..com`. [Create](/dns/manage-dns-records/how-to/create-dns-records/#create-dns-records) a proxied `CNAME` that points your `CNAME` target to your fallback origin (can be a wildcard such as `*.customers.saasprovider.com`). @@ -44,9 +44,9 @@ The `CNAME` target — optional, but highly encouraged — provides a friendly a -### Step 3 — Have customer create CNAME record +### 3. Have customer create CNAME record -To finish the custom hostname setup, your customer needs to set up a `CNAME` record at their authoritative DNS that points to your [`CNAME` target](#step-2-optional--create-cname-target) [^1]. +To finish the custom hostname setup, your customer needs to set up a `CNAME` record at their authoritative DNS that points to your [`CNAME` target](#2-optional-create-cname-target) [^1]. diff --git a/src/content/docs/reference-architecture/design-guides/extending-cloudflares-benefits-to-saas-providers-end-customers.mdx b/src/content/docs/reference-architecture/design-guides/extending-cloudflares-benefits-to-saas-providers-end-customers.mdx index 0b67748f542f49e..532d9132d34bfb4 100644 --- a/src/content/docs/reference-architecture/design-guides/extending-cloudflares-benefits-to-saas-providers-end-customers.mdx +++ b/src/content/docs/reference-architecture/design-guides/extending-cloudflares-benefits-to-saas-providers-end-customers.mdx @@ -92,7 +92,7 @@ This approach introduces using Cloudflare's [Regional Services](/data-localizati ![Figure 2: Standard Fallback Origin Setup with Regional Services.](~/assets/images/reference-architecture/extending-cloudflares-benefits-to-saas-providers-end-customers/standard-fallback-origin-setup-regional-services.svg "Figure 2: Standard Fallback Origin Setup with Regional Services.") 1. The Custom Hostname (`custom.example.com`) is configured as a CNAME record that points to a regionalized SaaS hostname (`eu-customers.myappexample.com`). This configuration ensures that all processing, including TLS termination, occurs exclusively within the specified geographic region. -2. The regionalized SaaS hostname is set up as a CNAME record that directs traffic to the standard [Fallback Origin](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#step-1--create-fallback-origin) of the SaaS provider (`fallback.myappexample.com`). +2. The regionalized SaaS hostname is set up as a CNAME record that directs traffic to the standard [Fallback Origin](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#1-create-fallback-origin) of the SaaS provider (`fallback.myappexample.com`). 3. The Fallback Origin is set up as an A record that points to the public IP address of the origin server. Cloudflare will route traffic sent to the custom hostnames to this origin server by default. ### Cloudflare Tunnel as Fallback Origin Setup with Regional Services @@ -102,7 +102,7 @@ For enhanced security, rather than exposing your application servers directly to ![Figure 3: Cloudflare Tunnel as Fallback Origin Setup with Regional Services.](~/assets/images/reference-architecture/extending-cloudflares-benefits-to-saas-providers-end-customers/cloudflare-tunnel-fallback-origin-setup-regional-services.svg "Figure 3: Cloudflare Tunnel as Fallback Origin Setup with Regional Services.") 1. The Custom Hostname (`custom.example.com`) is configured as a CNAME record that points to a regionalized SaaS hostname (`eu-customers.myappexample.com`). This configuration ensures that all processing, including TLS termination, occurs exclusively within the specified geographic region. -2. The regionalized SaaS hostname is set up as a CNAME record that directs traffic to the standard [Fallback Origin](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#step-1--create-fallback-origin) of the SaaS provider (`fallback.myappexample.com`). +2. The regionalized SaaS hostname is set up as a CNAME record that directs traffic to the standard [Fallback Origin](/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/#1-create-fallback-origin) of the SaaS provider (`fallback.myappexample.com`). 3. The Fallback Origin is a CNAME DNS record that points to a [public hostname](/cloudflare-one/connections/connect-networks/routing-to-tunnel/) exposed by Cloudflare Tunnel. This public hostname should be configured to route traffic to your application (e.g., `localhost:8080`). This setup is ideal for SaaS providers that do not need granular load balancing, such as [geo-based traffic steering](/load-balancing/understand-basics/traffic-steering/), across multiple origin servers. It's also well-suited for simple testing and development environments, where [protecting your origin server](/fundamentals/basic-tasks/protect-your-origin-server/) by only allowing requests through the Cloudflare Tunnel is sufficient. However, for distributed applications requiring load balancing at both global and local levels, we recommend using [Cloudflare's Load Balancer](/load-balancing/) with global and local traffic management capabilities. diff --git a/src/content/docs/ssl/client-certificates/configure-your-mobile-app-or-iot-device.mdx b/src/content/docs/ssl/client-certificates/configure-your-mobile-app-or-iot-device.mdx index 4b058b390c0da37..473b0fbbeb04f04 100644 --- a/src/content/docs/ssl/client-certificates/configure-your-mobile-app-or-iot-device.mdx +++ b/src/content/docs/ssl/client-certificates/configure-your-mobile-app-or-iot-device.mdx @@ -98,7 +98,7 @@ addEventListener("fetch", (event) => { --- -## Step 1 — Validate API +## 1. Validate API ### POST sample data to API @@ -141,7 +141,7 @@ $ curl --silent https://shield.upinatoms.com/temps | jq . --- -## Step 2 — Create Cloudflare-issued certificates +## 2. Create Cloudflare-issued certificates Before you can use API Shield to protect your API or web application, create Cloudflare-issued client certificates. @@ -262,7 +262,7 @@ $ curl https://api.cloudflare.com/client/v4/zones/{zone_id}/client_certificates --- -## Step 3 — Embed the client certificate in your mobile app +## 3. Embed the client certificate in your mobile app To configure the mobile app to securely request temperature data submitted by the IoT device, embed the client certificate in the mobile app. @@ -274,7 +274,7 @@ Enter Export Password: Verifying - Enter Export Password: ``` -In a real-world deployment, a bootstrap certificate should only be used in conjunction with users’ credentials to authenticate with an API endpoint that can return a unique user certificate. Corporate users will want to use mobile device management (MDM) to distribute certificates. +In a real-world deployment, a bootstrap certificate should only be used in conjunction with users' credentials to authenticate with an API endpoint that can return a unique user certificate. Corporate users will want to use mobile device management (MDM) to distribute certificates. ### Embed the client certificate in an Android app @@ -351,7 +351,7 @@ The above function returns an `OkHttpClient` embedded with the client certificat --- -## Step 4 — Embed the client certificate on your IoT device +## 4. Embed the client certificate on your IoT device To prepare the IoT device for secure communication with the API endpoint, embed the certificate on the device and configure the device to use the certificate when making POST requests. @@ -411,12 +411,12 @@ Response status code: 201 --- -## Step 5 — Enable mTLS +## 5. Enable mTLS After creating Cloudflare-issued certificates, the next step is to [enable mTLS](/ssl/client-certificates/enable-mtls/) for the hosts you want to protect with API Shield. --- -## Step 6 — Configure API Shield to require client certificates +## 6. Configure API Shield to require client certificates To configure API Shield to require client certificates, [create a mTLS rule](/api-shield/security/mtls/configure/#create-an-mtls-rule/). diff --git a/src/content/docs/ssl/edge-certificates/encrypt-visitor-traffic.mdx b/src/content/docs/ssl/edge-certificates/encrypt-visitor-traffic.mdx index 4bf316d5628e640..b03d11af4384b5c 100644 --- a/src/content/docs/ssl/edge-certificates/encrypt-visitor-traffic.mdx +++ b/src/content/docs/ssl/edge-certificates/encrypt-visitor-traffic.mdx @@ -16,7 +16,7 @@ Before trying to enforce HTTPS connections, make sure that your application has Also, make sure that your [SSL encryption mode](/ssl/origin-configuration/ssl-modes/) is not set to **Off**. Otherwise, Cloudflare will redirect all visitor connections automatically to HTTP. -## Step 1 — Evaluate existing redirects +## 1. Evaluate existing redirects To make sure that your visitors do not get stuck in a [redirect loop](/ssl/troubleshooting/too-many-redirects/), evaluate existing redirects at your origin server and within the Cloudflare dashboard. @@ -24,13 +24,13 @@ You should generally avoid redirects at your origin server. Not only are you lik Make sure that your redirects within Cloudflare are not forwarding traffic to URLs starting with `http`. -## Step 2 — Rewrite HTTP URLs +## 2. Rewrite HTTP URLs If your application contains links or references to HTTP URLs, your visitors might see [mixed content errors](/ssl/troubleshooting/mixed-content-errors/) when accessing an HTTPS page. To avoid these issues, enable [Automatic HTTPS Rewrites](/ssl/edge-certificates/additional-options/automatic-https-rewrites/) and pay attention to which HTTP requests are still reaching your origin server. -## Step 3 — Redirect traffic to HTTPS +## 3. Redirect traffic to HTTPS If your entire application can support HTTPS traffic, enable [Always Use HTTPS](/ssl/edge-certificates/additional-options/always-use-https/#encrypt-all-visitor-traffic). diff --git a/src/content/docs/ssl/edge-certificates/staging-environment.mdx b/src/content/docs/ssl/edge-certificates/staging-environment.mdx index 6ebd56d173a7660..43b2221cfc010d1 100644 --- a/src/content/docs/ssl/edge-certificates/staging-environment.mdx +++ b/src/content/docs/ssl/edge-certificates/staging-environment.mdx @@ -22,7 +22,7 @@ Use your certificate staging environment to test new custom (modern) certificate ## Use your staging environment -### Step 1 — Upload certificate +### 1. Upload certificate To upload custom (modern) certificates to your staging environment: @@ -31,7 +31,7 @@ To upload custom (modern) certificates to your staging environment: 3. Upload your custom (modern) certificate ([detailed instructions](/ssl/edge-certificates/custom-certificates/uploading/)). 4. Your certificate will appear in the dashboard with a status of **Staging Deployment**. If you refresh the page, its status should go to **Staging Active**. -### Step 2 — Test certificate +### 2. Test certificate Test your custom (modern) certificate by sending `curl` requests to the IP addresses listed in the dashboard card at **SSL/TLS** > **Staging Certificates**: @@ -45,7 +45,7 @@ You should confirm whether: * The right certificate is being served at the edge. * Any clients are pinning the old certificate. -### Step 3 — Push certificate to production +### 3. Push certificate to production Assuming there are no issues, push your custom (modern) certificate to your production environment: @@ -55,7 +55,7 @@ Assuming there are no issues, push your custom (modern) certificate to your prod If there were issues with your certificate, you can keep it in your staging environment or select **Deactivate** on the certificate itself. -### Step 4 (optional) — Push certificate back to staging +### 4. (Optional) Push certificate back to staging If you roll out a custom (modern) certificate to production and encounter issues, you can deactivate that certificate to delete the certificate from the edge and then push the certificate back to your staging environment for additional testing: diff --git a/src/content/docs/ssl/keyless-ssl/configuration/cloudflare-tunnel.mdx b/src/content/docs/ssl/keyless-ssl/configuration/cloudflare-tunnel.mdx index 55d3c6b2b5e3e7e..1e1551cd92a2f1e 100644 --- a/src/content/docs/ssl/keyless-ssl/configuration/cloudflare-tunnel.mdx +++ b/src/content/docs/ssl/keyless-ssl/configuration/cloudflare-tunnel.mdx @@ -19,13 +19,13 @@ Through an integration with [Cloudflare Tunnel](/cloudflare-one/connections/conn *** -## Step 1 - Install `cloudflared` on key server +## 1. Install `cloudflared` on key server First, install `cloudflared` on your key server.
-## Step 2 - Create a Tunnel +## 2. Create a Tunnel Then, create a Cloudflare Tunnel. @@ -38,7 +38,7 @@ After you create the Tunnel, use the Cloudflare API to [List tunnel routes](/api * `"virtual_network_id"` * `"network"` -## Step 3 - Upload Keyless SSL Certificates +## 3. Upload Keyless SSL Certificates @@ -59,6 +59,6 @@ When you receive the `network` value from the Tunnel route API, it will include ::: -## Step 4 - Set up and activate key server +## 4. Set up and activate key server diff --git a/src/content/docs/ssl/keyless-ssl/configuration/public-dns.mdx b/src/content/docs/ssl/keyless-ssl/configuration/public-dns.mdx index 608d19003335c16..ab3845e505f9d4c 100644 --- a/src/content/docs/ssl/keyless-ssl/configuration/public-dns.mdx +++ b/src/content/docs/ssl/keyless-ssl/configuration/public-dns.mdx @@ -20,7 +20,7 @@ This setup option is not ideal as the DNS record cannot be [proxied](/dns/manage --- -## Step 1 - Create public DNS record +## 1. Create public DNS record 1. Open a Terminal and run `openssl rand -hex 24` to generate a long, random hostname such as `11aa40b4a5db06d4889e48e2f738950ddfa50b7349d09b5f.example.com`. 2. Add this record via your DNS provider’s interface as an **A** or **AAAA** record pointing to the IP address of your Keyless SSL server. @@ -34,7 +34,7 @@ As a security measure, you should hide the hostname of your key server. --- -## Step 2 — Upload Keyless SSL Certificates +## 2. Upload Keyless SSL Certificates @@ -63,7 +63,7 @@ To create a Keyless certificate with the API, send a [`POST`](/api/operations/ke --- -## Step 3 — Set up and activate key server +## 3. Set up and activate key server