Cloudflare's TLS Bug Hit Twice in One Week
A recurring Let's Encrypt CA bundle bug broke TLS handshakes on Cloudflare twice in seven days, leaving some sites unreachable. Here's what went wrong.
The first time Cloudflare’s Let’s Encrypt certificate chains broke, you could call it a bad week. When the same bug class came back four days later, it became harder to write off. Between May 31 and June 6, 2026, a CA bundle misconfiguration in Cloudflare’s Let’s Encrypt certificates caused TLS handshake failures for a subset of websites, twice in seven days.
What happened
On May 31, 2026, Cloudflare identified an “unsupported CA bundling” issue in certain Let’s Encrypt certificates served through its edge network. The problem was confirmed on June 2 and resolved by June 3. Visitors to affected sites saw connection errors instead of the pages they expected.
On June 5, the same bug class showed up again. Cloudflare’s status page opened a new incident at 1:22 PM ET, describing an identical unsupported CA bundle configuration. Engineers worked through the evening and confirmed the fix by 11:53 PM ET, about ten hours later.
Then on June 6, a separate hardware failure at Cloudflare’s Dallas data center generated HTTP 500 errors for about 20 minutes. Different problem, but the timing didn’t help.
Why a bad CA bundle breaks connections
When your browser connects to an HTTPS site, the server sends the full certificate chain: the leaf certificate for the domain, an intermediate certificate signed by a Certificate Authority, and sometimes a cross-signed bridge back to a root CA that the browser trusts. The browser walks this chain link by link, checking each signature, until it reaches a root it recognizes.
If any link is misconfigured, verification fails. The browser doesn’t show a certificate warning. It refuses to connect. On mobile clients and API integrations that don’t cache intermediate certificates from prior visits, there is no fallback.
The tricky part at CDN scale is the inconsistency. A desktop browser that has visited the site before may have the correct intermediate cached and connect fine. A mobile user visiting for the first time sees an error. That makes these bugs hard to catch in testing and hard for site operators to reproduce when user reports start coming in.
When 20% of web traffic runs through one provider
Cloudflare routes roughly 20% of global web traffic. It handles DNS resolution, TLS termination, DDoS protection, and bot management for millions of sites. A certificate chain bug on their end affects sites whose operators never touched a certificate configuration themselves.
The June incidents landed in a week that also included a Cloudflare API service disruption, a WARP connectivity problem, and network performance issues in the US Eastern region. None of these matched the scale of Cloudflare’s November 2025 global outage, which took down X, Substack, Canva, and Downdetector at the same time. But the frequency is getting hard to ignore.
Ryan Polk, Director of Policy at the Internet Society, said after the November event: “When too much internet traffic is concentrated within a few providers, these networks can become single points of failure that disrupt access to large parts of the internet.”
What to do about it
If your site relies on Cloudflare for TLS termination with Let’s Encrypt certificates, you were potentially exposed during both incidents. Cloudflare said it would automatically rebuild all impacted certificate chains, so no customer action was required. Customers who needed an immediate fix could re-issue their certificates manually.
The bigger question is what your monitoring looks like when a CDN silently serves broken certificate chains. A standard uptime monitor checking from one location with a warm TLS cache might not catch it at all.
Worth reviewing: are you monitoring from multiple locations and client types? A desktop browser in your office may report an all-clear while mobile users in another region see errors. Synthetic monitoring that clears its TLS cache between checks is more likely to catch chain issues early.
Even if your CDN manages certificate issuance, you should know which CA is signing your certificates, which intermediates are in the chain, and whether your setup depends on cross-signed bridges that could change. Running openssl s_client -connect yourdomain.com:443 -showcerts gives you the full chain in seconds.
And think about what happens if your CDN goes down entirely. During Cloudflare’s November 2025 outage, organizations with a secondary CDN or fallback DNS shifted traffic automatically. Those that used Cloudflare for both DNS and CDN found that their fallback path was also Cloudflare.
Don’t wait for the postmortem
Certificate chain bugs are the kind of problem where your site looks fine from your desk while a slice of your users can’t connect. The error messages give them nothing useful, and half the time nobody notices until a customer complains on Twitter.
SSLcalendar.com tracks your certificate expirations and sends reminders before renewals become emergencies. If you need to monitor TLS health across your infrastructure, including chain validation and misconfigured intermediates, SSLboard.com catches those problems before your users do.
Cloudflare has not published a postmortem for either the May 31 or June 5 CA bundle incidents as of this writing.
Sources: TechTimes: Cloudflare Outage: Dallas Hardware Fault and Recurring TLS Bug Strike in One Weekend, Cloudflare Status