FortiClient certificate warning on Linux

[heisenbug]

Hi, I'm getting an SSL certificate warning when using FortiClient VPN on 1 of my Linux machines but not on 2 other Linux machines. Why does this only happen on 1 machine and not on the others?

I've tested this on 3 machines, and only 1 of them has this problem (openSUSE).

Context:

- There are no certificate warnings at all if we visit the SSL endpoint in the browser, or when we run 'sslscan' or 'testssl.sh' on the SSL endpoint: vpn.ourdomain.tld:10443

All good here.

- All 3 machines are running the same FortiClient version: 7.2.2 (build 7.2.2.0753)

- libssl versions on the 3 machines:

Debian: 3.0.11

Fedora: 3.0.8

openSUSE: 3.1.4

- All 3 machines are using the same DNS server, same DHCP, same internet connection.

- The cryptographic policies are set to DEFAULT.

- To make FortiClient usable at all on openSUSE, I temporarily(!) disabled AppArmor. That allows me to establish a successful VPN connection, although I see the certificate warning shown in the screenshot below.

I would like to know why this certificate warning is shown. In Wireshark, I can see that the openSUSE system initially lets the TLS handshake fail with "Unknown CA" as the reason. Then FortiClient shows the certificate warning and you can choose to continue. On other systems (like Debian and Fedora) the initial handshake succeeds and there is no certificate warning at all.

Screenshot:

[Markus_M]

Hi Heisenbug,

try from all three clients:

openssl s_client -connect www.fortinet.com:443

and see the certificate chain output.

Chances are that your server is not sending the complete chain (that is server+all intermediates), and the client fails completing the chain (with the fitting rootCA).

Best regards,

Markus

[heisenbug]

Hi Markus,

I forgot to mention, I tried that on all 3 machines, and the chain looks fine. No problem there. It looks just as normal as when you retrieve the certchain from www.google.com:

openssl s_client -connect www.google.com:443

Do you have any other ideas on what might be wrong? I found a couple of ancient KB articles:

https://community.fortinet.com/t5/FortiClient/Technical-Note-Certificate-warning-when-connecting-to-...

https://community.fortinet.com/t5/FortiClient/Technical-Tip-How-to-install-and-configure-SSL-VPN-cli...

However, I find it hard to believe any of them, because FortiClient works fine on 2 of the machines I tested without doing anything special.

The second article even recommends clicking Continue on a certificate warning without any explanation. Not exactly the best example.

Furthermore, I find it odd that the certificate warning mentions the DigiCert global root certificate. It exists on the openSUSE system in exactly the same place as on Fedora. Why would FortiClient complain about the root certificate and not about the others in the chain? Perhaps a clue lies in the fact that a global root certificate is, by definition, self-signed? But even so, why would FortiClient only show this certificate warning on the openSUSE machine and not on Debian and Fedora? The Fedora system is most similar to the openSUSE system, and the FortiClient even detects openSUSE as if it was Fedora.

[CatInHat]

I think there are some settings or configurations on the openSUSE machine that are different from other machines that affect the SSL certificate verification process. This may be due to browser settings, trust in root certificates, or even FortiClient itself on this machine. It is recommended to check all security settings and certificates on the openSUSE machine to understand what may be causing this certificate warning.

[Markus_M]

Agreed, the OpenSSL output header on the exact chain received may be important. Staying with the given example, google

 0 s:CN = www.google.com
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar  4 07:19:07 2024 GMT; NotAfter: May 27 07:19:06 2024 GMT
 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 13 00:00:42 2020 GMT; NotAfter: Sep 30 00:00:42 2027 GMT
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT

The certificate chain may be complete (and likely is) but the output won't show of if the missing certificate IS the root, or if it is just another intermediate.

In this case, certificate #2, "GTS Root R1" is not the root certificate, but points only to another issuer. The same could be true for your failing machine. There is an intermediate listed that your machine does not have. The link to the rootCA can then not be established. Chain verification fails.

Best regards,

Markus

[heisenbug · Accepted solution]

I'm happy to say that I identified the cause, found a workaround (for users) and a solution (for the Fortinet developers to implement).

(Workaround for users: see step 2 below.)

Hint: Fortinet can fix this problem easily by updating their source code, see below.

The reason why we are getting a certificate warning on openSUSE is the following:

The FortiClient VPN program is trying various places to find the system's CA bundle. So far, so good. However:

Below are the files it is trying to access on openSUSE:

./forti.pid.3283:2206:access("/etc/ssl/certs/ca-certificates.crt", R_OK) = -1 ENOENT (No such file or directory)
./forti.pid.3283:2207:access("/etc/pki/tls/certs/ca-bundle.crt", R_OK) = -1 ENOENT (No such file or directory)
./forti.pid.3283:2208:access("/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", R_OK) = -1 ENOENT (No such file or directory)

