VPN Client stuck at 40% with certificate error

[johna-eximiusdesign]

We had a PC with a working Forticlient setup that recently stopped working. It gets stuck at 40% with the error "The server you want to connect to request identification, please chose a certificate and try again (-5)." I've read all over the forum and I've already tried:

- Ensured Internet Options have TLS 1.0, 1.1 and 1.2 enabled.

- Uninstalled and reinstalled Forticlient using latest versions (7.01.0083)

- Tried to restore previously know good configuration

- Ensured there is no "hidden window" for certificate authorization*

The same credentials work on other PCs so the issue seems to be on one PC (have a second PC with similar symptoms but haven't triaged that one yet). From the "bad" PC, we've tried accessing multiple gateways, all get the same error. So there seems to be something awry with this PC. As far as I know we don't use any certificates, at least nothing didn't come preinstalled. It is possible when the problem first showed up that there was a popup window and we hit accidentally hit "no" on the certificate authorization, but I would have figured a clean uninstall / reinstall would have cleared that flag. It is almost like this PC corrupted itself in a way a fresh install didn't fix.

Any suggestions would be appreciated. We're at a loss here.

[kiri]

Hi johna-eximiusdesign,

Check if the enabling the following in FCT settings helps:
Do not Warn Invalid Server Certificate
https://docs.fortinet.com/document/forticlient/7.0.2/administration-guide/682005/vpn-options

This is no solution to the actual issue, untrusted cert, but it should allow you to connect.
Bear in mind that FOS 7.0.2 has now ACME certificate support. You can request a certificate signed by Let's Encrypt and use it for VPN access and avoid these errors.

https://docs.fortinet.com/document/fortigate/7.0.2/administration-guide/822087/acme-certificate-supp...

Let me know if this helps.

[johna-eximiusdesign]

Hi cchiriches,

Sincere thanks for responding. I've tried the Do Not Warn Invalid Server Certificate flag a few times and it had no appreciable effect. It looks like from version 6 to 7, the FortiClient VPN "Do Not Warn on Invalid Certificate" flag went from a per connection option to a global one, but I still see <warn_invalid_server_certificate> in the configuration xml on both the global <sslvpn> options and inside the individual <connection>. So, I've set both to 0 (i.e. do not warn) as well as tried the GUI options. It didn't seem to have any effect and still fails in the same way with the same error.

I've read that invalid TLS settings can sometimes be reported as invalid certificate, so I did play with those and made sure TLS 1.0, 1.1 and 1.2 were enabled. As proof, I disabled the one-by-one and when I disabled TLS 1.2 I saw a different error about TLS negotiation, so I feel confident I have those set correctly. Is there anything else that can show up as a "certificate" error that would not be masked by the "Do Not Warn on Invalid Certificate" flag?

Also, I wasn't able to gleem anything from this, but here is the error log event from FortiClient. Note I scrubbed the IP addresses / macIDs / names / uid / devid / hostname / serial number and replaced them with garbage, but I tried to leave everything else alone.

11/21/2021 3:20:15 PM error sslvpn date=2021-11-21 time=15:20:14 logver=1 id=96603
type=securityevent subtype=sslvpn eventtype=error level=error
uid=12345678 devid=abcdef
hostname=machine1 pcdomain=N/A deviceip=1.1.1.1
devicemac=11-22-33-44-55-66 site=N/A fctver=7.0.1.0083
fgtserial=FCT800199999999 emsserial=N/A
os="Microsoft Windows 8.1 , 64-bit (build 9600)" user=john
msg="SSLVPN tunnel connection failed" vpnstate= vpntunnel=SJC
vpnuser=johna remotegw=1.2.3.4

Does anything there mean anything to you?

Possibly related (or entirely useless), I did look through the Microsoft Event Logs and I did find that I get 3 of these errors every time I try to connect.

A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 51. The Windows SChannel error state is 808.

Decoding 0x51 results in a SEC_E_DECRYPT_FAILURE which means exactly that, the TLS was unable to decrypt something. I don't usually find Windows Event Logs particularly meaningful, but if you see something, let me know.

Again, thanks very much for the help. I really do appreciate it.

John

[kiri]

Hi John,

No worries

1. Is there anything else that can show up as a "certificate" error that would not be masked by the "Do Not Warn on Invalid Certificate" flag?
- I'm unaware of that.

2. Also, I wasn't able to gleem anything from this, but here is the error log event from FortiClient. Note I scrubbed the IP addresses / macIDs / names / uid / devid / hostname / serial number and replaced them with garbage, but I tried to leave everything else alone.
- Was log level set to Debug?

I'm afraid it's not that much in these logs, probably Info level, not debug.

I've checked internally for "The TLS protocol defined fatal error code is 51." and "The Windows SChannel error state is 808.", no relevant results.

Please answer the following:
Which FCT version, free or paid?
Did you try other versions? Which?
Which FOS?
Does the web ssl portal work from this pc?

If you run a debug for a working and a non-working example, I can take a look at it:

diag debug reset
diagnose debug cons time en
diag debug application fnbamd -1
diagnose debug app sslvpn -1
diagnose debug enable

To disable the debug type "di de di".

[johna-eximiusdesign]

Hi cchiriches,

The log was set to Debug, but so far, I have not seen any difference in the log output from Debug, Info, or any of the other options.

So far, I've observed the issue on:

FortiClient VPN Only 6.4 (free)

FortiClient VPN Only 7.0.1.0083 (free)

FortiClient ZTFA 7.0.1.0083 (trial)

The behavior for all 3 is identical. Get to 40%, sits for a longish while (~ 60 sec, which is much longer than typical fails) and then gives up with the "The server you want to connect to request identification" message. I'm still working on getting the credentials for our FortiGate server from IT (its a convoluted process, but they promised they would and I've got the CTOs backing), so I'm not 100% on what our license there covers.

