Cloudflare Certificate Failures, June 2026: Let's Encrypt Chains Broke TLS

The short version: Cloudflare logged two minor certificate incidents three days apart in June 2026, one on June 2 running about 28.6 hours and one on June 5 running about 10.5 hours, both attributed to unsupported CA bundling on a subset of Let's Encrypt certificates that could fail the TLS handshake for some visitors. The lesson: a site can resolve and look completely valid in your own browser while failing TLS for a subset of clients on a certificate whose expiry date is perfectly healthy. The signal that surfaces that is an external HTTPS monitor that performs a real TLS handshake from outside, the same handshake a visitor's browser makes. That is what Velprove's SSL monitoring does: it reads the served leaf certificate and fails the run when the served certificate will not validate, on the free plan.

Here is the failure that this teardown is about: a site that resolves, answers at the application layer, and looks completely valid when you open it in your browser, yet fails the TLS handshake for a subset of visitors. The certificate's expiry date is healthy the entire time, so nothing about the date is wrong. The problem is the chain the server bundles and serves to clients. That is exactly the shape Cloudflare published twice in June 2026, and it is a shape a days-remaining number never sees.

What broke on Cloudflare in June 2026 (and what didn't)

Cloudflare's own wording is the anchor here, so we quote it rather than paraphrase past it. In both incidents, Cloudflare stated that an unsupported CA bundling issue affected a subset of Let's Encrypt certificates and may have resulted in TLS connectivity issues for some visitors. Read those qualifiers literally. It was a subset, not all certificates. It was some visitors, not everyone. And the verb was may, because the failure was partial and client-dependent.

The mechanism Cloudflare named is the served certificate chain, not the certificate's issuance. Unsupported CA bundling describes the bundle of certificates a server sends a client so the client can build a trusted path back to a root. When that bundle is wrong, a strict client cannot complete the path and rejects the connection, even though the leaf certificate is genuinely valid. This was not Let's Encrypt failing to issue certificates, and it was not a Cloudflare private-key problem. Issuance worked. Unaffected certificates worked. The application layer behind the certificate was fine. What broke was the chain served to some clients.

One consequence worth stating once: an interactive browser that hits a broken served chain often shows a warning a human can click through, while an automated client hard-fails the handshake with nobody there to override it. We do not re-teach that mechanic here because it is the subject of a separate post; for the full browser-versus-machine-client breakdown and the chain mechanics behind it, see when SSL renewal automation fails silently.

The timeline (UTC, primary-source)

Cloudflare recorded two distinct incidents three days apart, both on the SSL Certificate Provisioning component, both impact minor, both describing the same unsupported CA bundling cause. The updates below are quoted verbatim from the Cloudflare status incident permalinks. All times are UTC. Incident A's official title carries the spelling “Lets Encrypt” without an apostrophe, which we leave as Cloudflare published it.

Incident A: June 2 00:25 UTC to June 3 05:01 UTC, roughly 28 hours 36 minutes. Source: Cloudflare Status incident j17t8xz91xs0.

Incident B: June 5 17:22 UTC to June 6 03:53 UTC, roughly 10 hours 30 minutes. Source: Cloudflare Status incident rsb9bsncwr64.

The two records share identical cause language and identical remediation language. It is tempting to call them one event, but Cloudflare did not. There is no combined post-mortem and no statement that June 5 was a recurrence of June 2. We treat the shared root cause as an inference from the matching wording, not as a fact Cloudflare asserted. What is certain is that the same failure shape was logged twice in four days.

Why a broken served chain is hard to catch

Start with the date, because the date is the trap. Throughout both windows, the leaf certificate's expiry was healthy. Nothing was about to lapse. So a monitor that counts down days until expiry, the right tool for catching a certificate that is genuinely about to expire, would have read green the entire time and never fired. This is not the expiry failure class; for the days-remaining countdown and the 30-15-7 threshold rule that governs it, see SSL certificate expiry monitoring. That post owns the countdown. This failure lives where the countdown goes blind.

Then there is the partial shape. Cloudflare said some visitors, not all. A chain that is mis-bundled can still validate for a client that already has the missing piece cached or bundled, and fail for a client that needs the served chain to be complete and correct. So the failure can hide from any single observer whose TLS stack happens to accept the served chain. Your laptop validates it; a partner's stricter client does not. And because the site answers at the application layer, every surface that is not the TLS handshake itself looks up.

Put those together and you get the most deceptive kind of outage: a valid-looking site, a healthy expiry date, a working application, and a TLS handshake that fails for a subset of the people trying to reach you. The only instrument positioned to see it is one that makes the same handshake a real client makes, from outside.

How Velprove monitors TLS/SSL certificates

An external HTTPS monitor performs a real TLS handshake from a vantage point outside your infrastructure, exactly the way a visitor's browser does. The moment a served certificate stops validating, that handshake fails and the monitor flips to Down. That is the detection signal an internal or application-layer view misses, because internally the application is still answering and the certificate file on disk still looks fine. The failure only exists on the wire, between a real client and the served chain, which is precisely where an outside handshake looks.

Setting this up is a single HTTPS monitor pointed at the hostname you serve. On each run it completes a real TLS handshake, and if that handshake fails because the served certificate does not validate, the monitor records a Down result rather than a quiet green. That detection is the base behavior of an HTTPS monitor; it needs no extra option turned on, because a failed handshake is a failed run. The wizard also offers an SSL certificate expiry alert toggle that adds a days-remaining countdown and reads the served leaf certificate, its expiry date and its issuer, but that countdown is a separate, complementary signal: it watches for a certificate that is about to lapse, which is not what failed here. There is no configuration file to hand-write and no code to maintain.

To see the symptom concretely, point a monitor at a host that deliberately serves a certificate a standard client will not trust, such as one of the badssl.com test hosts. The handshake fails closed, and the monitor flips to Down with a connection error, the same error a real client would hit. That is the alert that would have surfaced a served-chain failure from outside, with no chain expertise required to read it.

The honesty boundary

The strongest version of this post is the one that names what it does not claim. Four limits matter here.

First, the boundary on what Velprove reads. Velprove's SSL monitoring reads the served leaf certificate, its expiry and issuer, and the HTTPS handshake fails when the served certificate is invalid. It does not introspect the full chain and it does not diagnose the CA-side cause. So it tells you that TLS is failing for clients. It does not tell you that the reason is unsupported CA bundling. For walking and grading the served chain on a specific host, use a dedicated chain inspector like SSL Labs.

Second, detection here is vantage and client-dependent. Because the failure hit a subset of clients, whether a given probe trips depends on whether that probe's TLS client needs the broken part of the served chain. Catching a partial-subset failure from one vantage is a realistic possibility, not a guarantee. This is the same hard-fail shape that bites machine-to-machine clients with no human to click through, including pinned mobile clients, covered in monitoring a mobile app backend.

Third, and most important: Velprove did not detect this specific Cloudflare incident. We have no such observation. This is an illustrative teardown of the failure class and the detection mechanism, not a claim that any Velprove monitor caught the June 2026 events.

Fourth, detection is not prevention. An external handshake surfaces a served-chain failure faster than a human spot-check or a green expiry badge will. It does not stop the failure from happening. The value is knowing, early, that real clients cannot connect.

This pattern, not just this incident

A valid-looking site that fails TLS for a subset of clients is a recurring silent-outage shape, not a one-off. Cloudflare logging the same shape twice in four days is itself the point: this is a pattern with a name and a detection instrument, not a freak event. The broader taxonomy of outages that answer green to a naive check lives in the anatomy of a silent outage, and a sibling dated teardown of a different vendor incident, where the response body told a truth the status code hid, is the GitHub Actions May 2026 detection teardown. Same lesson, different surface: what a real client experiences is the only thing worth asserting on.

What to monitor for TLS and SSL

The recommendation is small and concrete. Run an HTTPS monitor against each hostname you actually serve, on the free plan, from one region you pick out of the five available. The HTTPS monitor completes a real TLS handshake from outside on every run by default, so a served certificate that stops validating surfaces as a Down result instead of hiding behind a healthy expiry date and a working application. Add the SSL certificate expiry alert toggle if you also want a days-remaining countdown for the separate case of a certificate about to lapse.

Keep the boundary in mind as you do it: this reads the served leaf and fails the handshake on an invalid served certificate; it does not diagnose the chain, so pair it with SSL Labs when you need to know why a chain is malformed. Detection from outside is what turns a partial, valid-looking TLS failure into an alert you can act on.

Set up a free HTTPS monitor with Velprove. A real TLS handshake from the region you choose, no credit card required, commercial use allowed on every plan including free.

Frequently Asked Questions

What happened in the Cloudflare certificate outage in June 2026?

Cloudflare logged two minor incidents on its SSL Certificate Provisioning component: one on June 2 2026 lasting roughly 28.6 hours, and one on June 5 2026 lasting roughly 10.5 hours. In both, Cloudflare's published cause was an unsupported CA bundling issue affecting a subset of Let's Encrypt certificates, which may have caused TLS connectivity issues for some visitors. This was a certificate serving and chain-bundling problem, not a certificate issuance failure. Cloudflare rebuilt the affected certificate chains, and the affected certificates were automatically restored to a valid state, so no customer action was required.

Was the whole Cloudflare network down in June 2026?

No. Cloudflare labeled both incidents minor, and the stated scope was a subset of Let's Encrypt certificates and some visitors. This was not a network-wide outage. Most traffic and most certificates were unaffected. The failure was partial and client-dependent, which is part of why it is hard to notice.

Was the Cloudflare cert issue Let's Encrypt's fault or Cloudflare's?

Cloudflare's published cause was an unsupported CA bundling problem on the served chain, which is a serving and chain-construction issue, not a Let's Encrypt issuance failure. Cloudflare did not attribute the incidents to a Let's Encrypt-side outage, and neither do we. We also do not assert a single confirmed root cause shared by the two windows. The wording in both records is identical, but Cloudflare published no combined post-mortem, so a shared root cause is an inference, not a stated fact.

Can a monitor catch a certificate that fails for only some clients?

An external HTTPS monitor performs a real TLS handshake from outside and flips to Down when the served certificate fails to validate for its probe. For this failure class, that is a realistic catch. But on a partial-subset failure the detection is vantage and client-dependent: whether a given probe trips depends on whether that probe's TLS client needs the broken part of the served chain. So it is a realistic possibility, not a guarantee for every such incident.

Did Velprove detect the Cloudflare cert issue in June 2026?

No. We have no such observation. This post is an illustrative teardown of the failure class and the detection mechanism an external TLS handshake provides. It is not a claim that Velprove caught this specific Cloudflare incident.

What can Velprove's SSL monitoring tell me, and what can't it?

Velprove's SSL monitoring reads the served leaf certificate, meaning its expiry date and issuer, and the HTTPS handshake fails when the served certificate is invalid. So it catches that TLS is failing for clients. It does not introspect the full chain or diagnose the CA-side cause such as unsupported CA bundling. For walking and grading the served chain, use a dedicated chain inspector like SSL Labs.