Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Magion
Contributor

(Computer) client certificate validation

Hi,

 

I have a working SSLVPN solution where I use client validation to check for a computer certificate from our internal PKI on the client. Domain computers get a certificate using autoenrollment policies and the root certificate is stored on the Fortigate. By enabling users to select the computer certificate in FortiClient during login, they can select the right certificate, which can be validated by Fortigate. So far so good...

 

The problem is, any certificate/key pair on the client, with a matching root on the Fortigate passes certificate validation. Since we use Lets Encrypt certificates, I uploaded the root of LE onto the Fortigate. If I install any valid LE certificate on the client, this certificate is also accepted.

 

Fortigate accepts any valid certificate for which it has a root certificate installed.

 

Is there a way to limit validation to specific root certificate(s)? Or perhaps check on specific certificate details?

 

 

Using only Fortigate, no other Fortinet products.

User authentication is done entirely on a remote Radius server, so no local/ldap/radius users defined.

FortiOS 6.0.5, FortiClient 6.0.8

 

Thx,

Michel

4 Solutions
Magion

Just got word from support again. The gave me this link: https://kb.fortinet.com/kb/documentLink.do?externalID=FD47120.

 

Although I find the example config a bit confusing, it seems like what I want to accomplish might be possible... but only from FortiOS 6.2.2+. We are still on 6.0.5.

 

View solution in original post

emnoc
Esteemed Contributor III

 

 

Here's what I'm talking about in auth-rule

 

 

 

config vpn ssl settings  set reqclientcert enable  set ssl-min-proto-ver tls1-1  set servercert "Fortinet_Factory"  set tunnel-ip-pools "SSLVPN_POOL_1"  set port 8443 config authentication-rule   edit 1   set source-interface "wan1"   set source-address "all"   set users "user1"   set portal "full-access"   set client-cert enable   set user-peer "socpuppets"   next  end end

 

The set user-peer is your  CA with or without the subject 

 

 

 

 

 

 

 

PCNSE 

NSE 

StrongSwan  

View solution in original post

PCNSE NSE StrongSwan
emnoc
Esteemed Contributor III

Hey, I just wanted to say I test it by only using the CA and no cn or subject string so it worked  What I did was use the web-acecs and firefox and called up a inferior certificate that did NOT match the "config user peer"

 

So if you are issuing certificates from a privateCA, just 1> import the ca into  the firewall 2> sign all users with that CA >3 and set a "config user peer" and finally use that peer in the auth-rule.

 

It should work and lock down the sslvpn. If the client presents no certificate or a certficate that is not signed by the CA you defined , the ssl will reject that connect. You will see this on a "diag debug application sslvpnd -1"

 

e.g 

 

[23346:root:3b]rmt_web_auth_info_parser_common:470 no session id in auth info [23346:root:3b]rmt_web_access_check:723 access failed, uri=[/remote/logincheck],ret=4103, [23346:root:3b]User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:72.0) Gecko/20100101 Firefox/72.0 [23346:root:3b]rmt_logincheck_cb_handler:1189 user 'user1' has a matched local entry. [23346:root:3b]sslvpn_auth_check_usrgroup:2039 forming user/group list from policy. [23346:root:3b]sslvpn_auth_check_usrgroup:2145 got user (1) group (0:0). [23346:root:3b]sslvpn_validate_user_group_list:1642 validating with SSL VPN authentication rules (1), realm (). [23346:root:3b]sslvpn_validate_user_group_list:1690 checking rule 1 cipher. [23346:root:3b]sslvpn_validate_user_group_list:1698 checking rule 1 realm. [23346:root:3b]sslvpn_validate_user_group_list:1709 checking rule 1 source intf. [23346:root:3b]sslvpn_validate_user_group_list:1730 checking rule 1 source address. [23346:root:3b]sslvpn_validate_user_group_list:1845 rule 1 done, got user (1:1) group (0:0) peer group (0). [23346:root:3b]sslvpn_validate_user_group_list:1963 got user (1:1), group (0:0) peer group (0). [23346:root:3b]fam_cert_send_req:808 do certificate peer check first(2). [23346:root:3b]doing certificate checking for 1 peer(s). [23346:root:3b]sslvpn_update_user_group_list:1579 Remove user(s) which has set user-peer (1). [23346:root:3b]sslvpn_update_user_group_list:1595 got user (0:0), group (0:0), peer group (0) after update. [23346:root:3b]__auth_cert_cb:939 no valid user/group candidate found.

 

 

PCNSE 

NSE 

StrongSwan  

View solution in original post

PCNSE NSE StrongSwan
Agent_1994

Magion,

 

 I did something like this in my lab. All the users are Active Directory users:

 

config user peer     edit "peer1"         set ca "home_lab"         set subject ".hydra.local"     next end

 

 In plain english, this is "certificate must belong to the home_lab CA and it's subject must have .hydra.local". The latter is the FQDN matching trick I told you.

 

 Next I created a realm "portal1" and did this:

 

