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

X509 Certificates - Matching Users based on CN oder Subject via Substring

Hi Community,

 

I would like to setup two different Phase1 IPSEC Interfaces which divides the peers via identifiers based on certificate matching. Suppose we have two companies and the structure of the CN is basically a String formatted like a FQDN of the Computer. Is there a chance to divide peers from company A and company B based on two peer-groups with a CN-Match Substring?

 

The CN has the classic form of computername.companyA.com or computername.companyB.com. In my test it was perfectly fine to use the full CN but a match based on substring matching does not do the job. Off Course the config vpn certificate setting Entry cn-match and subject-match is set to substring.

 

So what syntax, wildcard-Characters or even maybe regex can be used for the CN-Matching? Is there a way to go on the substring  "companyA.com" or can the cn Value in config user peer only be a whole string separated by whitespaces? Is there a knowledgebase Article or a more descriptive Article for the feature?

 

Thanks in Advance,

Michael

1 Solution
emnoc
Esteemed Contributor III

No not really that much but read on for more detail.

 

And that make zero sense for that business requirement to have one CA.

 

The private CAs can be crafted as required or even multiple intermediate CA  instances could be stroked as required if you want separation,  but need everything under the same root.

 

It isn't like you have to go out buy your "own private-rootCA" or charged for each intermediateCA ;) Just design a proper PKI infrastructure one time and you will be set for lie.

 

e.g    ( multiple intermediate CA approach ) 

 

       CAroot

          |

          | -------->  intermediateCA_A----users  for companyA    /* dialup vpn for companyA.com */

          |------------->  intermediateCA_B----users for companyB    /* dialup vpn fo companyB.com */

 

Now if you do the above, your peer is matched in the  user peer obj and match for companyA or companyB  intermediateCAs as required for your dialup ipsec or sslvpn users or webportal.

 

You can also look at subject constraint but I have not had a lot luck in that when you are trying to match multiple  "subjects"  from various users and you have area of potential problems. You have to be careful in this area and thread carefully.

 

e.g 

 

config user peer

    edit user1

      set ca CAcert1

      set cn-type fqdn

      set subject user1.example.com

     end

 

You best bet is a unique CA for each company. You would need to lab it and do a PoC, but if you go the 2 CAroot or  2 intermediateCAs route,  you can easily do what I suggested earlier and not worry about subject constraint matching and the potentials issues that might come up.

 

If you go one single CA signing all end users certs, than you will have to built a peergroup and add each "users" to that and defined a "config user peer" matching the subject field

 

e.g 

 

 

   config user peer

     edit user1

      set ca CAcert1

      set cn-type fqdn

      set subject user1.example.com

      next

      edit user2

      set ca CAcert1

      set cn-type fqdn

      set subject user2.example.com

     next

  config user peer

    edit user3

      set ca CAcert1

      set cn-type fqdn

      set subject user3.example.com

     end

 

config user peergrp

    edit "gr1"

       set member user1 user3

    next

     

    edit "gr2"

       set member user2

    next

end

 

A lot more over head for configurations imho but that would work also.

 

NOTE: I would look to see if wildcards are a possibility you might need to raise a ticket with FTNT-support;

 

e.g 

 

config user peer

    edit example1

      set ca CAcert1

      set cn-type email

      set subject *.example1.com

      next

   edit example2

      set ca CAcert1

      set cn-type email

      set subject *.example2.com

     end

    

 

 

 

You can look at what I previous posted in the past on potential "subject strings" constraints, like here this might work & if you subject strings are always unique when the CSR is generated and signed. If your CSR creation is not matched for correctness you might have issues , but you should be able to easily controlled this in MS by GPO. I would look or ask your domain-administrator for help in that area.

 https://forum.fortinet.com/m/tm.aspx?m=184812&p=3

 

Subject constraint matching on "ou"

 

/* subject pattern matching  by OU  */

 

 

    set subject "ou=companyA"

 

vrs

 

   set subject "ou=companyB"

 

YMMV,  but I would lab it and test you process and make sure on way or the other make sense and works for your ORG.

 

I would still press your business to think about a 2x intermediateCA under the same rootCA. if your company splits off or need comes up to peel the 2 company business sectors out, it might make life easier.

 

just my humble opinion from past experiences and issues that I've ran acrossed in the last 10+ years.

 

Ken Felix

           

PCNSE 

NSE 

StrongSwan  

View solution in original post

4 REPLIES 4
emnoc
Esteemed Contributor III

