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.