None of these exist. On openSUSE, the CA bundle can be found at:

/etc/ssl/ca-bundle.pem

Hence, the FortiClient fails to verify the root certificate of the SSL VPN endpoint, and that's why we get a certificate warning.

So, in summary, to make FortiClient work properly on openSUSE, Fortinet will have to do these things:

1. Develop an AppArmor profile, to make FortiClient work (better) on systems that use AppArmor, like openSUSE (and Ubuntu).

2. Fix the FortiClient code so it will _also_ try to access the following location to find the system's CA bundle:

/etc/ssl/ca-bundle.pem

Until then, a workaround that users can apply is this:

$ sudo ln -s /etc/ssl/ca-bundle.pem /etc/ssl/certs/ca-certificates.crt

If the link (last parameter) already exists, this will do nothing, which is good, since in that case no action should be necessary.

Other ways in which the Fortinet developers might solve the problem are:

- Install their own CA bundle along with FortiClient.

- Or use the system's built-in methods (if any are deemed suitable by the developers) of verifying certificates so FortiClient doesn't even have to know about the locations of the CA bundles.

Perhaps such options have already been considered and are either rejected or planned.

3. Test and review the code changes.

4. Done.

For the curious, the way I debugged this problem is the following:

I temporarily disabled the forticlient service, then rebooted, and executed the following command:

sudo strace -ff --output=forti.pid /opt/forticlient/fctsched

The /opt/forticlient/fctsched part was found in /usr/lib/systemd/system/forticlient.service, that's how we know which command to use to manually run the service via 'strace'.

Then I used the FortiClient VPN GUI program as normal so that the trace files contain useful information.

So, looking back at the original forum post: yes, even though the individual SSL certificate files were found on openSUSE in the same place as on other systems ( namely /etc/ssl/certs ), the location of the CA bundle was different.

[neovedder]

Hello friend!

I have been struggling with the forticlient in Opensuse Tumbleweed using SAML authentication. Despite the errors due to certificate chain, which was fixed using the "ln" hacking above, I'm still having problems to establish the tunnel. I can authenticate successfully and just after that the connection is closed. Using Windows everything works fine. Would you analyze the following log and help me to fix?

