FortiGate certificate authentication to SSL VPN

Note: The description in the article is based on FortiGate FG-300E with FortiOS version 6.2.3. Which is configured as an FGCP cluster and uses VDOM.

SSL VPN requiring client certificate

By default, users are authenticated by entering a username and password. They can be defined locally or remotely. A special case is local Peer (PKI) users, who are authenticated using a client digital certificate. They can authenticate using only a certificate or with two-factor authentication including a password. In the case of SSL VPN, we can require certificate verification for all users (regardless of where they are defined).

• (VDOM) > SSL > SSL-VPN Settings

When logging into SSL VPN, we can enable client certificate requirement in the GUI (Require Client Certificate). If we only enable this option, all certificates that are trusted by FortiGate are accepted. We can influence the exact behavior through global VPN certificate settings (see below). Using CLI, we can assign PKI users (Peer User) and define the details of the certificate that is accepted in this object.

We can enable client certificate verification in the global SSL VPN settings (SSL-VPN Settings). Then all connections (portals) will require a client certificate. Or we can set it using CLI in an authentication rule, where we map users to a portal. Then it will only apply to connections to that portal and that user.

If we set the certificate requirement in the global settings, the verification takes place right at the initial stage when the TLS connection is established. If the certificate doesn't pass, the user is not even authenticated. When set in an authentication rule, the user must first be identified to know if a certificate is required.

When accessing Web VPN, a certificate request pops up when accessing the page. The certificate is sent before the login dialog is displayed. If we have set it in a certain authentication rule, the request still pops up for everyone (who connects through the same URL). If a certificate is not required for our connection, we can cancel the dialog and continue. If we want to arrange for the request to be displayed only where a certificate is required, we can create different Realms. We define different URLs (Virtual Host) and assign each to a different group of rules.

With certificate verification enabled, various certificate properties are checked. For example, whether it's not a Self-signed certificate, whether it's from a trusted authority, CRL can be checked, etc. We can influence some things in the certificate settings (config vpn certificate setting). If we also have Peer User used, it checks if the certificate matches any of them.

If we don't have a certificate set up when logging in, an error is displayed.

Computer Certificate

Typically, Fortinet uses a user certificate (User Certificate - certmgr.msc), but it's also possible to use a computer certificate (Computer Certificate - certlm.msc) on Windows OS. If a user has access rights to the computer certificate store, the appropriate certificates are offered when selecting a certificate in FortiClient. Apparently, these are certificates with Enhanced Key Usage = Client Authentication. But when we use such a certificate, we can't connect to the VPN. When using debug, it can be determined (although FortiGate is very poor in displaying information) that the certificate is not sent to the server at all. Really funny behavior.

On the forum, I found questions from people about how to use authentication with a computer certificate. And answers that it's not possible. But in the end, almost by chance, I managed to find one Fortinet article Technical Tip: How to use machine certificates for SSLVPN connections in FortiClient. And according to it, using a computer certificate can indeed be easily enabled.

FortiClient enabling computer certificates

It's necessary to change the FortiClient application settings.

• create a backup of the settings
  • FortiClient - Settings - in the System section - Backup
  • for example to a file forticlient.conf, confirm OK, we'll get information that the backup was successful
• edit the configuration
  • open the configuration in a text editor and find the parts where our VPN connections are defined

            <connections>
                <connection>
                    <name>My VPN connection</name>

Note: we must edit all connections where we want to use a computer certificate

• • for example, after the part where certificates are defined, add a new line with the element allow_standard_user_use_system_cert

                    </certificate>
                    <allow_standard_user_use_system_cert>1</allow_standard_user_use_system_cert>
                    <warn_invalid_server_certificate>1</warn_invalid_server_certificate>

• • save the file
• restore the configuration to FortiClient
  • unlock the settings - bottom left (or top right) lock Unlock Settings
  • Settings - Restore - select the file and confirm

Peer User (PKI user)

We can use PKI users in several ways. We can use it to create a local user with a certificate definition (which specifies one certificate directly) and a password, which we include in a group and use it for VPN. SSL VPN with certificate authentication

Or we can use this object to define all certificates that are accepted for SSL VPN authentication. And then authenticate the user on a remote server (LDAP). Technical Tip: RADIUS authentication and client certificates in SSL VPN. Then we assign this user in the SSL VPN settings configuration with the command set user-peer {string}

If we authenticate users on an LDAP server, we can set up login with certificate only, without entering a username and password. The User Principal Name is taken from the certificate's Subject and used to search for the user. SSL VPN with LDAP-integrated certificate authentication

Creating a Peer (PKI) User

Documentation user peer, Technical Tip: PKI peer user creation for certificate authentication

We must create a PKI user using CLI and at minimum, we must specify the CA from which the certificate is issued.

config user peer
    edit "certuser"
        set ca "My_Root_Authority"
    next
end

• (VDOM) > User & Device > PKI

But once we create the first user in CLI, the option to edit and add more appears in the GUI. However, CLI offers more setting options.

Peer (PKI) User Parameters