If you have 2 companies, why not have 2 CAs and sign userAs with CA-rootA and userBs with CA-rootB? Now you can use a ca-peer match

 

example;

 

config user peer

    edit "companyA"

        set ca "CA_Cert_1"

    next

    edit "companyB"

        set ca "CA_Cert_2"

    next

end

 

 

 

Ken Felix

 

PCNSE 

NSE 

StrongSwan  

mike74
New Contributor II

Hi,

Thanks for the response. Because of Compliance Rules this must be the same CA. It's simple a Management Decision so we have to use that one.

 

Do you have any Information regarding pattern-rules of the Substring search in CN's in the config user peer section?

 

Thanks,

Michael

emnoc
Esteemed Contributor III

No not really that much but read on for more detail.

 

And that make zero sense for that business requirement to have one CA.

 

The private CAs can be crafted as required or even multiple intermediate CA  instances could be stroked as required if you want separation,  but need everything under the same root.

 

It isn't like you have to go out buy your "own private-rootCA" or charged for each intermediateCA ;) Just design a proper PKI infrastructure one time and you will be set for lie.

 

e.g    ( multiple intermediate CA approach ) 

 

       CAroot

          |

          | -------->  intermediateCA_A----users  for companyA    /* dialup vpn for companyA.com */

          |------------->  intermediateCA_B----users for companyB    /* dialup vpn fo companyB.com */

 

Now if you do the above, your peer is matched in the  user peer obj and match for companyA or companyB  intermediateCAs as required for your dialup ipsec or sslvpn users or webportal.

 

You can also look at subject constraint but I have not had a lot luck in that when you are trying to match multiple  "subjects"  from various users and you have area of potential problems. You have to be careful in this area and thread carefully.

 

e.g 

 

config user peer

    edit user1

      set ca CAcert1

      set cn-type fqdn

      set subject user1.example.com

     end

 

You best bet is a unique CA for each company. You would need to lab it and do a PoC, but if you go the 2 CAroot or  2 intermediateCAs route,  you can easily do what I suggested earlier and not worry about subject constraint matching and the potentials issues that might come up.

 

If you go one single CA signing all end users certs, than you will have to built a peergroup and add each "users" to that and defined a "config user peer" matching the subject field

 

e.g 

 

 

   config user peer

     edit user1

      set ca CAcert1

      set cn-type fqdn

      set subject user1.example.com

      next

      edit user2

      set ca CAcert1

      set cn-type fqdn

      set subject user2.example.com

     next

  config user peer

    edit user3

      set ca CAcert1

      set cn-type fqdn

      set subject user3.example.com

     end

 

config user peergrp

    edit "gr1"

       set member user1 user3

    next

     

    edit "gr2"

       set member user2

    next

end

 

A lot more over head for configurations imho but that would work also.

 

NOTE: I would look to see if wildcards are a possibility you might need to raise a ticket with FTNT-support;

 

e.g 

 

config user peer

    edit example1

      set ca CAcert1

      set cn-type email

      set subject *.example1.com

      next

   edit example2

      set ca CAcert1

      set cn-type email

      set subject *.example2.com

     end

    

 

 

 

You can look at what I previous posted in the past on potential "subject strings" constraints, like here this might work & if you subject strings are always unique when the CSR is generated and signed. If your CSR creation is not matched for correctness you might have issues , but you should be able to easily controlled this in MS by GPO. I would look or ask your domain-administrator for help in that area.

 https://forum.fortinet.com/m/tm.aspx?m=184812&p=3

 

Subject constraint matching on "ou"

 

/* subject pattern matching  by OU  */

 

 

    set subject "ou=companyA"

 

vrs

 

   set subject "ou=companyB"

 

YMMV,  but I would lab it and test you process and make sure on way or the other make sense and works for your ORG.

 

I would still press your business to think about a 2x intermediateCA under the same rootCA. if your company splits off or need comes up to peel the 2 company business sectors out, it might make life easier.

 

just my humble opinion from past experiences and issues that I've ran acrossed in the last 10+ years.

 

Ken Felix

           

PCNSE 

NSE 

StrongSwan  

mike74
New Contributor II

Hi Ken,

 

Thanks for your comprehensive response. Unfortunatly the wildcard-matching with an Asterisk in the cn-Setting did not work, so I followed your advice and opened a case. Maybe I will find out how many entries a peergroup supports on the hard way but we have no chance to add a second CA or even a Sub-CA. This is not intented by the designer. I will report back what the Engineers from Fortinet will tell me regarding the substring-match.

 

Thank,

Michael