Granular TLS Control: Per-Hostname Settings Now Available

Cloudflare has long offered two primary knobs for TLS configuration: the minimum TLS version and the list of supported cipher suites. Until now, however, these settings applied uniformly across an entire domain. That all-or-nothing approach worked well for many configurations, but it left organizations with mixed security requirements across their subdomains without a practical solution. As of today, customers can apply TLS settings on an individual hostname basis.

The Adoption Dilemma

The push for stronger encryption standards is frequently slowed by the reality of legacy clients. TLS 1.3, standardized by the IETF in April 2018, removed vulnerable cryptographic algorithms present in TLS 1.2 and reduced the handshake to a single roundtrip. Modern browsers and operating systems can update dynamically to adopt such standards, but older devices were built in an era when protocols evolved over decades, not years. They shipped with support for the standards of their time—and many remain in active use today.

According to Cloudflare Radar, roughly 62.9% of traffic currently uses TLS 1.3. That is substantial for a protocol standardized just five years ago, yet it still leaves a significant portion of internet traffic on TLS 1.2 or lower.

A similar trade-off exists for digital signature algorithms. ECDSA was standardized for TLS in 2006 and offers stronger security than RSA with shorter key lengths, improving performance on every request. But deploying ECDSA requires both an ECDSA certificate and clients that support cipher suites using elliptic curve cryptography (ECC). While most publicly trusted certificate authorities now offer ECDSA-based certificates, RSA remains the only option for many legacy systems. Restricting an application to ECC-only algorithms risks locking out users on older clients and devices.

Finding the Right Security Posture Per Subdomain

Security and accessibility are not always aligned, and the right balance depends on the nature of each endpoint. Consider a typical corporate domain structure: the root domain (example.com) often serves as a public marketing site, alongside blog.example.com, a management portal at dash.example.com, and an API gateway at api.example.com.

The marketing and blog properties are static and collect no user data—they should remain accessible to the broadest possible audience, including those on older hardware. The management portal and API gateway, by contrast, handle sensitive information and should enforce the strictest available protocols, dropping support for standards with known vulnerabilities.

To achieve this differentiated configuration, administrators need the ability to set TLS policies per subdomain, not just at the zone level.

Configuring TLS per Hostname

Cloudflare customers using Advanced Certificate Manager can now configure TLS settings on individual hostnames within a domain. This includes enabling HTTP/2, setting the minimum TLS version, and restricting supported cipher suites per hostname. Any hostname-level setting overrides the corresponding zone-level configuration. The feature also supports distinct policies for a hostname and its wildcard record, allowing example.com and *.example.com to be governed by different rules.

For example, an organization might keep the zone-wide minimum TLS version at 1.2 while raising the bar to TLS 1.3 specifically for its dashboard and API subdomains. After setting the zone-level minimum in the Cloudflare dashboard, requests to the per-hostname TLS settings API endpoint can be made with the desired hostname and setting value.

The per-hostname TLS settings endpoint is available now to Advanced Certificate Manager customers.