Let's Encrypt Blocked by Cloudflare: When Strict SSL Causes Unrelated Domain to Display

The Initial Environment: Working Let's Encrypt AutoSSL

The website operated with a standard Let's Encrypt AutoSSL configuration that had been functioning reliably. Certificates renewed automatically every 90 days using HTTP-01 challenge validation. This system is effective across many sites and configurations when the validation path remains accessible.

DNS records were managed through the client's Cloudflare account. The website loaded properly, traffic flowed normally, and the certificate renewal system worked without intervention. This was a stable, production environment running on an Apache web server (VPS infrastructure).

Client DNS Management Policy and Access Restrictions

Against best practices, the client maintains sole control of Cloudflare DNS administration due to internal vendor security policy. All DNS and proxy configuration changes must be coordinated through email tickets that cross international timezones, creating multi-day delays for even simple configuration updates.

Cloudflare does significantly more than basic DNS record management. It operates as a reverse proxy, sitting between visitors and origin servers, handling traffic routing, caching, security filtering, and SSL/TLS termination. When Cloudflare is configured with certain default settings or security rules, it can alter how the origin server receives and processes requests in ways that disrupt existing infrastructure.

Why Let's Encrypt Certificate Renewal Gets Blocked by Cloudflare

The development team was alerted through their Overwatch monitoring program that an SSL certificate was approaching expiration. Investigation revealed that Let's Encrypt AutoSSL certificate renewals were failing. The automatic 90-day renewal cycle that had been functioning was no longer completing successfully.

This is a well-documented issue between Cloudflare's proxy architecture and Let's Encrypt's validation system. Let's Encrypt validates domain ownership before issuing certificates using the HTTP-01 challenge method: it places a token file at /.well-known/acme-challenge/ on the server and then attempts to retrieve it from Let's Encrypt's validation servers. If the file can be retrieved successfully, domain ownership is proven and the certificate is issued.

The problem occurs because Cloudflare's proxy sits between Let's Encrypt's validation servers and the origin server. When Cloudflare's default proxy settings are enabled, several mechanisms can prevent validation from completing:

The client's Cloudflare configuration was blocking this validation path. The discovery happened through proactive monitoring, not through a site outage. However, with the client maintaining sole administrative access and all configuration changes requiring email coordination across timezones, coordinating the specific Cloudflare settings adjustments needed to permit Let's Encrypt validation for every 90-day renewal cycle was not operationally sustainable.

The Solution: Cloudflare-Managed SSL with Full (Strict) Mode

To resolve the certificate renewal issue without requiring ongoing coordination between the client and development team, the decision was made to switch from Let's Encrypt origin certificates to Cloudflare-managed SSL certificates. This allowed Cloudflare to handle certificate lifecycle management entirely within their system, eliminating the validation path blockage.

Cloudflare offers three primary SSL modes for origin connections:

Flexible SSL

Flexible encrypts traffic between visitors and Cloudflare's edge servers, but connects to the origin server over unencrypted HTTP. From a visitor's perspective, the site displays a valid HTTPS padlock. However, the connection between Cloudflare's edge and the origin server transmits data in plain HTTP with no encryption.

For any site handling user accounts, form submissions, payment processing, or sensitive business data, this configuration is inadequate. Traffic between Cloudflare and the origin can be intercepted by anyone with network access along that path.

Full SSL

Full encrypts both legs: visitor-to-Cloudflare and Cloudflare-to-origin. However, it does not strictly validate the origin certificate. Cloudflare will accept self-signed certificates, expired certificates, or certificates issued for different domains. Encryption exists, but the certificate trust chain is not verified.

This provides protection against casual interception but does not protect against certain attack scenarios where an attacker could substitute their own certificate in a man-in-the-middle position between Cloudflare and the origin server.

Full (Strict) SSL

Full (Strict) requires valid, non-expired certificates issued by a trusted certificate authority, correctly matching the requested domain. Cloudflare verifies the entire certificate chain during every connection attempt. This is the only mode that provides properly validated end-to-end encryption from visitor to origin server.

Full (Strict) mode was enabled, and Cloudflare-managed certificates were provisioned for the origin server. This resolved the certificate renewal blockage and provided proper end-to-end encryption. However, during the propagation window as this configuration spread across Cloudflare's edge network, the unexpected redirect behavior occurred.

Initial Troubleshooting: The Standard Diagnostic Checklist

When the redirect behavior was observed (visitors requesting the intended domain were intermittently being shown an unrelated domain), standard troubleshooting procedures began:

WordPress Database Options Check

