Why AutoSSL Fails Under Cloudflare Proxy

If you manage domains behind Cloudflare’s proxy and run cPanel with AutoSSL, there’s a good chance you’ve woken up to an email like this:

AutoSSL did not renew the certificate for “example.com”. You must take action to keep this site secure.

DNS DCV: No local authority: “example.com”; HTTP DCV: “cPanel (powered by Sectigo)” forbids DCV HTTP redirections.

The error is cryptic. cPanel’s documentation doesn’t mention Cloudflare. Cloudflare’s documentation doesn’t mention AutoSSL. And the forum threads that do cover it tend to offer only half the picture — either the quick workaround or the permanent solution, but rarely both, and almost never with a clear explanation of why it happens in the first place.

This article bridges that gap. We’ll walk through what’s actually going wrong at the protocol level, how to get AutoSSL renewed immediately if you’re in a pinch, and how to architect the permanent fix so you never deal with this again.

Understanding the Problem

To grasp why this breaks, you need to understand how AutoSSL validates domain ownership and what Cloudflare does to your traffic before it reaches the origin server.

How AutoSSL’s Domain Control Validation Works

When AutoSSL attempts to issue or renew a certificate (whether through Sectigo or Let’s Encrypt), it needs to prove you control the domain. One of the primary methods is HTTP-based Domain Control Validation (HTTP DCV). The process works like this:

1. The CA places a challenge token at a specific URL path on your server, typically under /.well-known/.
2. The CA’s validation server makes an HTTP request to http://yourdomain.com/.well-known/pki-validation/... to retrieve that token.
3. If the response matches, validation passes and the certificate is issued.

The critical detail here: Sectigo explicitly forbids HTTP redirections during DCV. The validation request must return a 200 OK response directly — not a 301 or 302 redirect. This is a deliberate security measure to prevent validation bypass attacks.

Let’s Encrypt is somewhat more lenient and will follow certain redirects, but Cloudflare’s configuration can still create conditions that cause Let’s Encrypt validation to fail as well.

What Cloudflare’s “Always Use HTTPS” Actually Does

When you enable “Always Use HTTPS” in Cloudflare’s dashboard (under SSL/TLS → Edge Certificates), Cloudflare injects a 301 Moved Permanently redirect for every HTTP request, redirecting it to HTTPS before the request ever reaches your origin server.

So when Sectigo’s validation server sends its HTTP request to:

http://example.com/.well-known/pki-validation/challenge-token

Cloudflare intercepts it and responds with:

301 Moved Permanently → https://example.com/.well-known/pki-validation/challenge-token

Sectigo sees the redirect, refuses to follow it (by design), and the DCV check fails. AutoSSL records the failure and sends you that ominous email.

Why DNS DCV Also Fails

You’ll notice the error message includes a DNS DCV failure as well. When your domain’s DNS is managed through Cloudflare, the authoritative nameservers point to Cloudflare — not to your cPanel server. AutoSSL’s DNS-based validation looks for specific TXT records at _cpanel-dcv-test-record.yourdomain.com, but since Cloudflare controls the DNS zone and doesn’t automatically add these records, the DNS validation method fails too.

This creates a situation where both primary DCV methods are blocked simultaneously, and AutoSSL has no path to certificate renewal.

The Quick Fix: Get AutoSSL Renewed Right Now

If certificates are expiring imminently and you need to renew them today, here’s the fastest path.

Step 1: Disable “Always Use HTTPS” in Cloudflare

Log into your Cloudflare dashboard and navigate to SSL/TLS → Edge Certificates. Toggle Always Use HTTPS to Off.

This stops Cloudflare from injecting the 301 redirect on HTTP requests, allowing Sectigo’s validation server to reach the DCV challenge file directly.

Step 2: Check for Other Redirect Sources

Even with Cloudflare’s setting disabled, other redirect sources can still block DCV. Check for:

Automatic HTTPS Rewrites — Also found under SSL/TLS → Edge Certificates in Cloudflare. Disable it temporarily if it’s enabled.

Server-side .htaccess redirects — If your site’s .htaccess contains an HTTP-to-HTTPS rewrite rule, it will still redirect the DCV request. Temporarily comment out or rename the .htaccess file. Be aware that this may briefly affect your site’s functionality depending on what else the file controls.

