How to Use Let's Encrypt with Cloudflare Without Breaking Validation

Overview

If you use Cloudflare in front of your site, visitors connect to Cloudflare first. Cloudflare then connects to your origin server. Let’s Encrypt, however, still needs to validate that you control the domain. That is where confusion starts.

The key idea is simple: Cloudflare is not your Let’s Encrypt certificate. Cloudflare can present its own edge certificate to visitors, but your origin server may still need its own certificate depending on how you want Cloudflare to connect to it. In practice, you usually choose between two valid approaches:

• Use Let’s Encrypt on the origin server, then set Cloudflare SSL mode to Full (strict). This is the cleanest option when you want a standard public certificate on the origin.
• Use a Cloudflare Origin Certificate on the origin, then also use Full (strict). This works well if the origin only needs to serve Cloudflare, not direct public visitors.

Where Let’s Encrypt enters the picture is validation. The certificate authority must confirm domain control. The most common methods are:

• HTTP-01: Let’s Encrypt checks a file on your web server over HTTP.
• DNS-01: Let’s Encrypt checks a TXT record in DNS.

With Cloudflare, both can work, but each has different failure modes:

• HTTP-01 is often blocked by redirects, firewall rules, reverse proxy behavior, or origin records that do not resolve as expected.
• DNS-01 is usually the more reliable choice for proxied setups and is required for wildcard certificates.

Before changing anything, identify your actual goal:

1. Do you need a public certificate on the origin, or only a certificate trusted by Cloudflare?
2. Are your DNS records proxied through Cloudflare?
3. Do you need a wildcard certificate?
4. Do you control the origin server enough to install an ACME client such as Certbot or an alternative?

Once you answer those questions, the setup path becomes much clearer.

Checklist by scenario

Use the scenario that matches your stack. If you are unsure, start with Scenario 1 or Scenario 2.

Scenario 1: Standard website behind Cloudflare, using Let’s Encrypt on the origin

This is the most reusable setup for VPS hosting, small production sites, and self-managed servers.

1. Confirm the A or AAAA record points to the correct origin server. If the IP is wrong, validation will fail before SSL becomes relevant.
2. Decide whether to validate with HTTP-01 or DNS-01. If you only need a certificate for the apex domain and common hostnames such as www, HTTP-01 may be enough. If you want a wildcard or expect proxy-related friction, use DNS-01.
3. Install your ACME client on the origin. Certbot is common, but other clients are also valid. If you want options, see Certbot Alternatives for 2026: When to Use acme.sh, Dehydrated, Win-ACME, or Caddy.
4. If using HTTP-01, make sure the ACME path is reachable. The request to /.well-known/acme-challenge/ must reach your origin correctly. Avoid aggressive rewrites that intercept or redirect this path in a way your client does not expect.
5. If using DNS-01, create or automate the required TXT record updates in Cloudflare DNS. This avoids proxy-related edge cases and is the usual path for wildcard certificates.
6. Install the issued certificate on the origin web server. Then verify your web server is serving the correct certificate for the hostname.
7. Set Cloudflare SSL mode to Full (strict). This tells Cloudflare to require a valid certificate on the origin rather than accepting an invalid or self-signed setup.
8. Test renewal before you need it. Renewal matters as much as initial issuance. For a deeper walkthrough, see How to Renew Let’s Encrypt Certificates Automatically and Verify It Actually Works.

Scenario 2: Proxied Cloudflare records and repeated HTTP validation failures

If Certbot with Cloudflare keeps failing and the errors point to unreachable challenge files or unexpected responses, switch your thinking from web traffic to domain control.

1. Check whether the hostname is orange-cloud proxied in Cloudflare. Proxying does not always break validation, but it adds another layer that can interfere with expected responses.
2. Temporarily decide whether to bypass the proxy or change validation method. In many environments, the cleaner fix is not to toggle the proxy at all, but to use DNS-01.
3. If you stay with HTTP-01, verify three things:
   • Port 80 is reachable at the origin.
   • Your web server serves the challenge path without application-level interference.
   • Cloudflare rules are not rewriting, caching, or blocking the request in unexpected ways.
4. If this is a recurring issue, move to DNS-01. It is usually more stable for Cloudflare-managed domains because validation happens in DNS rather than through the proxied web path.

Scenario 3: You need a wildcard certificate

This one is simple: use DNS-01. Wildcard certificates are not issued through HTTP-01.

1. Confirm you actually need a wildcard. For a small site, listing specific hostnames may be simpler than broad certificate coverage.
2. Use an ACME client that supports DNS-based validation with Cloudflare.
3. Create or automate the required TXT records. Make sure you wait long enough for the DNS update to become visible where validation is happening.
4. Install the certificate on the origin and keep Cloudflare in Full (strict).

Scenario 4: You are using a Cloudflare Origin Certificate instead of Let’s Encrypt

This is valid, but it solves a different problem.

1. Use a Cloudflare Origin Certificate if only Cloudflare needs to trust the origin. This is often acceptable when all public traffic should pass through Cloudflare.
2. Do not confuse an Origin Certificate with a public certificate. It is not the same as Let’s Encrypt and is not intended for direct public browser trust.
3. Keep Cloudflare SSL mode at Full (strict). That is what makes the origin certificate useful.
4. If you also need direct access to the origin over a publicly trusted certificate, use Let’s Encrypt instead.

Scenario 5: WordPress or another app keeps redirecting in ways that break validation

Application behavior can interfere with validation even when DNS is correct.