I'm not sure I know what FOS is (too many TLAs to keep track of :). If you are asking about OS, the client is on Windows 8.1.

I did confirm my TLS / SSL works for multiple browsers on my PC (at least TLS 1.2) at the SSLLabs site: clienttest.ssllabs.com:8443/ssltest/viewMyClient.html (let me know if you have a different one I should use). I have tried to VPN to two sites within our company with the same results, but I have not found an open 3rd party VPN to try to access. But since the same credentials work on ~6 other machines, include 2 personal PCs, one with a fresh install of the FortiClient, I think it is safe to say the issue is on my local PC.

What's bizarre is I've been using this PC and FortiClient for ~5 years, no major issues. Sometime between Wednesday night when I logged off and Thursday (11/18) morning, this issue arose. Nothing new installed. Logs say Teams and Zoom did an update overnight, but nothing else interesting seems to have happened.

Last night, I did generate a report using the "Diagnostics Tool" while it observed me trying to connect. If you want, I can share that with you. Its smallish (1MB) but it has some sensitive info (IP address, credentials, etc), so I'd rather not post it openly. Can you suggest a way I can send this to you like email?

I'm also happy to run the diag commands you listed, but I don't see how to enable them. Are they on the FortiGate side? Or is there a hidden switch someplace?

Also, I'm not sure if it is helpful, but I broke out WireShark to look at the packets. I can see the Client saying Hello, Server saying Hello, Server sending a Certificate and the Server saying "Hello Done" and sending a SHA256 key to the client. The Client then FINishes the TCP connection. The client then seems to repeat the sequence, starting over from Hello for two more times (which is consistent with the 3x Microsoft Logs errors). Because it is the local side that initiates the TCP termination, I gather the FortiClient is not happy about something. Maybe it is rejecting the certificate / key offered by the Server? Any insight there?

Thanks,

John

[kiri]

Hey John,

Sorry, FOS - FortiOS.
Yes, it looks like the issue is with the PC, since the same credentials work fine from other PCs. And other users aren't experiencing this.
Don't you have the option to do a System Restore to the point where it worked? I think this would be more practical if possible.
Something got stuck in registry maybe, can't tell what I'm afraid.
It's unclear from your message if you tried accessing the same vpn service via web, from the same pc, no FortiClient/tunnel mode.
I'm unable to provide you with my email address.
If you have a FortiClient licence, and you'd like us to examine the Diagnostics, then a Service Request would be needed.
The debug commands I shared are available on the Fortigate's CLI, copy and paste them.
If you're using vdoms, you need to be into that vdom to run them.
The packet capture might be interesting, can't give you any feedback unless I see it.

