ZTNA Error 022 "Client certificate is not provided" after recent update – 2-hour drop cycle

Hi everyone,

We are running a FortiClient ZTNA Access Proxy deployment for our UAT environment and have run into a persistent connection loop immediately following the latest Fortinet ZTNA update. We are looking to see if anyone has hit this specific behavior or has a confirmed Bug ID/Workaround.

🚨 The Symptoms

• Error Encountered: ZTNA Application Not Found (Error Code: 022) with the message Client certificate is not provided. Device Information: N/A.

• Behavior: It only affects users connecting from external networks (off-fabric). Internal corporate network connections work fine.

• The Loop: When we perform clean reinstalls or manual re-registrations, it works perfectly for exactly 2 hours, and then abruptly drops back into Error 022.

🛠️ Troubleshooting & Root Cause Analysis Done So Far

We have thoroughly mapped out the behavior and ruled out basic configuration errors:

1. The 2-Hour Pattern & Compliance Discovered: * The 2-hour survival window strongly pointed to a periodic server-side event.

   • We discovered that an unapproved third-party security software bundle (RAV Network Protection) had slipped onto some end-user machines.

   • Isolation steps taken: We completely uninstalled RAV (including its VPN, Safer Web, and kernel drivers), rebooted, verified via Task Manager, and forced an EMS re-registration.

2. The Catch: * Even after clean uninstallation of the conflicting software, system reboots, and clean client re-installations, the 2-hour expiration loop continues.

   • Disconnecting/reconnecting the client manually drops the survival window down to about 1 hour. Clearing the browser SSL cache acts as another temporary fix, but the session breaks again on the next renegotiation interval.

3. Scale: * This is widespread across multiple users and machines, perfectly coinciding with the application of the recent ZTNA firmware/client update. The compliance tab is currently hidden/disabled via admin profile, making endpoint-side verification difficult.

 Our Hypothesis & Questions for the Community

Given that removing the compliance offender didn't permanently fix the loop, we suspect a deeper synchronization bug introduced in the latest release:

• Hypothesis A: The background compliance re-evaluation / certificate renewal loop between FortiClient and EMS is silently breaking or failing to update the local OS certificate store seamlessly.

• Hypothesis B: A known FortiOS desynchronization bug where the FortiGate proxy process (wad daemon) loses track of or drops the endpoint certificate data cached from the EMS connector (fcnacd), assuming the client is unauthenticated.

Has anyone encountered this specific 2-hour certificate drop cycle after the recent ZTNA updates? Is there a specific EMS telemetry telemetry keep-alive tweak or a firmware-specific hotfix we should look into?