1. Check whether the app forces HTTPS, canonical host redirects, or custom rewrites.
2. Confirm the ACME challenge path is exempt from application routing when needed.
3. Review both server-level and app-level redirects. It is common to fix the web server and miss the application layer.
4. If the app is difficult to tame, use DNS-01 instead.

If your site runs on WordPress, related HTTPS cleanup steps are covered in Let’s Encrypt for WordPress: Hosting Requirements, Plugin Options, and HTTPS Fixes.

What to double-check

These checks catch most misconfigurations before they become downtime or failed renewals.

1. DNS record targets

Make sure the hostname you are validating points where you think it points. This matters especially after migrations, provider changes, or temporary staging work. A stale A record is one of the easiest ways to waste time on the wrong server.

2. Proxy status in Cloudflare

Know whether the hostname is proxied or DNS-only. This changes how requests flow, how troubleshooting should be done, and whether HTTP validation is worth pursuing.

3. Cloudflare SSL mode

For origin encryption with a valid certificate, Full (strict) is the target mode. Avoid leaving a production site in looser modes longer than necessary. If you switch modes during troubleshooting, switch back once the origin certificate is correct.

4. Port 80 and port 443 behavior

HTTP-01 typically depends on port 80 being reachable. If your origin only accepts 443, or if firewall rules differ from what you expect, validation may fail even though the site seems available through Cloudflare.

5. Web server virtual host selection

On Nginx and Apache, the wrong server block or virtual host can serve the challenge path or certificate. That leads to confusing behavior where one hostname works and another fails on the same machine. For server-specific guidance, see Let’s Encrypt for Nginx: Complete Setup, Redirects, and Renewal Checklist and Let’s Encrypt for Apache: Complete Setup, VirtualHosts, and Renewal Checklist.

6. AAAA records

If you publish IPv6 records, make sure the IPv6 path works too. Validation may reach that address if it exists. A correct IPv4 setup does not rescue a broken IPv6 endpoint.

7. Renewal automation

Do not stop after a successful first issue. Confirm that your renewal method still works with your Cloudflare setup, and test reload hooks so your web server actually uses the renewed certificate.

8. Monitoring

Add expiry checks or alerting so certificate problems are caught before users notice them. A practical starting point is Let’s Encrypt Expiry Monitoring: Best Tools, Alerts, and Dashboard Options.

Common mistakes

Most recurring Let’s Encrypt Cloudflare problems are not exotic. They are predictable configuration mismatches.

• Assuming Cloudflare’s edge certificate means the origin does not need one. If Cloudflare connects to your origin over HTTPS and you want proper verification, the origin still needs a suitable certificate.
• Using Flexible mode and forgetting about it. Flexible can mask origin SSL issues rather than solve them. It is not the same as a complete end-to-end HTTPS setup.
• Choosing HTTP-01 for a wildcard request. Wildcards require DNS validation.
• Forgetting that redirects can alter validation behavior. Redirect rules, app logic, and forced canonical domains can all interfere.
• Changing the proxy setting without checking DNS propagation behavior. Troubleshooting can become inconsistent if you switch states and test too quickly.
• Ignoring AAAA records. A broken IPv6 path can cause validation trouble that looks random if you only test IPv4.
• Confusing Cloudflare Origin Certificates with publicly trusted certificates. They are not interchangeable in every use case.
• Renewing successfully but not reloading the web server. The new certificate exists on disk, but the old one is still being served.
• Testing through the browser only. Browser success can hide origin-level problems because the browser may only be seeing Cloudflare’s side of the connection.

If you are still early in server setup, it may help to review a base deployment guide first, such as Let’s Encrypt on Ubuntu: Step-by-Step Setup for Current LTS Releases or Let’s Encrypt on Debian: Step-by-Step Setup for Stable Releases. Windows administrators can use Let’s Encrypt on Windows Server: IIS Setup, Renewal, and Common Errors.

When to revisit

Return to this checklist whenever one of the underlying inputs changes. That is the best way to prevent a stable setup from drifting into an outage.

• Before a hosting migration. New IPs, new web servers, and temporary DNS changes are common failure points.
• When changing Cloudflare proxy status. Orange-cloud and DNS-only behavior affect how traffic and validation reach the origin.
• When moving from a single hostname to wildcard coverage. This usually means switching to DNS-01.
• When changing web servers or reverse proxy layers. Nginx, Apache, Caddy, and platform proxies all handle challenge paths differently.
• When tightening SSL policy. For example, when moving to Full (strict) after a temporary setup.
• Before seasonal traffic periods or release cycles. Certificate and DNS problems are easier to solve before traffic pressure rises.
• When renewal automation or API workflows change. Any change to ACME clients, tokens, hooks, or DNS automation is worth retesting.

For a practical action plan, use this short pre-change routine:

1. List every hostname covered by the certificate.
2. Confirm whether each record is proxied or DNS-only.
3. Choose the validation method deliberately: HTTP-01 for simple direct cases, DNS-01 for wildcard or Cloudflare-heavy cases.
4. Verify the origin is serving the expected site on the expected IPs.
5. Install or renew the certificate and reload the web server.
6. Set or confirm Cloudflare SSL mode as Full (strict).
7. Test both issuance and renewal, not just the live site.
8. Add monitoring so you know when something drifts.

If you treat Let’s Encrypt, Cloudflare DNS, and origin SSL as separate layers, troubleshooting becomes much calmer. The certificate authority validates domain control. Cloudflare proxies and protects traffic. Your origin serves the real application. Keep those roles distinct, and most validation issues become routine rather than disruptive.