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

[saleha]

Description	This article describes the effect of the 'Default Certificate' option in the 'ZTNA Server' configuration on traffic. This article assumes familiarity with ZTNA configuration. The following link provides a reference from v7.4.7 for ZTNA deployment: Zero Trust Network Access introduction
Scope	FortiGate, ZTNA.
Solution	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>