We can set only a specific certification authority for a PKI user and then all certificates from it will be accepted. In practice, I had a problem (which I didn't investigate further). If we have a two-tier CA hierarchy, i.e., a root authority (Root CA) and a subordinate (Intermediate CA) that issues certificates. When I set the Intermediate CA (which is displayed on the client when selecting a certificate) in the PKI user, the verification didn't pass. When I changed it to Root CA, it started working.

For further specification, we can determine what should be in the certificate's Subject field. Or directly in the CN attribute (Common Name) of the Subject field. By default, it searches for a substring (substring), so if the specified string is found within the Subject or CN field, it's considered a match.

We can use, for example, a domain name and all user certificates where the email address has that domain will be accepted. Or computer certificates where the DNS name of the computer has this domain. For clarification, we can start with the at sign or dot. Alternatively, we can enter more detailed defined attributes in the Subject field.

Various filter examples:

        set subject ".company.local"
        set subject "@company.com"
        set subject "OU = company.com"
        set subject "CN = Smith John"
        set subject "smith@company.com"
        set subject "smith-win10.company.local"
        set subject "CN = smith-win10.company.local"
        set cn ".company.local"

For the CN attribute, we can also specify its type string, email, FQDN, ipv4, ipv6.

        set cn-type string

VPN Certificate Settings

Documentation vpn certificate setting

Various behaviors during certificate verification can be set globally in VPN certificate settings. Below are examples of setting interesting items including default values. CA check is set, or the entire chain. Whether a substring (substring) or exact value (value) of the attribute is searched for in Subject or CN. Option to enable Strict CRL/OCSP check.

config vpn certificate setting
    set check-ca-cert enable
    set check-ca-chain disable
    set subject-match substring
    set cn-match substring
    set strict-crl-check disable
    set strict-ocsp-check disable
end

Assigning Peer (PKI) User in VPN Settings

Assigning a created PKI user, and thus defining allowed certificates, along with enabling client certificate requirement, can be set for all connections in the global SSL VPN settings. Or in a specific authentication rule (Authentication/Portal Mapping), where we map users to a portal (possibly with a specific Realm) and affect this connection combination. In both cases, we must set it using CLI.

Configuration of Peer User in global SSL VPN settings

config vpn ssl settings
    set reqclientcert enable
    set user-peer {string}
end

In the global settings, we can also enable the requirement for a PKI user with two-factor authentication.

config vpn ssl settings
    set force-two-factor-auth enable
end

Configuration of Peer User in an authentication rule

config vpn ssl settings
    config authentication-rule
        edit 1
            set client-cert enable
            set user-peer {string}
        next
end

Events during debugging

If we enable debug SSL VPN in CLI, various events regarding certificate checks are logged (but there could be more). Below are examples of various events and selected logs.

diagnose debug application sslvpn -1
diagnose debug enable

A certificate is required, but the client does not use any.

[9315:FWINT:7a2]client cert requirement: yes
[9313:FWINT:7ad]No client certificate
[9313:FWINT:7ad]Require client certificate for bouska
[9313:FWINT:7ad]login_failed:384 user[bouska],auth_type=16 failed [sslvpn_login_cert_checked_error]

Using a self-signed certificate.

[9314:FWINT:74a]client cert requirement: yes 
[9314:FWINT:74a]SSL state:SSLv3/TLS write certificate request (78.248.255.155)
[9314:FWINT:74a]SSL certificate verification: self signed certificate
[9314:FWINT:74a]SSL error: self signed certificate
[9314:FWINT:74a]SSL state:SSLv3/TLS read client certificate (78.248.255.155) [9314:FWINT:74a]doing certificate checking.

Successful use of a correct certificate.

[9314:FWINT:74b]client cert requirement: yes
[9314:FWINT:74b]SSL state:SSLv3/TLS write certificate request (78.248.255.155)
[9314:FWINT:74b]SSL state:SSLv3/TLS read client certificate (78.248.255.155)
[9314:FWINT:74b]doing certificate checking.
[9314:FWINT:74b]__auth_cert_cb:903 certificate check OK.

Successful login with Peer User named certuser.

[9313:FWINT:778]client cert requirement: yes 
[9313:FWINT:778]fam_cert_send_req:808 do certificate peer check first(2).
[9313:FWINT:778]doing certificate checking for 1 peer(s).
[9313:FWINT:778]__auth_cert_cb:903 certificate check OK.
[9313:FWINT:778]__auth_cert_cb:915 certificate check OK, matched peer [certuser].
[9313:FWINT:778]sslvpn_update_user_group_list:1533 Remove user(s) and group(s) do not set matched peer [certuser].
[9313:FWINT:778]sslvpn_update_user_group_list:1537 got user (0:0), group (1:1) peer group (0) after update.
[9313:FWINT:778]sslvpn_authenticate_user:191 authenticate user: [bouska]
[9313:FWINT:778]Auth successful for group G VPN1
[9313:FWINT:778]Auth successful for group [G VPN1] with matched user-peer [certuser]
[9313:FWINT:778]fam_do_cb:654 fnbamd return auth success.

Unsuccessful login with Peer User.

[9315:FWINT:76e]doing certificate checking for 1 peer(s).
[9315:FWINT:76e]sslvpn_update_user_group_list:1563 Remove group(s) which has set user-peer (1).
[9315:FWINT:76e]sslvpn_update_user_group_list:1595 got user (0:0), group (0:0), peer group (0) after update.
[9315:FWINT:76e]__auth_cert_cb:939 no valid user/group candidate found.