Enabling SSL VPN (tunnel mode) with Client Certificate and/or 2FA/MFA (SSL VPN hardening)

[Fortilover]

Dear Fortinet Community.

I would like to go on hardening our SSL VPN access by using Client Certificates and I have several questions for my understanding that I cannot explain myself as I have no test environment and so I thought... Why not ask the professionals here in the forum that helped me in the past perfectly. :)

Our environment:

• Fortigate (newest update installed)
• SSL VPN in tunnel mode
• FortiClient VPN will be used for SSL VPN connections
• Users will authenticate via Active Directory (LDAP Server)

What do I want to do? I want to enable Client Certificates. See here in the picture from Fortigate Demo Access:

So what are the prerequisites for such a Client Certificate? These are my questions for understanding.

1. Is the client certificate only connected to the server certificate used for SSL VPN?
2. Can the client certificate be a certificate from another/internal root CA that we use internally from a Windows environment? And if so, does the server certificate must be issued by the same internal CA or is this "connection" not really necessary and the server certificate could be issued by a public CA?
3. If we can use a server certificate issued from an public CA and a client certificate from an internal CA I think the root Certificate of our internal CA must be installed to the fortigate.
4. Which prerequisites must be met for client certificates?
   1. Can/must it be a User Certificate that matches the name of the user that logs on?
   2. Can/must it be a Computer Certificate that matches the name of the PC/Laptop the user uses to log on?
   3. Or is this completely independent?
   4. Can we force the Fortigate SSL VPN to use a client certificate (User Certificate) that matches the name of the users that want to log on?
   5. Can we force the Fortigate SSL VPN to use a client certificate (Computer Certificate) that matches the name of the PC/Laptop that want to log on?
   6. Does the client certificate has the prerequisite to use huge key sizes? 4096 and bigger? And if so can we define this in anyway so that certificates with a lower key size will not be accepted?

These are my questions for the setup of the "Require Client Certificate" feature. Any kind of support and answers would be very much appreciated :)

With kindest Regards

FortiLover

[funkylicious]

Activating, Require Client Cert, will enable it globally for all SSLVPN connections, so you cannot have some clients authing w/ user+pass and others with certs.

The certificate must be signed by a CA ( can be internal ) that you later define in the config and imported on the FGT

 https://docs.fortinet.com/document/fortigate/6.2.14/cookbook/266506/ssl-vpn-with-certificate-authent... 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Combining-remote-user-authentication-and-c...

Hopefully these guides will answer the rest of your questions and as far as I know, you cannot force to match something, because in the config of Forticlient you just specify which cert to use, there is no input/selection of user, all the verifications are done within the cert if it matches what you defined.

You could try something like 2FA, combination of user and password + cert, if you want another layer of security.

[Fortilover]

Thank you @funkylicious for your hints and your answer.

For my understanding. Would the activation of "Require Client Certificate" make something like a 2FA? So does this still reqiure to type in Username & Password and additionally to this to choose a valid User Certificate or does it work the way that a password is not required and will be replaced by the user certificate? If I check the frontend from the FortiClient VPN Software it seems so that all 3 options are mandatory. Username, Password & Client Certificate.

Refering to this article from Fortinet it looks like this, that the server certificate for SSL VPN and the user certificate must be ussied by the same CA. Link

For me it would be great to differ between the server certificate and user certificate trust chain... But I could live with it...

But I am not quiet sure yet. Because of this statements in the article:

1. In this example, the server and client certificates are signed by the same Certificate Authority (CA).

2. Configuring the SSL VPN settings to require a client certificate

   Using this method, the user is authenticated based on their regular username and password, but SSL VPN will still require an additional certificate check. The client certificate only needs to be signed by a known CA in order to pass authentication.

   This method can be configured by enabling Require Client Certificate (reqclientcert) in the SSL-VPN settings.

So at the moment I would say. It is something like a 2FA. We need Username & Password and additional to this a user certificate. Probably it is possible that the user certificate could have been issued from an internal CA and the server certicate has been issued from another (public) CA. If so that would be more secure for my understanding yet.

[Fortilover]

I think I get it right now... But I have at the moment no chance to test it. Next week I have the chance to test it. I have seen several Youtube videos that explained it a bit more. Furthermore I have learned something from these articles:

• https://docs.fortinet.com/document/fortigate/7.2.4/cli-reference/522620/config-user-ldap 
• https://community.fortinet.com/t5/FortiGate/Technical-Tip-Using-certificate-as-additional-authentica... 

