Addressing the unauthorized issuance of multiple TLS certificates for 1.1.1.1

Rogue certificates for 1.1.1.1: What happened and what it means for TLS trust

Cloudflare was recently notified, via our vulnerability disclosure program and the certificate transparency mailing list, that the Croatian Fina CA had issued twelve unauthorized certificates for 1.1.1.1, an IP address used by our public DNS resolver. The certificates were issued between February 2024 and August 2025. We have not observed unauthorized issuance for any other Cloudflare-managed property.

We have no evidence that these certificates were used maliciously. To actually impersonate the 1.1.1.1 service, an attacker would need the rogue certificate and its private key, would need targeted clients to trust Fina CA in their root store, and would need to intercept traffic between those clients and our resolver. All certificates have now been revoked, and we are awaiting a full post-mortem from Fina. While this lapse is ultimately Fina's responsibility, we should have detected it earlier, and we have identified internal failures that allowed it to go unnoticed for so long.

Why DoT and DoH depend on IP-address certificates

The DNS protocol as originally specified in RFC 1034 and RFC 1035 has no built-in privacy or authenticity protections; queries and responses are exchanged in plain text over UDP or TCP. Roughly 60% of the queries received by the Cloudflare 1.1.1.1 service still arrive this way. That leaves every query vulnerable to interception and modification by intermediaries.

To fix this, we helped develop DNS over TLS (DoT, RFC 7858) and DNS over HTTPS (DoH, RFC 8484). Both keep the DNS wire protocol largely untouched but replace the plain-text transport with TLS. During the TLS handshake, the server presents a certificate that proves its identity; the client validates that the certificate is signed by a Certification Authority (CA) in its root store before sending a single DNS query.

For DNS resolvers, those certificates differ from typical website certificates. When a browser connects to example.com, it first resolves the domain to an IP address, then connects to that address and validates a certificate containing the domain name. But a DNS client cannot resolve a domain name before it has a working resolver — it must connect directly to a known IP like 1.1.1.1. The certificate presented by the resolver must therefore contain the service's IP addresses, not just its hostnames. The Cloudflare public resolver serves certificates that include these addresses:

Certificate:
  Data:
      Version: 3 (0x2)
      Serial Number:
          02:7d:c8:c5:e1:72:94:ae:c9:ed:3f:67:72:8e:8a:08
      Signature Algorithm: sha256WithRSAEncryption
      Issuer: C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
      Validity
          Not Before: Jan  2 00:00:00 2025 GMT
          Not After : Jan 21 23:59:59 2026 GMT
      Subject: C=US, ST=California, L=San Francisco, O=Cloudflare, Inc., CN=cloudflare-dns.com
      X509v3 extensions:
          X509v3 Subject Alternative Name:
              DNS:cloudflare-dns.com, DNS:*.cloudflare-dns.com, DNS:one.one.one.one, IP Address:1.0.0.1, IP Address:1.1.1.1, IP Address:162.159.36.1, IP Address:162.159.46.1, IP Address:2606:4700:4700:0:0:0:0:1001, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:64, IP Address:2606:4700:4700:0:0:0:0:6400

How a certificate for 1.1.1.1 was issued without our permission

The services we describe above use certificates managed by Cloudflare. The Fina CA certificates are different: they were issued without our involvement, meaning Fina failed to verify that the requester controlled the IP address in question. Fina has stated:

"They were issued for the purpose of internal testing of certificate issuance in the production environment. An error occurred during the issuance of the test certificates when entering the IP addresses and as such they were published on Certificate Transparency log servers."

Publishing test certificates to Certificate Transparency is not itself an error — that is how rogue issuance is meant to be caught. The error is signing a certificate for an IP address without the controller's permission, using production keys. Fina should have used an IP address it controls itself rather than the Cloudflare public resolver's address, which has often been misused in documentation and lab environments.

Unauthorized issuance is not rare. It can stem from negligence, as with IdenTrust in November 2024, or compromise — the 2011 hack of Dutch CA DigiNotar, whose keys were used to issue hundreds of rogue certificates, was a wake-up call that led to the introduction of Certificate Transparency, formalized in RFC 6962. CT does not prevent misissuance; it makes it publicly detectable. CAs are required to submit certificates to public logs, and many browsers require SCTs proving inclusion in at least two independent logs. Domain owners can monitor those logs for certificates covering their names, and services like crt.sh and Cloudflare Radar's certificate transparency page make the data searchable.

Most DNS clients, unlike browsers, do not require proof of CT inclusion. Had Fina not submitted the certificates to public CT logs, this incident might not have been discovered at all.

Assessing the real-world attack surface

Three independent conditions would need to hold for these certificates to be exploited. We reviewed each:

