A screenshot showing the 'Require Client Certificate' option enabled in the FortiGate GUI

This is a slightly left-field post on the back of some testing / tinkering I’ve been involved in over the last week or so. It’s not quite the post I had planned, but since I’ve not quite achieved what I set out to (yet, more on that in a future post) and this was a useful by-product along the way, it seemed silly to waste the opportunity of writing up some findings that will hopefully prove useful to someone down the line…

Fortinet’s FortiClient based SSL-VPN implementation is one of the best and simplest out there and has been a fairly staple feature on pretty much every FortiGate I’ve deployed since 2009 or so. One thing I haven’t ever explored though is the use of certificates as part of the authentication process - deferring instead to the more traditional approach of using RADIUS for Active Directory integration, or third-party MFA support where there’s more than a passing requirement.

Client VPN’s seems to have had a bit of a resurgence for a number of the organisations I work with in recent months, but given our Azure focus and the limitations associated with native Microsoft options in the cloud (lack of RRAS support, administrative complexity of P2S VPN’s etc.) we’ve found ourselves exploring and building solutions based on more traditional appliance based VPN solutions in Azure - Fortinet, Cisco, Palo Alto etc. A question I’ve been exploring is “how can we make these better / slicker / more secure?”.

The ideal world for me is the integration of Microsoft Always On VPN with a supported third-party appliance in Azure given the (theoretical) ability to do just that. One of the key advantages of Always On is it’s support for non-Microsoft IKEv2 / SSTP / L2TP compatible VPN appliances - which can (again, in theory) mitigate some of the challenges associated with the aforementioned Azure limitations. The reality, as I’ve experienced this week during testing, is that this isn’t as straightforward as you would hope when it comes to Azure. Is it possible? I absolutely hope so. How do you do it? Well… that’s the “future post” I’ve alluded to above - all being well 🙂

Back to certs and SSL-VPN in FortiClient… the inclusion of certificates in the user authentication process brings with it some advantages:

MFA: It introduces a level of multi-factor authentication that’s transparent to the user. This happens via background presentation of a user certificate containing a subject name that’s aligned to the authenticating user.

Device Level Security: Through the requirement for a user certificate to be present on the device, access is limited to trusted devices that fall within the governance and scope of corporate / enterprise IT.

Revocation: Linked with the above, certificates can be revoked / reissued at any time, ensuring the integrity of all connections to the corporate network.

Configuring Certificate Authentication for FortiClient

The process for enabling Certificate Authentication for FortiClient is actually relatively straightforward and involves just a few minor tweaks to the firewall configuration and regular SSL-VPN profile. Of course this assumes that you have a working PKI infrastructure in place, with the ability to issue user certificates to the devices of users who need to connect.

Step 1: Download the root certificate of the CA that will be responsible for issuing client certificates (along with any intermediary / issuing CA’s from your Certificate Authority) and upload as an External CA Certificate within the System > Certificates section of your FortiGate.

Step 2: Toggle the “Require Client Certificate” to “on” within VPN > SSL-VPN Settings. Note that if you have working clients they will be unable to access until they are defined as PKI users once this is enabled.

Step 3: Add users within User & Device > PKI, populating the “subject” field with the subject name from the certificate they will be using for authentication, and setting the “CA” field to reflect the External CA Certificate uploaded within Step 1. If the “PKI” section is not visible, create your first user via the CLI using the following commands as a template. Once the first user has been defined, the relevant views within FortiOS will be available:

config user peer
  edit kelvin-ca
    set ca CA*Cert*1
    set subject kelvin

Once the user has been added, toggle the “Two-factor authentication” setting to on and specify the password you want to assign to the user for SSL-VPN access.

Step 4: Within FortiClient, modify your VPN connection to include presentation of the relevant Client Certificate in place of “none”… and you’re done!

Certificate Authentication may not be for everyone, and it’s fair to say that there are other mechanisms for limiting device access and enhancing the security of VPN connections, but I was pleasantly surprised at just how straightforward the configuration of certificate auth was for FortiGate SSL-VPN.

Again, it’s not the blog I’d intended to post… but I hope this proves useful for some 🙂 Keep your eyes peeled for something soon that will hopefully blow this out of the water as far as simplicity, security, and ease of remote access is concerned… watch this space!