Cloudflare’s privacy-focused 1.1.1.1 DNS resolver has been thrust into the spotlight after a subordinate certificate authority improperly issued transport layer security (TLS) certificates containing the IP address 1.1.1.1. The misissuance, uncovered via Certificate Transparency logs months after the fact, exposes a risky gap in the internet’s trust model and raises fresh concerns about encrypted DNS traffic security.
What Went Wrong
A subordinate CA known as Fina RDC 2020 issued three certificates that listed iPAddress:1.1.1.1 in the Subject Alternative Name field—despite not controlling that address. The 1.1.1.1 resolver is operated by Cloudflare in partnership with APNIC and is one of the most widely used public DNS services globally.
Under CA/Browser Forum Baseline Requirements, certificate authorities must validate demonstrable control of any IP address included in a certificate. Including 1.1.1.1 without Cloudflare’s authorization violates those rules and could enable attackers, under the right conditions, to present a seemingly valid certificate when intercepting traffic to that IP.
The affected certificates were issued by a CA participating in the Microsoft Root Certificate Program, meaning they could be trusted by Windows and applications that use the Windows trust store. Notably, Mozilla, Google, and Apple have indicated that their root programs do not trust this CA, narrowing but not eliminating real-world impact.
Why 1.1.1.1 Matters
Cloudflare’s 1.1.1.1 is a privacy-first resolver that supports DNS over HTTPS (DoH) and DNS over TLS (DoT). Cloudflare reports that the service processes billions of queries daily. Any event that might undermine the confidentiality or authenticity of its encrypted sessions reverberates widely across consumer devices, enterprise networks, and privacy tools.
DoH and DoT rely on TLS to verify that clients are talking to the intended resolver. If a client accepts a certificate that lists an IP address and that IP appears in the certificate’s SAN, a malicious intermediary could, in theory, terminate TLS and observe or manipulate DNS lookups. The realistic risk depends on client behavior: many DoH clients validate hostnames (for example, cloudflare-dns.com), while some DoT or embedded clients may connect by IP and accept IP-based identities.
Scope and Immediate Impact
Cloudflare stated it did not authorize any certificates for 1.1.1.1 and has been coordinating with Microsoft and the Croatian authorities overseeing Fina’s PKI operations. Microsoft has moved to revoke and disallow the misissued certificates in its ecosystem. At the time of disclosure, some certificates remained valid pending revocation, underscoring the lag that can occur between discovery and effective mitigation.
Cloudflare noted its WARP VPN service is unaffected. The primary concern centers on encrypted DNS traffic paths where clients might accept IP-based SANs. There is no public evidence of exploitation, but the combination of certificate misissuance and potential network interception—think BGP hijacks or local network manipulation—warrants alertness.
A Familiar Weak Point in the CA System
Misissuance is not new. Past crises—from DigiNotar’s collapse to the eventual distrust of Symantec’s legacy PKI and the removal of other problematic CAs—show how a single weak link can ripple across the web’s trust fabric. The current incident highlights two systemic issues: verification rigor for IP identities and the time it can take for Certificate Transparency monitoring to flag obvious anomalies.
Certificate Transparency was designed to make every publicly trusted certificate visible, enabling rapid auditing. Yet these certificates sat in logs for months before broad awareness, suggesting that automated alerting for high-value IP ranges is either underused or ineffective. For critical addresses like 1.1.1.1, proactive watchlists and policy-based alerts should be standard across CT monitors used by browser vendors, CAs, and major network operators.
Technical Risk: How an Attacker Might Leverage This
In a plausible adversary-in-the-middle scenario, an attacker who can reroute traffic to 1.1.1.1 could present a misissued certificate containing that IP in the SAN to some clients. If the client’s resolver stack accepts IP-based identities and does not pin a hostname, the attacker may decrypt DoT or DoH sessions, observe queried domains, and potentially serve tampered answers. The feasibility hinges on client validation rules, revocation status, and the attacker’s ability to control the network path.
Best-practice clients validate the resolver’s hostname and reject IP-only identities for encrypted DNS. That single design choice dramatically reduces exposure from this class of CA failures.
What Enterprises and Users Should Do
– Prefer resolver configurations that use a known authentication domain name, not just an IP literal, for DoT and DoH.
– On Windows environments, ensure revocation checking is enabled and up to date; monitor Microsoft advisories and consider local disallow policies for known-bad thumbprints via group policy or MDM.
– Network teams should set up CT log monitoring for sensitive domains and IP ranges. Many security operations centers already watch certificates for internal domains; extending that to public resolvers and other critical infrastructure is prudent.
– Developers embedding DNS privacy features should enforce hostname validation for TLS and avoid accepting IP-based SANs unless absolutely necessary.
The Bigger Fix
This episode reinforces the need for sharper programmatic controls within CA ecosystems. Stronger pre-issuance linting for IP SANs, mandatory incident reporting timelines, and faster, coordinated revocation across root programs would materially cut risk. Browser and OS vendors can further reduce the blast radius by aligning on policy and automating disallow lists for certificates that reference well-known critical infrastructure.
For now, the damage appears contained. But the lesson is clear: even with Certificate Transparency and rigorous baseline requirements, trust on the internet still depends on relentless verification and on clients making the most secure choices by default.