config user ldap     edit "DC"         set server "dc.home.lab"         set cnid "userPrincipalName"         set dn "dc=home,dc=lab"         set type regular         set username "HOME\\fortigateLDAP"         set password [removed]     next end

 

config user group     edit "vpn"         set member "DC"         config match             edit 1                 set server-name "DC"                 set group-name "CN=VPN,OU=User Accounts,DC=home,DC=lab"             next         end     next end

 

config vpn ssl settings     config authentication-rule         edit 1             set groups "vpn"             set portal "full-access"             set realm "portal1"             set client-cert enable             set user-peer "peer1"         next     end end

 

 The test were:

[ul]
  • user + no certificate: fail
  • user + any user certificate from home_lab CA: fail
  • user + any computer certificate from home_lab CA: works
  • user (wrong credentials) + any computer certificate from home_lab CA: fail
  • user + any certificate from a CA other than home_lab: fail[/ul]

     Hope this helps

     

    Max

  • View solution in original post

    39 REPLIES 39
    Kojot_
    New Contributor II

    I now understand that I do not "config user peer" but only selected "require user certificate"

    I think I need to do like in this article https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/751987/ssl-vpn-with-ldap-integrated-cert...  but change according to kb

    # config user peer    edit user1          set ca "CA_1"       set subject "OU = your_org"    next end

    and now any certificate of my CA with "OU = your_org" will be accepted.

    Kojot_
    New Contributor II

    I configured this. It is works when unchecked "Limit Users to One SSL-VPN Connection at a Time", because all users now are "certificate cn"(all users use one certificate) . And in VPN-Events all users same.

    Revert all back.

     

    like Magion said:

    "I was hoping for something easy like:  config vpn ssl settings set reqclientcert enable set ca 'my root ca' end

    "

     

    emnoc
    Esteemed Contributor III

    Yes play around with the config user peer. You can set the string or "cn"  and even do a peergroup if you so desire.

     

    Ken Felix

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    Kojot_
    New Contributor II

    I now understand that I do not "config user peer" but only selected "require user certificate"

    and now any certificate of my ou will be accepted.

    I think I need to do like in this article https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/751987/ssl-vpn-with-ldap-integrated-cert...  but change according to kb # config user peer    edit user1          set ca "CA_1"       set subject "OU = your_org"    next end

    and now any certificate of my CA with "OU = your_org" will be accepted.

    Kojot_
    New Contributor II

    I now understand that I do not "config user peer" but only selected "require user certificate"

    and now any certificate of my ou will be accepted.

    I think I need to do like in this article https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/751987/ssl-vpn-with-ldap-integrated-cert...  but change according to kb # config user peer    edit user1          set ca "CA_1"       set subject "OU = your_org"    next end

    and now any certificate of my CA with "OU = your_org" will be accepted.

    Magion

    tanr wrote:

    Did they give a bug number?  There was a similar issue with 5.6 FortiGates just accepting the certs based on their root ca instead of actually checking the details.

     

    From support:

     

    Unfortunately, there is an internal ticket 574949, which is a security concern that once you enable require client certificate, you will allow all users signed by certificates that are trusted by the FortiGate

    Magion

    Lot's of posts (but did not get any notifications ). Will read them more closely on Monday, some of it looked very interesting.

     

    Just like to mention that I do not use local users. All authentication is done remotely on a radius server, and all I did was add the radius server as a remote group to a local firewall group.

     

    If I understand support and the article I linked to correctly, it's possible to 'attach' a root certificate to all remote radius users by creating 1 peer user and add this to the firewall group next to the remote group.

     

    But, since I only have a live production FortiGate top work with, I need to be careful of any tests I like to do. Especially now, since everybody is working from home and depend on the VPN (which by the way has been very stable so far)

     

    Michel

     

    tanr
    Valued Contributor II

    Magion, did TAC specify if 574949 was fixed in any later versions?

     

    It sounds like they managed to "unfix" the old bug I was referring to, 412987.

     

    When a serious bug like this or that is fixed, standard practice is to add a simple regression test to make sure it doesn't happen again.  It sounds like that wasn't done.

    Magion

    tanr wrote:
    Magion, did TAC specify if 574949 was fixed in any later versions?

    No, and I did not ask about it.

    Agent_1994
    Contributor

    Magion,

     

     I had a similar problem days ago, but with an internal CA. I wanted to use computer certificates but not user certificates. 

     First, the user have to be administrator or at least have permissions to access the computer certificate private key. If not, the certificate will be available in FortiClient but wont work.

     Second, in user->pki I used subject filterning to match part of the FQDN. I.E.: my lab environment had hydra.local as the domain, so the subject filter was ".hydra.local" (note the dot at the start, it will match computer.hydra.local but not user@hydra.local).

     That being said: if your certificates have something in common -or could have-, you can use subject filtering. 

     

    Max

    Announcements

    Select Forum Responses to become Knowledge Articles!

    Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

    Labels
    Top Kudoed Authors