Technical Tip: ZTNA traffic and default certificate settings in ZTNA server

When configuring a new ZTNA Server on the FortiGate (for both TCP-Forwarding and HTTPS access proxies), one of the mandatory options is to set a Default Certificate. This certificate is presented to the user when connecting to the FortiGate as a ZTNA proxy gateway:

While it is possible to use the Fortinet_Factory certificate for this purpose, it is recommended to use a proper, trusted certificate or issues can occur.

Problem:

If the certificate assigned to this ZTNA server does not include the IP/FQDN used to access the ZTNA gateway as a Common Name (CN) and/or Subject Alternative Name (SAN) then users may run into warnings when attempting to connect to the service. For example, web browsers will show certificate errors when accessing a ZTNA HTTPS Access Proxy on the FortiGate, whereas FortiClient may show certificate errors when acting as a TCP Forward Access Proxy (depending on the version and the underlying configuration.

Solution:

The first recommendation is to obtain a certificate that is issued by a trusted Certificate Authority (e.g., GoDaddy, DigiCert, Let's Encrypt, etc.) and also has CN/SAN entries corresponding to the IPs/FQDNs used for the ZTNA gateway. This ensures that users accessing the FortiGate as a ZTNA Gateway will not encounter any TLS certificate errors/warnings, and there are a few different ways to accomplish this:

• Generate a Certificate Signing Request (CSR) on the FortiGate, then download the CSR and have a Certificate Authority sign and generate a certificate that can be uploaded to the FortiGate (the private key will be generated alongside the CSR and will remain on the FortiGate).
• Utilize Let's Encrypt and the ACME protocol to provision and renew certificates automatically (see also: FortiGate Admin Guide - Automatically provision a certificate).
• Generate a certificate and private key outside of the FortiGate, then import them as a PKCS #12 certificate bundle (see also: Technical Tip: How to import PKCS#12 certificate )

Note regarding FortiClient and EMS:

When FortiClient connects to a FortiGate ZTNA Gateway that uses an invalid certificate, there are a few options for controlling its behavior:

• Within EMS, one can set Enforce Valid Server Certificate in the Endpoint Profiles -> ZTNA Destinations section to determine if end users will be fully blocked from accessing a ZTNA destination when an invalid certificate is received. See also: EMS Admin Guide - ZTNA Destinations
  • A similar option exists in the FortiClient XML configuration named disallow_invalid_server_certificate (see also: FortiClient XML Reference Guide - ZTNA).
• Another option also exists in the FortiClient XML configuration named warn_invalid_server_certificate. This option (also discussed in the FortiClient XML Reference Guide) determines if FortiClient displays a security warning to the end-user when the certificate is invalid.

<forticlient_configuration>

<ztna>

<...>

<disallow_invalid_server_certificate>1</disallow_invalid_server_certificate>

<warn_invalid_server_certificate>1</warn_invalid_server_certificate>

<...>

</ztna>

</forticlient_configuration>