As far as I understand it now I can create users on the Fortigate and refer to a LDAP User. Then, after creating the user in the fortigate, I can edit the user via cli. That could look like this:

config user ldap

edit <name>

set ca-cert {string}
set client-cert {string}
set client-cert-auth [enable|disable]

set two-factor-authentication email

next

end

I understand it the way that I can tell the Fortigate that this LDAP User has to use a client certificate that has been issued by a defined CA. Therfore these both lines are necessary:

set ca-cert {string}       <- defines the CA Root cert (Name in the Fortigate. example: "CA_Cert_1")

set client-cert {string}  <- defines the client certificate name. I believe it is the "issued to" string that could be the name of the user account or PC/Laptop name or something different specified, depending on the certificate template created in the Windows CA.

What I additional to this try to understand are the possibilities for 2FA/MFA. I have seen the FortiToken Solutions. They cost but are pretty nice. But I have seen additional possibilities in this Youtube video: https://www.youtube.com/watch?v=UxWo4hV_qHg 

Here it is shown how to activate the 2FA e-mail method for a user account. Probably this could work as well additional to the certificate. Because then I can define a specific Certificate Name for a specific User Account AND additional to this I can create a Token sent by e-Mail. So we have more than one authentication method. Then we need to know these "properties" to log in:

1. Username (depending on the LDAP "Common Name identifier")
2. Password (User password from AD)
3. Client certificate name (that needs to match the string defined in cli: set client-cert {string} )
4. Token (sent by E.Mail defined by cli: set two-factor-authentication email)

If this really works I would say it is more secure then.

[Fortilover]

Dear Fortinet Community.

Today I have got the chance to test a bit more. What I have seen in the Fortigate CLI Reference is the fact that the command "config user ldap" does not give me the chance to edit a Userobject that I have created via the Fortigate and is refering to a user object I can receive via a defined LDAP Server connection. No, instead it configures the whole LDAP Server object and not only a single user object. Is there any chance you know of that can edit a user defined via Fortigate that is refering via a LDAP Server defined in a fortigate?

Here you can see the hint in the CLI reference:

Like I said. I do not want to configure the whole LDAP Server object. I just want to configure one single user object that has been created via this LDAP Server connection on the Fortigate.

I mean exactly a Remote LDAP user Object like you see here in the picture.

I know that I could create a such called LDAP Server per User. So the LDAP Server Object is pointing to one special user object and then the "config user ldap" command would make sense. But I think this is not really OK because it should be a server object.

So in order to be precise: Is it possible to configure a Remote LDAP User object via CLI? Does anyone know this?

Any support and help would be very much appreciated :)

With kindest Regards

FortiLover

[FortiNet_Newb]

Fortilover,

I think you are getting confused by the naming of the cli commands.  I'm going to assume you are using LDAP (hopefully LDAPS) to query your Active Directory database.

#config user ldap is used to specify the Active Directory user account and connection settings the FortiGate can use to query your Active Directory database.  I would highly recommend enabling and utilizing LDAPS for this connection whenever possible.  Most have created a dedicated user account in AD specifically for this. I have also chosen to delegate the ability to reset passwords in AD to this account so VPN users can change/update their passwords remotely after they have expired or been forced to reset.

If you are using the GUI, these settings can all be found and configured under User & Authentication > LDAP Servers instead (much easier).

Once the above is configured successfully you can then add New Remote LDAP Users.  Using the GUI you can go to User & Authentication > User Definition > Create New and then choose "Remote LDAP User", you then specify the LDAP Server that you just created in the preceding step above.  You should then be able to browse your AD database and select the AD user you wish to add.

Alternatively, you can configure these LDAP users using the CLI by using #config user local.  When adding a user through the CLI just be sure to set the type to ldap.

Hope this helps.

[Fortilover]

Dear @FortiNet_Newb .

Thank you very very much for your response. First of all I have to say that I think I have understood everything regarding the LDAP Server und LDAP User connection within the Fortigate. I am creating my concepts of rolling out a more secure SSL VPN right now. And thank you very very much for your hint regarding the config user local command. I will give this a try again because I tried to use the show user ... commands in order to find my Remote LDAP User object and could not really find it. But I had not so much time to really be sure. I will definetely try this again. And with "real" local users my tests were successful! :)