WordPress force-HTTPS plugins — Plugins like Really Simple SSL or WordPress’s own FORCE_SSL_ADMIN constant can create redirects at the application level.

Step 3: Run AutoSSL Manually

In cPanel, navigate to SSL/TLS Status and click Run AutoSSL. Watch the progress — each domain should now validate successfully via HTTP DCV.

If you have WHM access, you can also trigger it from WHM → SSL/TLS → Manage AutoSSL and run it for the specific user account.

Step 4: Re-enable Your Settings

Once AutoSSL completes successfully, re-enable “Always Use HTTPS” in Cloudflare and restore any .htaccess rules you modified.

The Downside

This approach works, but you’re signing up to repeat it every 90 days (or whenever AutoSSL attempts renewal). It’s manual, it temporarily reduces your site’s security posture, and if you forget, you’ll end up with expired origin certificates. For a production environment, this isn’t sustainable.

The Permanent Fix: Cloudflare Origin CA Certificates

The real solution is to stop relying on AutoSSL for domains that sit behind Cloudflare’s proxy. Instead, install a Cloudflare Origin CA certificate on your origin server and configure Cloudflare to validate it using Full (Strict) mode.

Why This Works

Cloudflare Origin CA certificates are issued by Cloudflare’s own certificate authority and are trusted only by Cloudflare’s edge servers. They’re not publicly trusted (browsers won’t accept them directly), but that’s fine because in a proxied setup, visitors never communicate directly with your origin. The traffic flow is:

Visitor ←→ Cloudflare Edge (Universal SSL) ←→ Origin Server (Origin CA cert)

Cloudflare’s Universal SSL handles the visitor-facing encryption. The Origin CA certificate handles the Cloudflare-to-origin encryption. Both legs of the connection are fully encrypted, and you get certificates valid for up to 15 years — eliminating the 90-day renewal cycle entirely.

Step 1: Generate the Origin CA Certificate

1. Log into the Cloudflare dashboard.
2. Navigate to SSL/TLS → Origin Server.
3. Click Create Certificate.
4. Select Generate private key and CSR with Cloudflare (the default).
5. Choose RSA as the private key type.
6. Confirm the hostnames — by default it will include example.com and *.example.com. Add any additional subdomains if needed.
7. Set certificate validity to 15 years.
8. Click Create.

You’ll now see both the Origin Certificate (PEM format) and the Private Key. Copy both immediately — Cloudflare will not show you the private key again after you leave this page.

Step 2: Install the Certificate in cPanel

1. Log into cPanel and navigate to SSL/TLS under the Security section.
2. Under Private Keys (KEY), click Upload a New Private Key.
3. Paste the private key you copied from Cloudflare and save it. Add a description like “Cloudflare Origin CA — example.com” so you remember what it’s for.
4. Go back to the SSL/TLS manager and click Manage SSL Sites (under “Install and Manage SSL for your sites”).
5. Select your domain from the dropdown.
6. Paste the Origin Certificate into the Certificate (CRT) field.
7. The private key should auto-populate. If it doesn’t, select it manually from the dropdown.
8. For the Certificate Authority Bundle (CABUNDLE), you need the Cloudflare Origin CA root certificate. Download the RSA PEM version from Cloudflare’s documentation. Important: Do not use the ECC PEM version with Apache/cPanel.
9. Click Install Certificate.

Step 3: Set Cloudflare to Full (Strict) Mode

Back in the Cloudflare dashboard:

1. Navigate to SSL/TLS → Overview.
2. Change the encryption mode from whatever it’s currently set to (likely Flexible or Full) to Full (strict).

Full (Strict) means Cloudflare will validate that your origin server presents a certificate that is either publicly trusted or issued by Cloudflare’s Origin CA, and that it’s not expired. This is the most secure option and ensures end-to-end encryption is actually enforced.

Step 4: Verify

Open your site in a private/incognito browser window. The SSL certificate presented to your browser will be Cloudflare’s Universal SSL certificate (as expected — Cloudflare terminates the visitor-facing TLS). If you see no errors, the Origin CA certificate is working correctly on the back end.

You can further verify by checking that Cloudflare doesn’t throw a 525 (SSL Handshake Failed) or 526 (Invalid SSL Certificate) error, which would indicate a problem with the origin certificate configuration.