The WordPress wp_options table was queried for siteurl and home values. Both correctly pointed to client.com with no reference to the unrelated domain. A full-text search across all database tables for any occurrence of example.com returned zero results. The database contained no configuration directing traffic elsewhere.

.htaccess File Inspection

The .htaccess file was reviewed line by line for redirect rules, rewrite conditions, or any reference to the unrelated domain. All redirect logic pointed to the correct domain. No unexpected rules were present. The configuration matched what had been operational for months without issue.

Application Code Review

WordPress theme files, plugin configurations, and custom code were examined for programmatic redirects or domain references. The application layer showed no awareness of the domain appearing in visitor browsers.

Server Access and Error Logs

Server logs were analyzed for the time period when the redirect behavior began. This review was particularly important: no configuration file modifications were logged. No database updates. No code deployments. No manual changes of any kind.

Understanding Apache's Two-Phase HTTPS Connection Process

The redirect behavior occurred despite having no application-level configuration pointing to the unrelated domain. To understand this, you must understand how Apache processes HTTPS connections in two completely separate phases, and what happens when Phase 1 selects the wrong virtual host.

Phase 1: TLS Negotiation (Infrastructure Layer, Pre-HTTP)

Before any HTTP communication exists, before request headers are transmitted, before your application code executes, the TLS handshake must complete. This is the encryption negotiation that secures the connection.

During TLS negotiation, Apache must select an SSL virtual host and present a certificate to the client. Apache makes this selection based on:

• Server Name Indication (SNI): The hostname the client says it wants to connect to
• Certificate availability: Which virtual hosts have valid certificates installed
• Virtual host load order: The sequence in which Apache loads virtual host configurations

Here's the critical behavior: If Apache cannot successfully complete TLS validation for the requested hostname, it falls back to the first SSL virtual host capable of completing the handshake.

At this exact moment in the connection:

• No HTTP headers exist yet
• The Host header that applications use to determine routing does not exist
• .htaccess rules have not been evaluated
• WordPress configuration has not been consulted
• Application code has not run

This is infrastructure-layer behavior occurring in the TLS protocol layer, which operates below HTTP. Phase 1 must complete successfully before Phase 2 can begin.

Phase 2: HTTP Routing (Application Layer, Post-TLS)

Only after the TLS handshake completes successfully does Apache enter HTTP protocol territory. Now it:

• Reads the Host header from the HTTP request
• Routes to the intended virtual host based on that header
• Evaluates .htaccess rules in the selected virtual host's directory
• Executes application code

But if Apache selected the wrong SSL virtual host during Phase 1, you're already locked into that virtual host's context. All HTTP routing, all redirect logic, all application behavior, it belongs to whichever virtual host Apache selected during TLS negotiation, not the virtual host the visitor intended to reach.

This is why database checks found nothing. This is why .htaccess configuration showed correct settings. This is why the application had no awareness of the redirect. The correct application never executed. The redirect happened at the TLS layer before the intended application was reached.

When Strict SSL Causes an Unrelated Domain to Appear

When Cloudflare's SSL mode was changed to Full (Strict), that configuration needed to propagate across Cloudflare's global edge network (hundreds of data centers operating autonomously across six continents while maintaining eventual consistency).

A propagation window is the time period during which a configuration change spreads through a distributed system. There is no "update everywhere instantly" mechanism in distributed computing. Configuration changes propagate node by node, data center by data center. During this window, different parts of the system operate under different configurations. Some edge nodes complete the update immediately. Others take longer. Some attempt connections, experience validation failures, retry with different parameters, and gradually converge on the new settings.

This is normal distributed system behavior, not instability or malfunction. Global CDN networks operate through eventual consistency by design. During the convergence period, behavior can vary by:

• Geographic location (which edge data center handles the request)
• IP protocol version (IPv4 vs IPv6 routing paths)
• TLS session caching state (whether session parameters are cached locally)
• Timing (when the specific edge node received the configuration update)

The Cascading Effect: Propagation Inconsistencies Triggering Apache Fallback

During this propagation window, some Cloudflare edge nodes attempting strict certificate validation experienced temporary TLS validation failures. The exact technical mechanism varied (some IPv6 connections may have behaved differently than IPv4, some edge nodes may not have had updated certificate chains cached, some validation paths may have encountered routing delays).

The specific technical details of which validation attempts failed and why matter less than the outcome: when strict TLS validation failed, Apache's fallback behavior activated.

Apache examined its configured SSL virtual hosts and selected the first one capable of completing a TLS handshake. That selection happened to be a different domain entirely. Apache completed the TLS handshake using that virtual host's certificate. Phase 1 complete. Now Phase 2 begins (HTTP routing). The visitor's browser was now connected to the wrong virtual host context.

