HTTP (2)

HTTP (2)

Last updated Oct 15, 2026 HTTP validation involves adding a DCV token to your customer's origin.

You choose one certificate validation method when you create a custom hostname. The API accepts one ssl.method value: http, txt, or email.

Non-wildcard custom hostnames

Eligible non-wildcard custom hostnames can use automatic HTTP validation after the hostname points to your SaaS target.

This HTTP validation should succeed as long as your customer's hostname points to your SaaS target and they do not have any CAA records blocking your chosen certificate authority.

During renewal, Cloudflare may use HTTP validation even if you selected TXT for initial issuance. Hostnames with properly configured Delegated DCV remain TXT-based. For more information, refer to Renew certificates.

Wildcard custom hostnames

HTTP DCV validation is not allowed for wildcard certificates. Use TXT validation instead. You can also configure Delegated DCV to automate TXT-based validation.

DCV records are generated asynchronously

After you create a custom hostname, the ssl.validation_records array may be empty for a short period while Cloudflare requests DCV tokens from the certificate authority. If the array is empty, wait a few seconds and query the custom hostname details endpoint again.

Validation methods

HTTP (automatic)

If you value simplicity and your customers can handle a few minutes of downtime, you can rely on Cloudflare automatic HTTP validation.

Once you create a new hostname and choose the http validation method, all your customers have to do is add a CNAME to your $CNAME_TARGET and Cloudflare will take care of the rest.

Automatic HTTP validation works on the fly. After your customer points the hostname to your SaaS target, Cloudflare can serve the CA's HTTP DCV token from the edge and complete certificate validation.

During that period, the hostname may route to Cloudflare before the certificate reaches ssl.status: active. If you need the certificate active before your customer changes DNS, use TXT validation or Delegated DCV instead.

What happens after you create the custom hostname

</summary>

Cloudflare contacts one of our certificate authority (CA) providers and asks them to issue certificates for the specified hostname. The CA will then inform Cloudflare that we need to demonstrate control of this hostname by returning a <code>$DCV_TOKEN</code> at a specified <code>$DCV_FILENAME</code>; both the token and the filename are randomly generated by the CA and not known to Cloudflare ahead of time.

For example, if you create a new custom hostname for <code>site.example.com</code>, the CA might ask us to return the value <code>ca3-38734555d85e4421beb4a3e6d1645fe6</code> for a request to <code>http://site.example.com/.well-known/pki-validation/ca3-39f423f095be4983922ca0365308612d.txt"</code>. As soon as we receive that value from the CA we make it accessible at our edge and ask the CA to confirm it is there so that they can complete validation and the certificate order.

</details>

Note

Cloudflare is able to serve a random token from our edge due to the fact that site.example.com has a CNAME in place to $CNAME_TARGET, which ultimately resolves to Cloudflare IPs. If your customer has not yet added the CNAME, the CA will not be able to retrieve the token and the process will not complete.

We will attempt to retry this validation check for a finite period before timing out. Refer to Validation Retry Schedule for more details.

If you would like to complete the issuance process before asking your customer to update their CNAME (or before changing the resolution of your target CNAME to be proxied by Cloudflare), choose another validation method.

HTTP (manual)

Once you create a new hostname and choose this validation method, you will see the following values after a few seconds:

API: Within the ssl object, store the values present in the validation_records array (specifically http_url and http_body).
Dashboard: When viewing an individual certificate on the Custom Hostnames ↗︎ page, refer to the values for Certificate validation request and Certificate validation response.

At your origin, make the http_body available in a TXT record at the path specified in http_url. This path should also be publicly accessible to anyone on the Internet so your CA can access it.

Here is an example NGINX configuration that would return a token:

location "/.well-known/pki-validation/ca3-0052344e54074d9693e89e27486692d6.txt" {
       return 200 "ca3-be794c5f757b468eba805d1a705e44f6\n";
}

Once your configuration is live, test that the DCV text file is in place with curl:

curl "http://http-preval.example.com/.well-known/pki-validation/ca3-0052344e54074d9693e89e27486692d6.txt"

ca3-be794c5f757b468eba805d1a705e44f6

The token is valid for one check cycle. On the next check cycle, Cloudflare will ask the CA to recheck the URL, complete validation, and issue the certificate.

If you would like to request an immediate recheck, rather than wait for the next retry, send a PATCH request with the same values as your initial POST request.

Was this helpful?

YesNo

{"@context":"https://schema.org","@type":"TechArticle","@id":"https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/http/#page","headline":"HTTP","description":"Validate domain ownership by placing a DCV token on your customer origin.","url":"https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/http/","inLanguage":"en","image":"https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/http/og.png?v=fcb8d6e1cf2e4947","dateModified":"2026-10-15","publisher":{"@type":"Organization","name":"Cloudflare","description":"One platform for your apps, agents, and workforce. Build, secure, and scale without managing infrastructure","url":"https://www.cloudflare.com/","sameAs":["https://github.com/cloudflare","https://www.linkedin.com/company/cloudflare","https://x.com/cloudflare"],"logo":{"@type":"ImageObject","url":"https://developers.cloudflare.com/logo.svg"},"address":{"@type":"PostalAddress","streetAddress":"101 Townsend St","addressLocality":"San Francisco","addressRegion":"CA","postalCode":"94107","addressCountry":"US"},"contactPoint":[{"@type":"ContactPoint","contactType":"Customer Support","url":"https://support.cloudflare.com/","availableLanguage":["English"]},{"@type":"ContactPoint","contactType":"Sales","url":"https://www.cloudflare.com/contact/","availableLanguage":["English"]}]},"isPartOf":{"@type":"WebSite","@id":"https://developers.cloudflare.com/#website","name":"Cloudflare Docs","url":"https://developers.cloudflare.com/"},"keywords":["TLS"]}

description: Resolve domain control validation failures and certificate issuance issues for custom hostnames. title: Troubleshooting image: https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/troubleshooting/og.png?v=9d2a249f28a574a1

Documentation Index
Fetch the complete documentation index at: https://developers.cloudflare.com/cloudflare-for-platforms/llms.txt
Use this file to discover all available pages before exploring further.

HTTP (2)

HTTP (2)

Non-wildcard custom hostnames

Wildcard custom hostnames

Validation methods

HTTP (automatic)

HTTP (manual)

On this page