Technical Tip: Certificate authentication for FortiClient remote access dialup IPsec clients with SAML user authentication

Limitation 1: FortiOS only supports certificate checking as an additional factor for FortiClient endpoints. While Fortinet uses a proprietary protocol for IKEv2 SAML authentication, if a third-party IPsec client could successfully authenticate to the SAML SP and connect to the IKEv2 gateway, the FortiClient certificate check would not be enforced- only SAML authentication would be enforced.

Limitation 2: FIPS-enabled FortiGates have additional requirements on top of what is discussed within this article. Review the FIPS-specific section at the bottom of this article for more information before continuing with the setup steps described in the rest of the article below.

Example topology:

Note: X.509 certificates are often referred to as 'SSL certificates', but they are not restricted to use in SSL. If a FortiGate local certificate was in use for SSL VPN before, it can, in many cases, be reused for IPsec VPN.

1. Configure the FortiGate as an SAML SP for IPsec.

See Fortinet documentation SAML-based authentication for FortiClient remote access dialup IPsec VPN clients, or Technical Tip: Recommended basic configuration for SSL VPN to IPsec VPN migration with SAML authentication for more on this step.

Verify SAML authentication is working as expected using a pre-shared key VPN before configuring signature authentication. The remainder of this article assumes a SAML SP for IPsec VPN users is already correctly configured and deployed.

2. Import the Private CA certificate to FortiGate.

Import the Certificate of the CA that signs VPN client certificates. From the GUI, Navigate to System -> Certificate -> Create/Import -> CA Certificate -> Upload File.

After import, the CA certificate will have a name like 'CA_Cert_1'. Optionally, rename the certificate.

config vpn certificate ca

rename CA_Cert_1 to 'Private CA'

end

• If the Private PKI infrastructure has a Root CA and one or more intermediate CAs, any CA in the chain can be used with default certificate settings. If 'check-ca-chain' is enabled in 'config vpn certificate setting', all CAs must be imported.
• Since the FortiGate will not be signing any certificates with the imported certificate, the certificate should not include the private key.

3. Configure a user peer referencing the imported CA.

This configuration will be used for authenticating the client device in IKEv2 phase1 authentication. The client devices must have certificates signed by the referenced CA.

config user peer

    edit "peer_admin-ou"

        set mandatory-ca-verify enable <-- default setting

        set ca "Private User CA"  <--imported CA

    next

end

Note: Without a configured Subject or Common Name (CN) in the peer definition, FortiGate may accept the certificate as valid but cannot map it to a specific user or VPN policy. This is because the CN or Subject field is used to associate the certificate with a PKI user or group. (Refer: Technical Tip: PKI peer user/usergroup creation for certificate authentication)

    config user peer
         edit "user01"
            set ca "Private User CA"
            set subject "CN=User01"
         next
    end

If multiple CAs are used to sign client certificates, multiple peers can be configured and included in a peergrp.

config user peergrp

    edit "IKE peers"

        set member "peer1" "peer2"

    next

end

4. Configure an IPsec tunnel using IKEv2.

Note the settings in bold.

config vpn ipsec phase1-interface

    edit "dialup_admin"

        set type dynamic

        set interface "port1"

        set ike-version 2

        set authmethod signature

        set peertype peer

        set net-device disable

        set mode-cfg enable

        set proposal aes256-sha256

        set dpd on-idle

        set dhgrp 20 14 5

        set eap enable

        set eap-identity send-request

        set eap-cert-auth enable

        set certificate "vpn.sitea.example.com"

        set peer "peer_admin-ou"

        set ipv4-start-ip 10.253.0.100

        set ipv4-end-ip 10.253.0.200

        set dns-mode auto

        set ipv4-split-include "Admin Split Tunnel Addresses"

        set dpd-retryinterval 60

    next

end

config vpn ipsec phase2-interface

    edit "dialup_admin"

        set phase1name "dialup_admin"
        set proposal aes256-sha256
        set dhgrp 20 14 5

    next

end

5. Configure one or more user groups referencing the SAML connector.

The SAML server used must be the same one configured on the interface hosting the dial-up IPsec tunnels.

config user group

    edit "VPN Admin General Access"

        set member "IKE_SAML" <-- SAML SP configuration in 'config user saml'.

    next

end

If users require different access depending on groups returned in the SAML assertion, additionally configure a group match.

config user group

    edit "VPN Admin General Access"

        set member "IKE_SAML"

            config match

                edit 1

                    set server-name "IKE_SAML"

                    set group-name "LAB_org_admin_unpriv"

                next

            end

    next

end

6. Configure a firewall policy referencing the IPsec tunnel and user group.