[johna-eximiusdesign]

Hey cchiriches,

Unfortunately, I had some disk space issues and had to limit the system restore to two or three points, which are unfortunately long in the past after all the install/reinstall over the past week or so. I did do a manual reload of my registry from ~10 months back (and reinstalled forticlient vpn from that registry point) and it gets to 40% just like before.

I'm still working with my local IT to get access to the FortiGate to run the diagnostics you gave.

I tried to access the VPN server by entering the server IP address into various browsers (Edge, which is new install and never used before so no cache, etc, Firefox, Chrome). There is no webserver on the VPN server, so nothing is there and I get some variant of a timeout on both working and non-working system. I can ping from both systems without issue and get a response. This matches the wireshark frames showing the back/forth communication, so I don't think the firewall or anything is (obviously) stopping the traffic.

Comparing the wireshark traces is interesting. I can clearly see both the good and bad going through this sequence:

1. Client / Server init TCP

2. Client sends TLSv1.2 Client Hello

3. Server sends TLSv1.2 Server Hello

4. Server sends Certificate (same on both good/bad)

5. Server sends first half of Key Exchange and Server Hello done.

The difference is on the good, the client responds with a "Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message" followed by additional TCP / TLS packets. The bad simply acknowledges outstanding data and terminates the TCP. Looking closer at the two machine's Client Hello message, they are different (different number of supported cipher suites, SessionTicket TLS, etc), but it is not clear what is important in those differences and it could just be different OS specific features.

So, I don't see any evidence of anything like a firewall blocking the VPN client. I do see back/forth communication at a layer 3/4 level and the only differences appear at layer 5 (SSL TLS commands) and above. Any ideas what would prevent the PC from issuing any response to the certificate from the Server? Are there any SW packages that could have been updated (or were supposed to be updated) for windows that are affecting the VPN client?

Thanks,

John

[kiri]

Hi John,

Apologies for the late response.

"The bad simply acknowledges outstanding data and terminates the TCP."
- It is likely that your client is not supporting the parameters the firewall is sending over, ciphers and so on.
I came across this before, a bunch of devices had to be replaced because of outdated cipher.

"Any ideas what would prevent the PC from issuing any response to the certificate from the Server?"
- I can't tell.

"Are there any SW packages that could have been updated (or were supposed to be updated) for windows that are affecting the VPN client?"
- I'm not aware of that, didn't come across anything similar by now where some Windows update would break FCT and cert operation.
Maybe it's not the best option, but rebuilding the machine might be the quickest way to fix this.

Please let me know how it goes.

Claudiu

[johna-eximiusdesign]

Hi Claudiu,

Over the holiday break I took the time to do a "in place windows repair" which essentially reinstalls windows but leaves in place the contents and programs of the disk. As soon as I did that (and reinstalled forticlient), the VPN fired up and ran without issue. I waited a little while to post this to ensure some basic stability, but so far I've been good for a couple weeks. It is worth stating I have not yet updated my windows (it is probably at the out-of-the-box OEM state) and some things are not quite working yet (chrome, firefox work great... IE cannot connect), but I expect updating windows will fix that.

So, all of this is to say that it looked like something inside windows was broken / corrupt and reinstalling windows (and a fresh install of forticlient) and all is well. No idea what was corrupted or how it was corrupted, but I'm happy I'm functional again. :)

Thanks again for the help.

[johna-eximiusdesign]

Update: I did the windows update and the problem returned. I made no other changes to the computer. I then did a restore to a previous state, and the problem went away.

From this, I'm reasonably certain that something in the windows 8.1 updates is breaking forticlient. Since I started with a fresh install of windows 8.1, I would have assumed this problem would have been seen elsewhere, so I cannot explain why (AFAIK) my computer seems unique. If I have time, I may try to identify exactly which update breaks things. I'll update more when / if I get time.