But you mentioned one thing I have seen as well and this is seriously very important! The guys that setted up the firewall have created a non LDAPS connection. And I was trying for two full days, after reading many many threads about that, to create the LDAPS connection and I was not successful. Yes I have a special account to connect to LDAP. And yes I had imported the root certificate of our internal CA and was hoping that this helped me to make the LDAPS connection to internal Domain Controllers successfull. But in this two days the connection tests always failed. I still try to figure out why. It works without LDAPS but not with LDAPS. Ports and so on are clear to me. Tests with my client laptop in order to assure that LDAPS should work generally were successful as well. But the fortigate always told me. NO. No chance. And I need to say I had no time to go on finding the real error. I thought I need to use the FQDN of the Domain controller because I thought the LDAPS connection needs it for the secure connection. But at this point I found out that the Fortigate could not get the correct IP when using the FQDN of the domain controller because we do not query our internal Domain DNS Servers. This was the point where I stopped my tests about that. I have given the domain controller an extra certificate based on IP and hoped that this could resolve the problem. No. That was not the case. So at this point I was stucked and need to find more time to really understand what is going on. Nevertheless. I will go on and thank you again for your hint about config user local when using Remote LDAP Users. If you have probably a small hint why the connection with LDAPS is not successful... give it a go. Tomorrow is friday. Hopefully a quiet friday where I have time for several hours to deep dive into this again. I need to say it is really fun to understand the fortigate to 100% and how it really works and how to debug this.

Like I said. I have really read several threads about creating LDAPS connection to the DC. I have checked Youtube videos as well. But in this 2 days I have not found a solution that worked. So if you have a small hint please let me know.

I will give it a go again with the help of this article but I could swear I did it exactly like explained in this article: Technical-Tip-Configuring-LDAP-over-SSL-LDAPS 

With kindest regards

Fortilover

And thank you again for your answer :)

[Fortilover]

I works now with LDAPS! :)

But there is a bug in the Fortigate GUI. I cannot create a secure connection. The connection test always fails although the debug tells me everything seems to be fine when checking the connection. The solution therefore is, if you use the GUI to configure this.

1. Create the connection like explained in this tutorial: Technical-Tip-Configuring-LDAP-over-SSL-LDAPS 
2. The connection test will fail.
3. Close the dialogue.
4. Open up the dialogue again and test again. The test will not fail anymore.
5. Test credentials and see if it works like defined.
6. Voila :) LDAPS connection works

@FortiNetSupport: Please be informed about that little bug. It really was not easy to find out. Probably you can address this in one of your next updates.

[Debbie_FTNT]

Hey Fortilover,

thank you for your detailed posts!

Regarding a general guide to use certificates as a second factor for SSLVPN, you have two basic options:

1. Enable the general 'require client certificate' setting in SSLVPN settings.

-> this enforces a client certificate requirement for ALL SSLVPN settings

-> the connecting user must, in addition to username and password, provide ANY certificate issued by a trusted CA. It does not necessarily have to be issued to any specific subject.

2. Add PKI user configuration

-> you can create PKI users via CLI (essentially a user entry that defines a certificate match, with subject requirements and issuing CA requirements)

-> you can add the PKI user to SSLVPN group/portal mappings; users in a group matching this will have to provide a certificate matching the PKI user specifically.

You can refer to this KB for a setup example (it uses a RADIUS server, but you can substitute an LDAP server with essentially no other changes):

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Combining-remote-user-authentication-and-c...

I hope this helps clarify your options!

EDIT:

In case this wasn't addressed yet: the VPN server certificate in FortiGate is for FortiGate to prove its identity to the connecting clients; client certificates are for clients to prove their own identity. The server and client certificates can be issued by completely different CAs and follow different naming conventions, as long as the CAs are trusted and the subjects match as expected.

[Fortilover · Accepted solution]

We have installed FortiTokens Mobile as 2 Factor Method. This increased the security so that we do not want to use certificates anymore. FortiTokens are not cheap but they are not toooo expensive. The system is easy to install and really easy to use. So for us we think FortiTokes are a must have for SSL VPN users in order to increase the security and we can recommend the use of Fortitokens Mobile. App works well for Android, iOS and the Windows App (from Appstore) as well. Although I need to state that using the Windows App from Windows/Microsoft App Store is not really recommended if the App is installed on the machine that is using the SSL VPN Client. Another device like a smartphone is theoretically a better option.