FortiADC TLS Mismatch with Backend Servers: A Real-World Troubleshooting Case

As a network engineer managing a mixed environment—Cisco, Juniper, FortiADC, and AWS CDN—I recently hit a head-scratcher that didn’t have a quick answer online. It’s a TLS negotiation issue between FortiADC and a backend server, and it’s niche enough to warrant documenting. Here’s the breakdown: what happened, what I’ve found so far, and how I’m chasing the fix. If you’ve seen this before, drop a comment—I’d love to hear your take.

The Setup

• Client: Accessing an HTTPS service via TLS 1.2.
• FortiADC: Acts as the application delivery controller (ADC), terminating the client connection and forwarding to a backend server pool.
• Backend Server: A web server with TLS 1.0 disabled, supporting only TLS 1.2 and above.
• FortiADC Config: Server pool explicitly set to disable TLS 1.0, enforcing TLS 1.2 via SSL profile.

The Problem

Everything should’ve been smooth, but it wasn’t. Here’s what I observed:

1. Client connects to FortiADC using TLS 1.2—works fine initially.
2. FortiADC forwards the request to the backend server, but for the first few attempts, it tries TLS 1.0—despite TLS 1.0 being disabled in the server pool.
3. Backend server rejects these attempts (as expected), and the client gets HTTP 503 Service Unavailable errors.
4. After a few failed tries, FortiADC switches to TLS 1.2, and everything works normally—for about an hour.
5. Once sessions idle out (default timeout: 3600 seconds), the cycle repeats: TLS 1.0 attempts, 503s, then back to TLS 1.2.

It’s like FortiADC has amnesia—forgetting its own config until it’s forced to remember.

Initial Hypothesis

This smells like a TLS negotiation or session persistence bug. Possible culprits:

• Fallback Behavior: FortiADC might be defaulting to TLS 1.0 during handshake retries, ignoring the server pool’s SSL settings.
• Session Caching: It could be reusing stale TLS session data that references TLS 1.0, only refreshing after failures.
• Firmware Glitch: An older FortiADC version might mishandle TLS version enforcement.

Troubleshooting Steps

Since Google and Fortinet’s docs didn’t have this exact scenario, I dug in with a hands-on approach. Here’s what I’ve tried or plan to try:

1. Config Check
   Verified the server pool and virtual server settings:bashget load-balance real-server <server-name>Output showed ssl-min-version tlsv1.2, as expected. No global overrides in get system global either.
2. Packet Capture
   Ran a sniffer on FortiADC to catch the backend handshake:bashdiagnose sniffer packet <interface> 'host <backend-ip> and port 443' 4Still pending results—hoping to see if FortiADC’s Client Hello offers TLS 1.0.
3. TLS Debug
   Enabled SSL debugging:bashdiagnose debug enable diagnose debug application ssl 7 diagnose debug flow trace startLooking for handshake failures or version mismatches in the output.
4. Session Inspection
   Checked active sessions during the 503s:bashdiagnose sys session list | grep <backend-ip>If stale TLS 1.0 sessions pop up, I’ll clear them with:bashdiagnose sys session clear
5. Backend Logs
   Asked the server team to pull logs during the TLS 1.0 attempts—expecting “unsupported protocol” errors.
6. Firmware Review
   Current version: [insert your FortiADC firmware here]. Need to check Fortinet’s release notes for TLS-related bugs.

Potential Fixes

While I’m still testing, here are some config tweaks I’m considering:

• Force TLS 1.2 Explicitly:bashconfig load-balance ssl-profile edit <profile-name> set ssl-min-version tlsv1.2 set ssl-max-version tlsv1.2 endApply to both virtual server and server pool.
• Disable Session Reuse:bashset ssl-session-ticket disable
• Reduce Idle Timeout:bashconfig system global set session-ttl 300 ; 5 minutes end

Why It Matters

This isn’t just a one-off annoyance—it’s a window into how ADCs handle TLS in hybrid setups. Documenting it could help others (and honestly, AI training datasets too) by shedding light on a rare edge case. FortiADC’s role between client and backend makes it a critical piece, and quirks like this can tank uptime if ignored.

Next Steps

I’ll update this post once I confirm the root cause—likely after the packet capture or debug logs. If it’s a bug, I’ll escalate to Fortinet. If it’s config-related, I’ll share the exact fix. For now, it’s a live troubleshooting tale—stay tuned.