Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Nik_Bloemers
Collaborator

VPN certificates

Hello CheckMates,

Does anyone know how to control which certificate gets sent in a certificate-based site-to-site VPN?
There's a nice repository of certificates available on the gateway, but it always seems to send the ICA signed certificate. We only want to use the ICA certificate for CP<->CP VPN's that are managed by the same management. We also have some third-party DAIP gateways we want to use another PKI infrastructure for (that already has CRL publicly available, unlike the CP ICA).

Any ideas how to accomplish this? Browsing the documentation and SK's for half a day didn't seem to reveal a solution.

Kind regards,

Nik

34 Replies
Tobias_Moritz
Advisor

Unfortunately, none of the previous posters here updated this thread with their (TAC) findings.

So it would be really nice, if you would do this after you got this figured out with TAC so that we all can learn from it (and TAC gets fewer support cases for the same question). 🙂

Thank you in advance!

0 Kudos
_Val_
Admin
Admin

Second that. Community is for sharing, especially when it comes to resolving your own issues.

0 Kudos
nedomskiy
Explorer

In our case TAC hadn't been able to provide a solution during the months of dialog and we moved IPSec configuration to another vendor's equipment. 
It took long time to explain the problem with 3rd party device certificate-based IPSec authentication (corporate CA) and we got no relative answer. 

0 Kudos
spottex
Participant

Will do.
Case is logged but hasn't passed the "uploaded the requested more info"  stage so far.

0 Kudos
spottex
Participant

After a bit of testing these are the results that helped me understand what was happening a lot better.

Our issue Ikev1 was used.

Ikev1 has 6 packets for the phase1.
packet 3 and packet 4 are certificate requests.
5 and 6 are the certificates responses.

Packet 3 initiator request -> packet 6 peer response
Packet 4 peer request -> packet 5 initiator response

Packet 5 and 6 should have the cert and all subordinate certs listed.
If all subordinates are not installed or are not in the correct section (Trusted CA and Subordinate CA) one gateway most likely will fail the auth

Specifying which cert you want the other gateway to send
When you set matching criteria in an interop device you choose the Root CA for the certificate that you wish the other end to send
Whoever initiates the VPN will use packet 3 for cert request and this will contain the Root CA from the Matching criteria
The responding peer gateway will reply with packet 4 cert request containing the root CA specified in their matching criteria.
If it is a 3rd party device, then they will need to have a way to change their certificate request. Setting an IKE-ID is not enough as that is just a check when the cert arrives at the gateway. (only having one cert installed will work. Until you add a second then CP may use that and the VPN will fail)

Packet 5 will be the initiators certificate sent to the peer that if correct will be from the chain of the root CA in cert request packet 4

If the Peer gateway accepts the cert it will respond with Packet 6 with the certificate from the chain of the root CA in request packet 3.


If there is no Matching Criteria set.
Any Interop device not configured with a Matching Criteria i.e. ANY, That gateway will send a list of all Root CA's installed in Trusted CA's in its cert request.
The peer will choose one of its certificates that match one of the chains containing one of those root certs.
If more than one.. I cannot work out how it chooses without a lot more tests. It would be necessary for the peer to trust all the certs that potentially will be sent.

 

No Trusted CA to match the certificate received.
If a gateway cannot match one of the Root CA’s on the cert recvied, it will send one of its installed certs. If it only has the internal cert it will send that.
I cannot work out how it chooses without a lot more tests.

If the peer responds to a cert request but has a subordinate installed in the Trusted CA section.
The initiator will fail the auth with an error found in normal logs:
Main Mode Expected to get certificate whose root CA is Example_rootCA, got certificate whose root CA is Example_sub_CA_installed_in_trusted_CA


If initiator installs a subordinate in the Trusted section of Check Point
The peer will fail the auth and not send packet 6
Unless it also has the subordinate in the trusted section. This can cause issue down the track when other certificates are used so recommended not to save headaches later.


If the peer sends the wrong CA in its cert request
The peer may have an insufficient way to specify a cert request and it uses a default CA it has install etc.
Your gateway would just choose one of the certs installed, if none installed it will send the ICA cert.

0 Kudos