FortiClient hangs at 40% – If you encounter an issue with the certificates or the TLS negotiation, it may be due to the default FortiGate certificate not being trusted by the client. This can result in a popup window appearing to confirm the certificate’s validity.
Ensure that this popup window is not hidden behind other windows.
If the client is utilizing CRL or OCSP, verify that the FortiGate certificate can be validated against these protocols.
DO this manual with certutil.exe –url
or
by employing our freeware tool, crlcheck.exe, to detect all CRL-related errors on your system and across all applications simultaneously. You may be experiencing related issues throughout your infrastructure without realizing it, such as application delays, Veeam Backup issues, PowerShell delays, etc.
English:
German:
Furthermore, discrepancies in TLS versions between the client and FortiGate could be another potential cause. You can refer to this KB article for guidance on checking the TLS versions for SSLVPN on the FortiGate, and this one for instructions on inspecting the TLS versions on a Windows client.
Open up TLS settings from within Internet Explorer (IE) and then experiment with those settings (sounds great).
There is also a newly discovered bug with SSL VPN using SAML (Security Assertion Markup Language), which may fail to establish the VPN connection when the CA certificate is saved to Personal Certificates (see the end of our post) if the CRL retrieval is functioning correctly.
Here is the error you see in the FortiClient / EMS client:
Hangs at 40%, at 40 percent / Status: 40%
If you move the FortiClient window DOWN (To back) you would see the “Security Alert”
which showed behind the VPN client.
With our tool you would have seen the BLOCKED URLS’s at once.
Manual check of CRL Certificate Revocation List of an EXE file (Forticlient.exe) and if your client can reach the web address.
From another PATH not the Forticlient Directory check the CRL
certutil.exe -url http://crl3.digicert.com/sha2-assured-cs-g1.crl
URL Retrieval Tools does open
Or to do this FULLY automated AND for every EXE that is on your clients (Around 500-1200 EXE) use
our freeware tool crlcheck.exe
The problem is a BUG 1008116
SSL VPN with SAML may fail to bring up the VPN when the CA certificate is saved to Personal Certificates. See SSL VPN with SAML issue.
https://docs.fortinet.com/document/forticlient/7.2.4/windows-release-notes/991883/known-issues
Will be resolved in version 7.2.5, 7.4.0 | SAML (Security Assertion Markup Language) |
Even though I had not selected the option to authenticate with certificates, it appears that the FortiClient software was enforcing the certificate popup when it found certs in the Windows cert store. The only certs I needed to delete were in my “Personal” certificate store, and they were also visible in the certificate dropdown of the FortiClient VPN setup interface. What solved the issue for me was deleting my personal certificates from the Windows certificate store. When I deleted the certs, they were no longer visible in the setup dropdown, and the authentication completed successfully. |
SAML integration in FortiClient enables users to authenticate to a VPN gateway using credentials from trusted identity providers. Instead of local authentication, FortiClient initiates a SAML authentication request to the configured identity provider when users attempt to connect to the VPN. The identity provider prompts users to authenticate, generating a SAML assertion upon successful authentication. This assertion, containing user identity information, is sent back to FortiClient. After validation, if the assertion is deemed valid, FortiClient grants access to the VPN gateway. This process streamlines authentication, centralizes management, and supports single sign-on, leveraging existing identity infrastructure for VPN access control. |