20241203 16:50:09.950 TZ=-0300 [sslvpn:INFO] main:1817 Init
20241203 16:50:09.951 TZ=-0300 [sslvpn:INFO] main:622 Load profile: BLN
20241203 16:50:09.952 TZ=-0300 [sslvpn:DEBG] main:631 Inherit local DNS: No
20241203 16:50:09.952 TZ=-0300 [sslvpn:DEBG] main:644 DNS service resetting interval: 0
20241203 16:50:09.952 TZ=-0300 [sslvpn:INFO] main:329 Get DBUS session bus address
20241203 16:50:09.954 TZ=-0300 [sslvpn:DEBG] main:333 Failed to find DBUS session bus address in dbus-daemon, try to find in dbus-broker
20241203 16:50:09.955 TZ=-0300 [sslvpn:DEBG] main:393 get passwd: true, get cert passwd: false, get user input: false
20241203 16:50:09.961 TZ=-0300 [sslvpn:INFO] main:329 Get DBUS session bus address
20241203 16:50:09.962 TZ=-0300 [sslvpn:DEBG] main:333 Failed to find DBUS session bus address in dbus-daemon, try to find in dbus-broker
20241203 16:50:09.963 TZ=-0300 [sslvpn:INFO] main:1288 Load profile: BLN
20241203 16:50:09.963 TZ=-0300 [sslvpn:DEBG] main:1676 FCT UID: F473F21C23864864B1FED27271AA89F6
20241203 16:50:09.964 TZ=-0300 [sslvpn:DEBG] main:1691 EMS not registed
20241203 16:50:09.964 TZ=-0300 [sslvpn:DEBG] main:1704 Public IP is not set
20241203 16:50:09.964 TZ=-0300 [sslvpn:INFO] main:1481 State: Connecting
20241203 16:50:09.979 TZ=-0300 [sslvpn:DEBG] vpn_connection:1506 Server URL: https://vpn.[omitted]:10443
20241203 16:50:09.986 TZ=-0300 [sslvpn:INFO] main:1481 State: Logging in
20241203 16:50:09.986 TZ=-0300 [sslvpn:INFO] sslvpn:92 ApiEncMethod: 0
20241203 16:50:09.986 TZ=-0300 [sslvpn:INFO] sslvpn:93 ApiRemoteAuthTimeout: 120
20241203 16:50:09.986 TZ=-0300 [sslvpn:INFO] sslvpn:94 ApiServerSalt: 127ac17e
20241203 16:50:09.986 TZ=-0300 [sslvpn:INFO] sslvpn:95 flag: 1247
20241203 16:50:09.986 TZ=-0300 [sslvpn:INFO] vpn_connection:1944 /remote/saml/login
20241203 16:50:13.254 TZ=-0300 [sslvpn:DEBG] vpn_connection:406 https server 'vpn.[omitted]' has this certificate, which looks good to me:
/CN=[omitted]
20241203 16:50:13.444 TZ=-0300 [sslvpn:DEBG] vpn_connection:599 http connection closed.
20241203 16:50:13.445 TZ=-0300 [sslvpn:DEBG] vpn_connection:478 Response line: 200 OK
20241203 16:50:13.445 TZ=-0300 [sslvpn:INFO] sslvpn:234 Authentication passed.
20241203 16:50:13.445 TZ=-0300 [sslvpn:INFO] vpn_connection:1944 /remote/fortisslvpn
20241203 16:50:16.676 TZ=-0300 [sslvpn:DEBG] vpn_connection:595 http request error: 1
20241203 16:50:16.676 TZ=-0300 [sslvpn:EROR] vpn_connection:552 socket error = Resource temporarily unavailable (11)
20241203 16:50:16.676 TZ=-0300 [sslvpn:EROR] vpn_connection:1815 Error: Can not connect to VPN server.
20241203 16:50:16.686 TZ=-0300 [sslvpn:DEBG] vpn_util:260 Get connection name: Wired connection 1
20241203 16:50:16.687 TZ=-0300 [sslvpn:DEBG] dns:210 Read DNS backup /etc/nm_resolv.forticlient.backup:
20241203 16:50:16.687 TZ=-0300 [sslvpn:DEBG] dns:213 JSON parse error, content dump:
20241203 16:50:16.694 TZ=-0300 [sslvpn:DEBG] vpn_util:260 List fctvpn connection: Wired connection 1
lo
enp2s0
20241203 16:50:16.694 TZ=-0300 [sslvpn:DEBG] dns:632 default interface restore: 1, vpn interface restore: 1
20241203 16:50:16.694 TZ=-0300 [sslvpn:DEBG] mtu:116 Restore MTU.
20241203 16:50:16.694 TZ=-0300 [sslvpn:DEBG] mtu:120 No MTU backup file was found. Skip.
20241203 16:50:16.694 TZ=-0300 [sslvpn:DEBG] route:160 clean up route...
20241203 16:50:16.694 TZ=-0300 [sslvpn:DEBG] route:164 Cleanup file not found
20241203 16:50:16.694 TZ=-0300 [sslvpn:DEBG] main:1911 exception: Error: Can not connect to VPN server.
20241203 16:50:16.775 TZ=-0300 [sslvpn:INFO] main:1817 Init
20241203 16:50:16.775 TZ=-0300 [sslvpn:INFO] main:1829 VPN is running in restore DNS mode
20241203 16:50:16.787 TZ=-0300 [sslvpn:DEBG] vpn_util:260 Get connection name: Wired connection 1
20241203 16:50:16.788 TZ=-0300 [sslvpn:DEBG] dns:210 Read DNS backup /etc/nm_resolv.forticlient.backup:
20241203 16:50:16.788 TZ=-0300 [sslvpn:DEBG] dns:213 JSON parse error, content dump:
20241203 16:50:16.799 TZ=-0300 [sslvpn:DEBG] vpn_util:260 List fctvpn connection: Wired connection 1
lo
enp2s0
20241203 16:50:16.800 TZ=-0300 [sslvpn:DEBG] dns:632 default interface restore: 1, vpn interface restore: 1
20241203 16:50:16.800 TZ=-0300 [sslvpn:DEBG] mtu:116 Restore MTU.
20241203 16:50:16.800 TZ=-0300 [sslvpn:DEBG] mtu:120 No MTU backup file was found. Skip.

[neovedder]

Adding some comments... The lines that look to show the problem may be the following:

20241203 16:50:16.676 TZ=-0300 [sslvpn:DEBG] vpn_connection:595 http request error: 1
20241203 16:50:16.676 TZ=-0300 [sslvpn:EROR] vpn_connection:552 socket error = Resource temporarily unavailable (11)
20241203 16:50:16.676 TZ=-0300 [sslvpn:EROR] vpn_connection:1815 Error: Can not connect to VPN server.

But the "resource unavailable (the vpn server) is ok. My provider replied to me that's a "client reset" log there.