Technical Tip: Understanding TLS vs mTLS on FortiGate

hamidr · ‎12-11-2025

Description

This article provides a clear explanation of how TLS and mTLS operate, outlining the distinction between standard encrypted transport and certificate-based client authentication. It also clarifies which FortiGate features rely on TLS and which ones support mutual TLS (mTLS).

Scope

FortiGate.

Solution

TLS (One-Way Authentication).

TLS provides encrypted transport and server authentication only. During the handshake, the server presents its certificate, and the client validates it. However, the client is not required to present a certificate. As a result, the connection is accepted anonymously at the transport layer, and the client is authenticated later using application-layer credentials (for example, usernames, passwords, API tokens, or SAML assertions).
Because any device can initiate a TLS session, the exposed interface remains reachable for unsolicited connections. This increases the attack surface for credential probing, brute-force attempts, and enumeration before user authentication occurs.

Where TLS is commonly used:

TLS is used by FortiGate in scenarios where encrypted transport is required but device identity is not enforced:

Secure GUI and API access
(HTTPS administrative access and REST API endpoints)
Initial SSL VPN connection before user authentication
(TLS tunnel setup occurs prior to credential validation)
ZTNA browser-only mode (no FortiClient device certificate)
HTTPS inspection in Explicit Proxy and Deep SSL Inspection
(FortiGate acts as a TLS man-in-the-middle but does not authenticate the source device)

In all these cases, TLS provides confidentiality and server authentication, while client verification relies on application-layer identities rather than certificate-based device authentication.

Key limitations:

No device identity validation
Any endpoint can initiate a TLS handshake.
Interface remains exposed to unauthenticated traffic
Attackers can probe, scan, or attempt connections without presenting trust material.
Higher risk of credential-based attacks
Password guessing, brute force, and enumeration are possible until the application layer enforces authentication.

mTLS (Two-Way Authentication):

mTLS (Mutual TLS) extends standard TLS by enforcing bidirectional certificate authentication. During the TLS handshake, the server requests a client certificate and validates it before the session is established. The client must present a certificate issued by a trusted Certificate Authority (CA); otherwise, the session is terminated at the cryptographic layer.

This mechanism ensures the client’s device identity is validated before any application data, login banner, or VPN portal is exposed.

Advantages of mTLS:

Device identity is verified before authentication begins
Only endpoints with a valid certificate can complete the handshake.
Blocks unauthorized clients early
Connection attempts from unidentified devices fail during the handshake.
Strengthens Zero Trust posture
Enforces a 'trusted device first' requirement before user authentication.
Reduces reliance on shared secrets or static tokens
Security is anchored in asymmetric cryptography, not user-managed credentials.

Where FortiGate supports mTLS:

SSL VPN (Client Certificate Enforcement)

FortiGate can enforce client certificate validation for SSL VPN.
ZTNA with FortiClient

ZTNA with FortiClient always uses mTLS.
A device certificate is mandatory, and FortiGate validates the device prior to user authentication.

mTLS use in proxy architectures:

How mTLS behaves in proxy mode depends on the proxy type and whether the TLS session is terminated on the FortiGate. In practice, Reverse Proxy designs commonly terminate mTLS.

Reverse proxy mTLS patterns:

When FortiGate operates as a Reverse Proxy (Access Proxy VIP), it terminates the inbound TLS session and can enforce client certificate authentication.

mTLS Termination (Client --> Proxy)

This is the most common and operationally efficient approach.

Process summary:

The client initiates an HTTPS connection to the Access Proxy VIP.
The FortiGate presents its server certificate.
The FortiGate requests a client certificate.
The FortiGate validates the certificate using the configured CA(s) and authentication scheme.
If authentication succeeds, the FortiGate decrypts the traffic and forwards the request to the internal server based on the Access Proxy policy.

FortiGate can pass client certificate information to backend services by adding the X-Forwarded-Client-Cert (XFCC) header.

This requires:

An Access Proxy VIP with client-certificate authentication enabled
A web-proxy profile configured with header-x-forwarded-client-cert add
A proxy policy that applies this profile

The backend server receives the encoded certificate but does not participate in mTLS directly.

There is more information available in the link below:
mTLS client certificate authentication

mTLS passthrough (Forward Proxy):

In Forward Proxy mode, the FortiGate generally does not terminate mTLS traffic.
Instead, it allows the client and the destination server to perform the mutual TLS handshake end-to-end.

This behavior is expected because terminating mTLS in a Forward Proxy would require the proxy to impersonate the destination server, which is not feasible for mutual certificate authentication.

Process summary:

The client initiates an mTLS session to an external server.
The Forward Proxy (FortiGate) relays the TLS handshake packets without decrypting them.
The client and the external server exchange and validate certificates directly.
Encrypted mTLS application data flows through the proxy unchanged.

Limited inspection capability:

Deep SSL Inspection cannot be applied because:
mTLS does not allow third-party interception
the client and server must authenticate each other directly

Related documents:

Technical Tip: Understanding TLS vs mTLS on FortiGate

You are leaving our website