DEV Community

Cover image for DAX Futures Flash-Crash 8% as Europe Opens: What Triggered the Sell-Off?
Pranit
Pranit

Posted on

DAX Futures Flash-Crash 8% as Europe Opens: What Triggered the Sell-Off?

#productivity #webdev #programming #discuss

Why Cloudflare's "Automatic" SSL Might Be Silently Breaking Your API Integrations

Cloudflare's new SSL/TLS Recommender doesn't just suggest settings — it changes them automatically, and the upgrade from Flexible to Full can break backends that were never configured for internal HTTPS.

The Part Everyone Is Glossing Over

The headline feature here is "automatic SSL optimization," which sounds like pure upside. What the changelog doesn't emphasize: if you're on the Flexible SSL mode (where Cloudflare terminates HTTPS but talks to your origin over HTTP), the Recommender can silently upgrade you to Full mode — which requires your origin server to actually serve HTTPS.

This isn't a bug. It's working as designed. But for teams running internal services behind Cloudflare where the origin was "good enough" on port 80, you're about to get 502 errors and no obvious explanation in your application logs.

The Recommender runs periodically and applies changes without manual confirmation on zones where it's enabled. If you set up Cloudflare two years ago and forgot about the SSL settings, this is the kind of "improvement" that pages you at 2am.

How It Actually Works

Cloudflare's SSL modes control what happens on the back half of the connection — between Cloudflare's edge and your origin server:

User <--HTTPS--> Cloudflare Edge <--???--> Your Origin
Enter fullscreen mode Exit fullscreen mode

The modes break down like this:

  • Off: No HTTPS anywhere (please don't)
  • Flexible: HTTPS to Cloudflare, HTTP to origin
  • Full: HTTPS both sides, but origin cert isn't validated
  • Full (Strict): HTTPS both sides, origin cert must be valid and trusted

The Recommender tests your origin by attempting HTTPS connections and checking certificate validity. If it sees your origin can serve HTTPS, it assumes it should — and bumps your setting accordingly.

The logic is reasonable in isolation: if a valid cert exists, use it. The problem is that "origin can serve HTTPS" doesn't mean "origin is configured to serve your application over HTTPS." You might have a default nginx SSL config responding on 443 while your actual app runs on 80.

Here's what a minimal nginx config looks like that would trigger an upgrade but break your app:

# This exists because you once ran certbot
server {
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    # Returns default "Welcome to nginx" page
}

# This is your actual app
server {
    listen 80;
    location / {
        proxy_pass http://localhost:3000;
    }
}
Enter fullscreen mode Exit fullscreen mode

Cloudflare sees the valid cert on 443, upgrades to Full, and now all requests go to the default nginx page instead of your app.

What This Changes For You

If you're running anything behind Cloudflare, go check your SSL/TLS setting right now:

Dashboard → SSL/TLS → Overview

If you see "Flexible" and you don't have a real HTTPS setup on your origin, you have two options:

  1. Disable the Recommender: SSL/TLS → Edge Certificates → toggle off "SSL/TLS Recommender"
  2. Actually configure origin HTTPS: Use Cloudflare Origin CA certificates (free, 15-year validity, trusted only by Cloudflare — perfect for this use case)

The second option is the right long-term fix. Running HTTP between Cloudflare and your origin means anyone who can see that traffic (cloud provider, compromised network hop, rogue datacenter employee) sees plaintext. Flexible SSL was always a stopgap.

For API services specifically, test this before Cloudflare tests it for you:

curl -I https://your-origin-ip:443 -H "Host: yourdomain.com" --insecure
Enter fullscreen mode Exit fullscreen mode

If that returns your application's expected response, you're probably fine. If it returns a default page, connection refused, or times out — you have work to do before the Recommender does it for you.

The Catch

The Recommender is supposedly conservative — Cloudflare says it only upgrades when confident the origin can handle it. But "can handle it" is doing a lot of work in that sentence.

The check verifies the TLS handshake succeeds and a certificate exists. It doesn't verify that:

  • Your application code is actually reachable over that HTTPS endpoint
  • Health checks will still pass
  • Internal service-to-service calls that hardcode http:// origins will still work
  • Your load balancer or reverse proxy passes the request correctly

There's also no granular rollback. If the upgrade breaks something, you're manually changing the setting back and hoping you catch it before the next automated scan.

The notification system exists but it's easy to miss — just another email in the pile of Cloudflare alerts. If you're managing multiple zones, multiply that noise.

Where To Go From Here

The single most useful action: set up Cloudflare Origin CA certificates and switch to Full (Strict) intentionally, on your schedule, with proper testing.

# Generate via API or Dashboard, then configure your origin
# Dashboard: SSL/TLS → Origin Server → Create Certificate
Enter fullscreen mode Exit fullscreen mode

Documentation: https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/

This removes the Recommender from the equation entirely — you're already at the highest setting it can recommend. Takes 20 minutes and eliminates a whole category of surprise outages.

cloudflare, ssl, devops, security

Photo by Jamie Street on Unsplash

Top comments (0)