What About cPanel’s SSL/TLS Status Warnings?

After installing the Origin CA certificate, you’ll likely notice that cPanel shows warnings about the certificate. It may display “Unknown Certificate Type”, “Self-signed certificate in chain”, or flag it as invalid in the SSL/TLS Status page.

This is expected and can be safely ignored. cPanel validates certificates against publicly trusted certificate authorities, and Cloudflare’s Origin CA isn’t publicly trusted — it’s only trusted by Cloudflare’s edge network. As long as your domain is proxied through Cloudflare (the orange cloud icon is enabled), the Origin CA certificate is fully valid for its intended purpose.

If these warnings bother you or trigger monitoring alerts, you can suppress AutoSSL for specific domains in WHM under Manage AutoSSL → Manage Users by excluding the domains that use Origin CA certificates.

Handling Mixed Environments: Some Domains Proxied, Some Not

In real-world cPanel environments, you often have domains that are proxied through Cloudflare alongside domains that resolve directly to the server. The approach here is straightforward.

For proxied domains (Cloudflare orange cloud enabled), use Origin CA certificates as described above. AutoSSL is unnecessary for these domains and can be excluded.

For non-proxied domains (DNS-only or grey cloud in Cloudflare, or domains not on Cloudflare at all), continue using AutoSSL normally. Since these domains don’t pass through Cloudflare’s proxy, there’s no redirect interference and DCV will work as expected.

If you’re managing this at the WHM level, you can configure AutoSSL exclusions per-domain rather than per-account, giving you granular control over which domains use which certificate strategy.

What About Let’s Encrypt as the AutoSSL Provider?

Some hosting providers offer Let’s Encrypt as an alternative AutoSSL provider instead of Sectigo. Let’s Encrypt handles HTTP DCV redirects more gracefully — it will follow redirects during validation in many cases. However, this isn’t a guaranteed fix.

Let’s Encrypt can still fail when Cloudflare’s proxy is involved because the validation request may not reach the origin at all (Cloudflare may serve a cached response or interfere in other ways), or because the redirect chain becomes too complex. Additionally, switching AutoSSL providers is a server-level decision that requires WHM access and may not be available on shared hosting.

If you have the option and prefer to stick with AutoSSL rather than Origin CA certificates, switching to Let’s Encrypt is worth testing. But for a definitive, zero-maintenance solution, Origin CA certificates remain the better choice.

A Note on Page Rules and Configuration Rules

If you have specific requirements that prevent you from disabling “Always Use HTTPS” globally, Cloudflare offers a more targeted approach through Configuration Rules (the successor to the legacy Page Rules system).

You can create a rule that disables HTTPS enforcement specifically for the AutoSSL validation path:

• When: URI Path contains /.well-known/pki-validation/
• Then: Set Automatic HTTPS Rewrites to Off and SSL to Off

This allows DCV requests to pass through unmodified while keeping HTTPS enforcement active for all other traffic. It’s a middle-ground approach that lets you keep AutoSSL working without fully committing to Origin CA certificates.

That said, this approach still leaves you dependent on AutoSSL’s 90-day renewal cycle and adds another configuration point that can break silently. For most environments, the Origin CA approach is cleaner.

Summary: Which Approach Should You Use?

Scenario	Recommended Approach
Domains fully proxied through Cloudflare	Origin CA certificate + Full (Strict) mode
Domains with DNS-only (grey cloud) in Cloudflare	Standard AutoSSL
Domains not on Cloudflare	Standard AutoSSL
Mixed environment	Origin CA for proxied, AutoSSL for the rest
Shared hosting with no WHM access	Disable “Always Use HTTPS” before each renewal or ask your host about Origin CA support
Need a quick fix right now	Disable “Always Use HTTPS” → Run AutoSSL → Re-enable

The root of this problem is a documentation gap. cPanel’s AutoSSL documentation assumes your DNS points directly to the server. Cloudflare’s SSL documentation assumes you’re using their certificates. Neither product’s documentation accounts for the other, and yet running both together is one of the most common configurations in modern web hosting.

Hopefully this article bridges that gap. Install an Origin CA certificate, set Full (Strict), and move on to problems that actually deserve your attention.