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
Solved! Go to Solution.
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 nextend 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
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" nextend
Ken Felix
PCNSE
NSE
StrongSwan
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
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 nextend 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
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
Dear Michael,
did you ever get this working with a wildcard in Subject and/or CN? I am running in the same issue unfortunately.
Hello,
I also have a requirement to match on a substring of the certificate subject field.
For example, let's say I have a certificate with "CN = matt.mycompany.com" in the subject.
If I set this as the subject to be matched under the PKI user it works fine.
But if I configure the PKI user with a subject of "*.mycompany.com" or "mycompany.com" or ".*.mycompany.com" it does not match, despite the cert settings being configured to match a substring.
I want to be able to match matt.mycompany.com or bob.mycompany.com or fred.mycompany.com or anyone.mycompany.com in the certificate subject field.
Yes, I could do as @emnoc suggested previously and create a new sub-CA and use this but I really shouldn't have to engage the PKI team when the FortiGate itself should be able to do this.
Is it a bug??
Any help gratefully received!
Many thanks, Matt.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1737 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.