config firewall policy

    edit <index>

        set name "IPsec RA Admin General Access"

        set srcintf "dialup_admin"

        set dstintf "port2"

        set action accept

        set srcaddr "all"

        set dstaddr "Admin General Access"

        set schedule "always"

        set service "PING"

        set logtraffic all

        set groups "VPN Admin General Access"

    next

end

Note:

• The user group referencing the SAML SP configuration must be configured on the tunnel firewall policy or in the phase1-interface configuration. It must not be configured on both.
• 'set srcaddr' in the firewall policy must be configured to 'all' to trigger the SAML authentication and successfully connect to the VPN. As authentication takes place before IP assignment during IPsec VPN negotiation, while using EAP with IKEv2, utilizing the IPsec VPN address range can lead to a discrepancy in the firewall policy, causing it to be bypassed.

7. Provision and import the client certificate to endpoints.

For domain-joined endpoints, this may be done automatically via GPO. For an example of how to manually import a certificate using Windows, see Importing user certificate into Windows 10.

8. Configure the FortiClient VPN connection.

The FortiClient SSO port must match the configured auth-ike-saml-port, and the remote gateway should match the CN or SAN in the FortiGate's server certificate.

config system global

    set auth-ike-saml-port 20443

end

The IKE version must be 2. If visible, NAT Traversal must be enabled in most deployments.

• If the endpoint does not trust the FortiGate's SAML certificate or the remote gateway was configured using an IP address rather than an FQDN, the single-sign-on prompt will display a certificate error. See the article Troubleshooting Tip: How to resolve FortiClient untrusted Certificate Errors with SAML authentication for an example.
• If the FortiGate’s VPN or SAML server certificate is signed by a private CA, ensure this private CA is imported to the endpoint's certificate store, or the connection may fail with a FortiClient error stating 'Configuration error: Server Certificate Invalid'. For an example using GPO, see Technical Tip: How to distribute a Fortinet CA SSL certificate on a local domain on a Windows Server.
• For FortiClient macOS endpoints, ensure the root CA and any intermediate CA certificates signing the FortiGate's server certificate are installed in the endpoint's keychain. Both the root and any intermediate CA certificates are required. See Add certificates to a keychain using Keychain Access on Mac.
• For FortiClient Linux endpoints, ensure the root CA and any intermediate CA certificates signing the FortiGate's server certificate are installed in the CA certificate store. Both the root and any intermediate CA certificates are required. To add the certificates, refer to the appropriate third-party documentation for the Linux version in use.

9. (Optional) Configure cert_subjectcheck in FortiClient XML.

By default, FortiClient accepts any server certificate from FortiGate for authenticating the remote dial-up gateway, as long as it is signed by a trusted CA. It is recommended to enable Certificate subject checking to verify that the FQDN of the remote gateway matches the CN or SAN in the subject field.

This setting is supported by both EMS-managed and VPN-only FortiClients. See 'cert_subjectcheck' in IKE settings.

In future EMS versions, a toggle will be added to allow configuring this setting from the FortiClient EMS GUI for VPN connections using signature authentication.

10. (Optional) Configure multiple Dial-up tunnels and remote peers.

config user peer

    edit "peer_admin-ou"

        set ca "Private CA"

        set subject "OU=ADMIN"

    next

    edit "peer_sales-ou"

        set ca "Private CA"

        set subject "OU=SALES"

    next

end

After configuring each additional peer, configure a matching IPsec tunnel and required firewall policies.

The principal advantage of configuring multiple remote access IPsec gateways is the ability to assign different VPN configurations to different client groups, such as different address pools, split-tunnel routes, and DNS servers.

Alternatively, a single IPsec gateway can be used, and access control applied based on matching groups in the firewall policy.

If using PSK authentication for IKEv2, network-id is required to support multiple dial-up gateways on the same IP address, see Technical Tip: FortiGate Hub with multiple IPSec Dial-up phase1 using IKEv2 and PSK authentication.

Expected behavior:

1. Using the configured SSO port, the FortiClient establishes a connection to the FortiGate acting as SAML SP.
2. The FortiClient is redirected to the SAML IDP, where the user can enter their credential.

    

   

    

3. Using the SSO port, FortiClient presents the SAML response to FortiGate for validation.
4. FortiClient establishes an IKEv2 connection to FortiGate and performs certificate authentication.
5. FortiClient and FortiOS use an IKEv2 AUTH exchange to match the IKE connection attempt to the previously received SAML response.
6. If this is successful, authentication is complete, and the connection proceeds to mode-cfg exchange and phase2 SA negotiation.

Note:

The reason this configuration is recommended on FortiOS v7.4.8+ and v7.6.3+ is that, before those versions, connection to the VPN would be allowed even if client certificate validation failed.

Important notes regarding FIPS-enabled FortiGates:

First, for recent FIPS certification changes, refer to Technical Tip: Key considerations when upgrading FIPS FortiGates from FIPS 140-2 (v7.0 and earlier) to FIPS 140-3 (v7.2, v7.4, and later).

