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 FarWe have thoroughly mapped out the behavior and ruled out basic configuration errors: 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. 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. 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 CommunityGiven 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?Any help, bug tracking IDs, or CLI debugging insights would be greatly appreciated!

Hi,Thank you for the detailed analysis and for sharing the two possible hypotheses.The consistent two-hour interval is certainly relevant; however, at this stage, it does not by itself confirm that the issue is caused by an EMS compliance/certificate renewal cycle or by synchronization between the EMS connector and WAD.The key indication we currently have is the FortiGate reporting:"Client certificate is not provided. Device Information: N/A"Before we can validate either hypothesis, we need to determine at which stage the endpoint identification is being lost.In particular, we need to establish:Whether the ZTNA certificate remains present and valid on the endpoint before and after the two-hour interval.Whether FortiClient actually presents the certificate when the failing connection is initiated.Whether the endpoint remains connected/compliant and correctly identified in EMS at the time of failure.Whether FortiGate still has the expected endpoint/tag information from the EMS connector when the failure occurs.What WAD receives and processes during a successful connection compared with the failed connection.This comparison is important because EMS tag synchronization and presentation of the ZTNA client certificate during the connection are separate parts of the ZTNA process. A valid endpoint/tag state in EMS does not necessarily confirm that the certificate was presented during the failing connection.Could you therefore please provide the exact FortiClient, EMS and FortiOS versions and collect FortiClient diagnostic logs and the corresponding FortiGate debug output for one successful connection and one failed connection after the two-hour interval?If possible, please avoid reinstalling or re-registering FortiClient before collecting the failed-state information, as the state while the issue is occurring will be particularly useful in determining where the endpoint identification is being lost.Once we establish whether the certificate is missing at the client side, not being presented, or is being received but not associated with the endpoint on the FortiGate, we can determine whether further investigation of EMS synchronization/WAD behavior is required.Regards,Suraj

Z

zxcbnm

Visitor III

Question

ZTNA Error 022 "Client certificate is not provided" after recent update – 2-hour drop cycle (EMS Compliance Scan vs. WAD Cache Bug?)

Forum|Forum|28 days ago
August 12, 2026
4 replies
109 views

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:

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.
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.
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?

Any help, bug tracking IDs, or CLI debugging insights would be greatly appreciated!

Stephen_G

Staff & Editor

Hi zxcbnm,

Thank you for using our forums. We will seek to get you an answer or help.

In the meantime, if anyone else has any advice, please feel free to contribute.

Stephen_G - Fortinet Community Team

Stephen_G

Staff & Editor

Hi zxcbnm,

We are still looking to get you an answer or help, and will reply as soon as possible.

Stephen_G - Fortinet Community Team

srajeswaran

Staff

Hi,

Thank you for the detailed analysis and for sharing the two possible hypotheses.

The consistent two-hour interval is certainly relevant; however, at this stage, it does not by itself confirm that the issue is caused by an EMS compliance/certificate renewal cycle or by synchronization between the EMS connector and WAD.

The key indication we currently have is the FortiGate reporting:

"Client certificate is not provided. Device Information: N/A"

Before we can validate either hypothesis, we need to determine at which stage the endpoint identification is being lost.

In particular, we need to establish:

Whether the ZTNA certificate remains present and valid on the endpoint before and after the two-hour interval.
Whether FortiClient actually presents the certificate when the failing connection is initiated.
Whether the endpoint remains connected/compliant and correctly identified in EMS at the time of failure.
Whether FortiGate still has the expected endpoint/tag information from the EMS connector when the failure occurs.
What WAD receives and processes during a successful connection compared with the failed connection.

This comparison is important because EMS tag synchronization and presentation of the ZTNA client certificate during the connection are separate parts of the ZTNA process. A valid endpoint/tag state in EMS does not necessarily confirm that the certificate was presented during the failing connection.

Could you therefore please provide the exact FortiClient, EMS and FortiOS versions and collect FortiClient diagnostic logs and the corresponding FortiGate debug output for one successful connection and one failed connection after the two-hour interval?

If possible, please avoid reinstalling or re-registering FortiClient before collecting the failed-state information, as the state while the issue is occurring will be particularly useful in determining where the endpoint identification is being lost.

Once we establish whether the certificate is missing at the client side, not being presented, or is being received but not associated with the endpoint on the FortiGate, we can determine whether further investigation of EMS synchronization/WAD behavior is required.

Regards,
Suraj

S

s1k0_s3ba

Visitor III

i agree with @srajeswaran that comparing the working and failed state before reinstalling or re-registering the client is probably the most useful next step.

one additional thing worth checking is the forticlient fortitcs_1.log fortinet recently published a troubleshooting article specifically for error 022, so it may help correlate what forticlient is doing at the exact failure timestamp.

https://community.fortinet.com/forticlient-4/troubleshooting-tip-ztna-application-not-found-error-with-error-code-022-in-ztna-tcp-forwarding-229547

there are also a couple of previously documented forticlient bugs with similar certificate symptoms:

bug 919832 – ZTNA stops working after days with "No ZTNA client certificate was provided"
https://docs.fortinet.com/document/forticlient/7.4.2/windows-release-notes/743101

bug 967199 – "No ZTNA client certificate was provided" error occurs when trying to access HTTPS page
https://docs.fortinet.com/document/forticlient/7.2.5/windows-release-notes/743101/existing-known-issues

i wouldnt assume either bug is the same issue, especially since neither mentions the exact 2-hour cycle, but they may be useful references once the exact forticlient, ems and fortios versions are confirmed.

🚨 The Symptoms

🛠️ Troubleshooting & Root Cause Analysis Done So Far

❓ Our Hypothesis & Questions for the Community

Sign up

Login with SSO

Login to the community

Login with SSO