The intended website never processed the request. From the application's perspective, that traffic never arrived. This all occurred at the infrastructure layer before the correct application was invoked.

Why the Issue Resolved Automatically

As Cloudflare's edge network completed propagation, multiple factors converged:

• Edge nodes globally finished updating to the new SSL validation behavior
• TLS session caching stabilized across the network with updated parameters
• Certificate validation paths that initially failed began succeeding consistently
• Retry attempts during propagation stopped as the system reached equilibrium

Apache began consistently selecting the correct SSL virtual host for client.com. TLS handshakes completed successfully using the intended certificate. The redirect behavior ceased entirely.

No configuration changes were made to resolve this. No application settings were adjusted. The behavior was transient, tied to the distributed system's convergence window. Once propagation completed and the system reached a stable state, normal operation resumed automatically.

Why Development Teams Require DNS Access

This case illustrates why development teams need administrative access to DNS and proxy configuration systems, not as a matter of convenience but as an operational requirement for managing modern web infrastructure.

The Nature of Development Work

Web development and digital marketing operations require iterative testing, rapid deployment cycles, and immediate incident response capabilities. DNS configuration, SSL/TLS settings, CDN behavior, and caching rules all directly impact how applications function. When these systems require email requests, approval workflows, or multi-day response times, development work becomes operationally constrained.

Organizations that engage agencies like Custody & Agency delegate substantial control: access to edit website code, modify databases, manage advertising budgets in the tens or hundreds of thousands of dollars per month, handle customer data, configure analytics tracking, control brand identity through messaging and creative decisions. The fundamental operating principle is trust. You hire skilled professionals and provide them the tools necessary to perform their work effectively.

Restricting DNS access while simultaneously granting control over advertising spend, brand messaging, and customer-facing content is arbitrary security theater. If an organization cannot trust its vendor with DNS configuration (a system with robust built-in protections detailed below), they fundamentally cannot trust that vendor with PPC campaign management, brand identity decisions, or any other aspect of digital operations. The relationship lacks the foundation necessary for effective collaboration, and the organization should find a different vendor they do trust.

Internal IT Gatekeeping and Artificial Complexity

A common pattern occurs when internal IT departments treat DNS access as a specialized function requiring their exclusive control. Sometimes this stems from legitimate organizational policies. Other times it reflects job security concerns or institutional territoriality, treating routine DNS updates as requiring specialized knowledge that only internal staff possess.

The reality: DNS configuration is not inherently complex. Creating A records, CNAME records, TXT records for verification systems, and MX records for email is straightforward technical work. Modern development teams handle infrastructure far more complex than DNS record management. The specialized knowledge required for one-time email system setup or CRM integration does not make DNS management inherently beyond development team capabilities.

Development teams manage numerous verification and backup systems requiring DNS access:

• Domain ownership verification for search engines, analytics platforms, and advertising networks
• SSL certificate validation via DNS-01 challenges
• Email authentication records (SPF, DKIM, DMARC)
• CDN configuration and testing
• Subdomain creation for staging environments, testing, and feature branches
• Emergency traffic routing during incidents or attacks

When each of these requires an email to IT with multi-day response times, development work slows to an operational crawl.

DNS Security Mechanisms Already Exist

Concerns about unauthorized DNS changes are legitimate. However, robust protection mechanisms already exist:

• Registrar-level transfer locks prevent domain transfers without explicit authorization
• Two-factor authentication on DNS provider accounts prevents unauthorized access
• Cloudflare's access controls include audit logs, permission scoping, and activity monitoring
• Change notification systems alert when DNS records are modified
• Version control and rollback capabilities allow rapid recovery from errors

The proper process for DNS security is:

1. Enable registrar transfer locks to prevent domain theft
2. Require two-factor authentication on all accounts with DNS access
3. Grant development team members appropriate permission levels in Cloudflare or DNS provider accounts
4. Enable audit logging and change notifications
5. Establish documented procedures for emergency changes

This provides security without creating operational bottlenecks. Organizations can verify changes occurred appropriately without preventing them from occurring quickly.

The Operational Impact of Restricted Access

In this case, the client's decision to take sole DNS control created a multi-month coordination requirement for certificate renewals. The development team, capable of configuring Cloudflare to work with Let's Encrypt validation, could not implement the configuration changes because they lacked access. The client, with access, lacked the technical knowledge to configure the settings correctly.

The result: a functioning system became non-functioning due to access restrictions rather than technical limitations.

The workaround, switching to Cloudflare-managed certificates with Full (Strict) mode, was operationally efficient given the access constraints. But it was a workaround for an organizational problem, not a technical problem.

