12 Erroneous Certificates Were Issued for Cloudflare's DNS Service 1.1.1.1

Last week it was revealed that a little-known certificate authority (CA), Fina, had improperly issued 12 TLS certificates for 1.1.1.1—Cloudflare’s popular DNS service—between February 2024 and August 2025. These certificates were created without Cloudflare’s permission and could have been used to decrypt requests protected by DNS over HTTPS (DoH) and DNS over TLS (DoT).

The discovery was almost accidental. A researcher on Mozilla’s dev-security-policy mailing list first noticed the suspicious entries.

How the Certificates Were Issued

The certificates came from Fina RDC 2020, a subordinate CA under the Fina Root CA. Because Microsoft trusts Fina Root CA, these certificates were also implicitly trusted by Windows and Microsoft Edge.

Cloudflare quickly confirmed the certificates were unauthorized:

“Cloudflare did not authorize Fina to issue these certificates. After seeing the report on the certificate-transparency mailing list, we immediately began an investigation and contacted Fina, Microsoft, and Fina’s TSP supervisory authority, who can address the issue by revoking trust in Fina or the misissued certificates,” the company stated.

Cloudflare also emphasized that the WARP VPN was unaffected.

Industry Response

Microsoft confirmed it had contacted Fina and demanded immediate action. The company said it was already taking steps to block the certificates. Meanwhile, Google, Mozilla, and Apple noted that their browsers never trusted Fina’s root, so their users were unaffected.

The problem highlights how the trust model works. TLS certificates contain a public key and details about the domain, while the issuing CA holds the private key that validates the certificate. Browsers verify certificates against a trusted list of CA public keys. Possession of both the certificate and its private key allows someone to cryptographically impersonate the domain.

For 1.1.1.1, this would have enabled a man-in-the-middle attack: intercepting, decrypting, and even altering DNS traffic.

Cloudflare summed it up bluntly:

“The certificate authority ecosystem is a castle with many doors: the failure of one certificate authority can compromise the security of the entire castle.”

The company also credited Certificate Transparency—a system it helped launch—with making the misissuance detectable.

What Went Wrong

Cloudflare’s own audit showed that 12 certificates had been issued, not three as initially reported, with the first dating back to February 2024.

Fina explained the incident in a brief email: the certificates were created during “internal testing of the issuance process in a production environment.” The error, they said, stemmed from “incorrect input of IP addresses.” They also emphasized that the certificates were logged publicly, private keys never left Fina’s environment, and the keys were destroyed before revocation.

Cloudflare, however, remains unconvinced. The company must assume that a corresponding private key could exist and be outside of its control—because there’s no way to verify Fina’s assurances.

Cloudflare’s Own Failures

In its report, Cloudflare admitted the incident also exposed shortcomings on its side. The company had not implemented effective monitoring of Certificate Transparency logs, which record every TLS certificate issued.

“We failed three times. First, because 1.1.1.1 is an IP certificate, but our system did not alert us to these cases. Second, because even if we received notifications about certificate issuance, like any of our customers, we did not implement sufficient filtering. Finally, due to overly ‘noisy’ monitoring, we did not enable alerts for all of our domains. We are working to address all three of these shortcomings,” Cloudflare wrote.

Why It Matters

This case underlines a recurring truth: the security of the TLS ecosystem depends not only on the strength of cryptography but also on the discipline of certificate authorities. Even a single CA’s mistake can ripple out, threatening millions of users.