1. Private key availability. The certificates were issued without our involvement, so we must assume a corresponding private key exists outside our control. Fina told us the keys remained in its controlled environment and were destroyed before revocation. We have no way to verify this, and we continue to monitor for signs of use.
2. Client trust in Fina CA. Fina CA is included in Microsoft's root store and in an EU Trust Service provider's program. It is not in the default root stores of Android, Apple, Mozilla, or Chrome, which limits the affected population. We contacted Fina, Microsoft, and the EU Trust Service provider immediately. Microsoft has started rolling out an update to its disallowed list that causes clients using it to stop trusting the Fina certificate.
3. Traffic interception. We launched an investigation into possible interception. A man-in-the-middle attack by an on-path device is likely to be invisible to us — clients receive responses from the interfering middlebox and we have no reliable way to detect it. Such interference has been a persistent problem for 1.1.1.1, which we have been addressing for years. Off-path attacks via BGP hijacking are also possible but harder to pull off at scale thanks to increasing RPKI route origin validation (ROV) adoption. We reviewed historical BGP announcements involving 1.1.1.1 and found no evidence of hijacks.

So far, we have seen no evidence that any of these certificates were used to impersonate our service — but we cannot be certain, and we outline below the steps we are taking to prevent future misuse.

What the unauthorized certificates looked like

The Fina certificates were all valid for exactly one year and included domain names alongside the IP address. Most of those domains are unregistered — a sign that no proper domain control validation was performed. That violates sections 3.2.2.4 and 3.2.2.5 of the CA/Browser Forum's Baseline Requirements, as well as sections 3.2.2.3 and 3.2.2.4 of the Fina CA Certificate Policy.

The domain names we identified on the unauthorized certificates:

fina.hr
ssltest5
test.fina.hr
test.hr
test1.hr
test11.hr
test12.hr
test5.hr
test6
test6.hr
testssl.fina.hr
testssl.finatest.hr
testssl.hr
testssl1.finatest.hr
testssl2.finatest.hr

The certificates' Subject attribute pointed to a fictional organization, TEST D.D., as shown here:

        Serial Number:
            a5:30:a2:9c:c1:a5:da:40:00:00:00:00:56:71:f2:4c
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=HR, O=Financijska agencija, CN=Fina RDC 2015
        Validity
            Not Before: Nov  2 23:45:15 2024 GMT
            Not After : Nov  2 23:45:15 2025 GMT
        Subject: C=HR, O=TEST D.D., L=ZAGREB, CN=testssl.finatest.hr, serialNumber=VATHR-32343828408.306
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:testssl.finatest.hr, DNS:testssl2.finatest.hr, IP Address:1.1.1.1

Timeline of the incident

All timestamps are UTC. Certificates are identified by their date of validity.

The first certificate was valid starting February 2024 and revoked just 33 minutes later. A total of 11 further certificates with common name 1.1.1.1 followed through August 2025. Public reports appeared on Hacker News and the certificate-transparency mailing list in early September 2025, which triggered our response.

Where Cloudflare failed, and what we are fixing

Cloudflare has long invested in CT. We operate public CT logs and run a CT monitor that alerts customers when certificates are mis-issued for their domains. It is disappointing that this monitoring failed to catch issuances for one of our own properties. We failed three times:

• Our alerting system did not flag IP-address certificates at all.
• Even when certificate issuance alerts would have fired, insufficient filtering meant important notices got lost in a high volume of mail.
• Because of the noisy monitoring, we had not enabled alerting across all the domains we own.

We rechecked all certificates for our names — including but not limited to 1.1.1.1 — using CT and confirmed that, as of 3 September, the Fina certificates are the only unauthorized issuances. We have contacted Fina and the root programs that trust it. The certificates are revoked.

We are acting on these lessons:

• Alerting: We will improve alerts and escalation for unauthorized issuance for Cloudflare-owned domains and for 1.1.1.1 certificates specifically.
• Transparency: The fact that most DNS clients do not enforce CT inclusion made this detection a lucky one. We are working to promote transparency for non-browser clients, particularly DNS clients using TLS.
• Bug Bounty: Triage delays in our vulnerability disclosure program slowed our response. We are revising that process to ensure reports get proper visibility.
• Monitoring: During this incident, our team relied on crt.sh as a convenient UI. We thank the Sectigo team for maintaining it. We are building a dedicated certificate transparency explorer in Radar and plan to support certs with IP addresses as common names there as well.

Recommended actions for operators and root-store managers

This incident underscores how fragile the root store model can be: a single poorly-behaving CA puts everyone who trusts it at risk.

If you manage a fleet of devices, check whether your clients are affected. The certificates are already revoked, but system-wide revocation is neither instantaneous nor automatic, so direct intervention may still be needed — the list is in the timeline section above.

If you oversee a root store program that includes Fina CA, review their inclusion. This incident raises serious concerns and warrants a clear report and follow-up. Consider requiring CT participation for all CAs in your root store; without CT, misissuance like this can go undetected until real user impact occurs.

We are not suggesting you abandon DoH or DoT. Plain DNS over UDP and TCP leaves every query at risk of tampering and surveillance. But client security would materially improve if DoH and DoT clients required server certificates to be included in CT logs — a standard that browsers already effectively enforce.

While this is the first rogue issuance we have observed against our public DNS resolver, it may not be the last. Our goal is to discover and alert on these events faster, and we intend to do so.