Understanding Apache's Behavior Pattern

This behavior pattern is universal to Apache servers hosting multiple SSL-enabled domains when strict certificate validation is enforced by edge proxies or CDNs. The occurrence requires specific conditions aligning simultaneously:

• Strict TLS validation enforced at the edge (Cloudflare, CloudFront, or similar CDN)
• Multiple SSL virtual hosts configured on the origin server
• Temporary certificate validation failures during edge propagation
• Redirect logic present in a virtual host that becomes the fallback selection

This is not an indication of server misconfiguration or hosting quality issues. Apache's TLS-layer fallback selection is documented behavior. Edge network propagation windows are inherent to distributed systems. Multiple virtual hosts on a single server is standard practice for agencies managing client portfolios.

What makes this situation unusual is the intersection of Cloudflare's strict validation requirements with Apache's fallback behavior during the propagation window. It's an edge case, but a valid, documented edge case that reveals how distributed web infrastructure actually operates beneath the application layer.

Importantly, modern web hosting architectures, whether using Apache, Nginx, LiteSpeed, or other web servers, all implement some form of virtual host selection during TLS negotiation. This isn't unique to Apache. The specific fallback mechanisms differ between web servers, but the fundamental pattern of "select a virtual host during TLS handshake before HTTP routing occurs" is universal.

Prevention and Infrastructure Hardening

To prevent this class of behavior from manifesting during future SSL configuration changes or edge propagation events:

1. Remove SSL Virtual Host Configurations for Inactive Domains

If a domain serves no active website and is used exclusively for email or other non-web services, it does not require an SSL virtual host configuration in Apache. Removing these configurations eliminates them as potential fallback targets during TLS negotiation.

This is the most effective prevention measure: if Apache has no alternate SSL virtual host to fall back to, even temporary validation failures during propagation cannot trigger redirect behavior.

2. Audit Apache's SSL Virtual Host Load Order

Apache loads virtual host configurations in a specific sequence, and this sequence determines fallback selection priority during TLS negotiation failures. Review the order in which virtual hosts are loaded and ensure that if fallback selection occurs, it selects a benign target rather than a virtual host with active redirect logic.

3. Remove Redirect Logic from Dormant Virtual Hosts

Even if a virtual host configuration must remain for technical reasons, remove any redirect rules from its configuration. If the virtual host is selected during fallback, having no redirect logic means the worst-case behavior is a connection failure rather than a redirect to an unrelated domain.

4. Ensure Active Domains Have Clear Certificate Renewal Paths

Whether using Cloudflare-managed certificates, manually-installed commercial certificates, or Let's Encrypt with proper validation paths configured, ensure that active domains have functioning certificate renewal mechanisms that work with the chosen edge proxy configuration.

5. Coordinate DNS and Proxy Access with Development Teams

Provide development teams with appropriate access to DNS management and CDN configuration systems. Enable audit logging and change notifications, but avoid creating operational bottlenecks that prevent rapid testing and incident response.

Frequently Asked Questions

Conclusion

This case documents how Cloudflare's Full (Strict) SSL mode, when enabled on a domain where Let's Encrypt certificate renewal was blocked by Cloudflare's proxy configuration, exposed Apache's TLS virtual host fallback behavior during the SSL configuration propagation window.

The redirect to an unrelated domain occurred entirely at the infrastructure layer, during TLS negotiation before HTTP routing began. This is why database queries found no references to the unrelated domain, why .htaccess configuration showed correct settings, and why application code had no awareness of the redirect. The intended application never executed because the redirect happened before the correct virtual host was reached.

Several factors contributed to this situation:

• Client-controlled Cloudflare configuration blocked Let's Encrypt renewal paths
• Development team lacked access to adjust Cloudflare settings to permit validation
• Full (Strict) SSL mode was correctly selected for security, triggering strict validation at the edge
• Cloudflare's propagation window created temporary TLS validation failures
• Apache's fallback behavior selected a virtual host with redirect logic configured

The solution, allowing propagation to complete without making application-level changes, proved correct. The behavior resolved automatically once Cloudflare's distributed edge network converged on the new configuration.

Key Takeaways

For anyone experiencing unexpected domain redirects after enabling Cloudflare's strict SSL validation: understand that you may be observing Apache's TLS-layer fallback behavior during Cloudflare's propagation window. Review SSL virtual host configurations, remove redirect logic from inactive domains, and ensure certificate renewal paths work with Cloudflare's proxy settings. Most importantly, coordinate DNS and proxy access with development teams to enable rapid testing and configuration adjustments when infrastructure changes are required.

-e