One of the new restrictions that comes with FIPS 140-3 is that SHA1 is deprecated as an acceptable cryptographic signing algorithm. At the same time, signature-based Authentication in IKEv2 (as per RFC 7296 Section 3.8) mandates the usage of SHA1 for the digital signature, which directly conflicts with FIPS 140-3's directives.

To address this, RFC 7427 extended IKEv2 to allow for broader hashing algorithm support used for signature-based authentication, and FortiOS has implemented this support as early as FortiOS v6.0.2 and v6.2.0 using the set digital-signature-auth option (see Change #489990 in the Release Notes). When FIPS mode is enabled on FortiGates running FortiOS v7.2, v7.4, or later, it is mandatory to enable this option in addition to the settings described earlier in this KB article:

config vpn ipsec phase1-interface

    edit <name>

        set digital-signature-auth enable <--- Mandatory

        set signature-hash-alg [ sha1 sha2-256 sha-384 sha2-512 ] <--- Optional, specify allowed algorithms

    next

end

Additionally, it is mandatory to use the following FortiClient versions to connect to FIPS-enabled FortiGates using certificate-based authentication; otherwise, the connection will not succeed due to a lack of support for RFC 7427:

• Windows FortiClient v7.4.5 or later (Change #1197323).
• macOS FortiClient v7.4.5 or later (Change #1197300).
• Linux FortiClient v7.4.3 or later (Change #1097956).

Note: at the time of this writing (March 2026), the free FortiClient VPN version is capped at version 7.4.3 and is not expected to receive further updates. This means that Windows/macOS users with the free FortiClient VPN will not be able to connect to FIPS-enabled FortiGates with IKEv2 + certificate/signature-based authentication.

If digital-signature-auth is not enabled for FIPS-enabled FortiGates, then the IPsec tunnel will fail to establish (this setting is not required for non-FIPS FortiGates). Notably, the iked debugs will show an error message stating 'error calculating auth information':

FortiGate # diagnose deb app ike -1 Debug messages will be on for 30 minutes.  FortiGate # diagnose debug enable [...] ike V=root:0:dialup:49: received peer identifier DER_ASN1_DN 'C = CA, ST = BC, L = Burnaby, O = Fortinet, OU = TAC, CN = testuser@jang.lab' ike V=root:0:dialup:49: re-validate gw ID ike V=root:0:dialup:49: gw validation OK ike V=root:0:dialup:49: Validating X.509 certificate ike V=root:0:dialup:49: peer cert, subject='testuser@tac.lab', issuer='TAC XCA RSA Root' ike V=root:0:dialup:49: peer ID verified ike V=root:0:dialup:49: building fnbam peer candidate list ike V=root:0:dialup:49: FNBAM_GROUP_NAME candidate 'IKE_PeerGrp' ike V=root:0:dialup:49: certificate validation before eap pending ike V=root:0:dialup:49: fnbam reply 'IKE_PeerGrp' ike V=root:0:dialup:49: fnbam matched peergrp 'IKE_PeerGrp' ike V=root:0:dialup:49: certificate validation before eap succeeded ike V=root:0:dialup:49: responder preparing EAP identity request ike V=root:0:dialup:49: error calculating auth information [...]

If the FortiClient version is not up-to-date as specified above, then iked will show the following debug snippet on the FortiGate when the connection fails. Note the line 'no matching SIGNATURE_HASH_ALGORITHMS':

FortiGate # diagnose deb app ike -1 Debug messages will be on for 30 minutes.  FortiGate # diagnose debug enable [...] ike V=root:0:dialup:33: responder preparing SA_INIT msg ike V=root:0:dialup:33: generate DH public value request queued ike V=root:0:dialup:33: responder preparing SA_INIT msg ike V=root:0:dialup:33: compute DH shared secret request queued ike V=root:0:dialup:33: responder preparing SA_INIT msg ike V=root:0:dialup:33: create NAT-D hash local 10.15.64.101/500 remote 10.15.64.1/1012 ike V=root:0:dialup:33: sending CERTREQ payload (len=21) ike V=root:0:dialup:33: certreq[0]: '75292B37A02544834597E437860A533A0C425E34' ike V=root:0:dialup:33: no matching SIGNATURE_HASH_ALGORITHMS ike V=root:0:dialup:33: schedule delete of IKE SA fff7ad7ec44f749e/5e4c51e677a2ae01 ike V=root:0:dialup:33: scheduled delete of IKE SA fff7ad7ec44f749e/5e4c51e677a2ae01

Related articles:

Technical Tip: FortiGate SAML authentication resource list 

Troubleshooting Tip: SAML Authentication fails after firmware upgrade to v7.2.12, v7.4.9 or v7.6.4