VPN certificates

[Nik_Bloemers]

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

[Danny]

This can be configured in the gateway object > IPsec Site-to-Site VPN. There you can choose which certificate from the cert repository it has to use.

HowTo Set Up Certificate Based VPNs with Check Point Appliances

[Nik_Bloemers]

I still don't quite understand how. I found that post yesterday and I know you can configure what CA the certificate of the other side has to belong to (with the Matching Critera on the Interoperable Device) but I don't understand how to control the certificate that is sent from Check Point to the third party DAIP gateway. The post shows how to do it with an Externally Managed CP gateway, but the GW we're dealing with on the other end is not Check Point.

[Danny]

Setting up the ICA Management Tool

Best Practices - ICA Management Tool configuration

Expired certificates cannot be deleted from the Management Database

Basically you can just run "cpca_client  set_mgmt_tool on  -no_ssl" in expert mode of your SmartCenter, connect to the ICA Management Tool via http://SmartCenter-IP:18265/ and configure your certificates and turn off the Management Tool via "cpca_client  set_mgmt_tool off" afterwards.

[Nik_Bloemers]

I don't see how the ICA Management Tool is going to help me. It's for downloading or revoking the ICA issued certificates.

I have 2 certificates available in the IPSEC VPN pane of the Check Point gateway:
1. the default Check Point ICA issued certificate
2. a certificate signed by our internal PKI infrastructure CA

What I need to know if how to configure Check Point to send the non-ICA certificate (2) to a third party VPN peer instead of the internal ICA one (1).

[PhoneBoy]

For these third party DAIP gateways, are they part of the same VPN community or a different one?

[Malopro]

On Management Server using object Explorer you can create under Servers - Trusted CA an object that defines a external CA, you will need the Root CA Certificate ... Once done you can use Digital Certificates issued by that external CA for the VPNs that you need.

Simply add the Certificate under Gateway - IPSec VPN properties page !!

I did myself a couple of times using Comodo issued Certificates !!!

Warm regards

[Nik_Bloemers]

As mentioned, I have the trusted CA certificate available under IPSec VPN tab along with the ICA certificate, it just doesn't send it to peers, it only sends the ICA certificate.

[_Val_]

why not using preshared key, if your remote GWs are a third party?

[Nik_Bloemers]

Because they're DAIP. Check Point doesn't allow PSK for DAIP peers.

[G_W_Albrecht]

So i would suggest to use the CP internal CAs certificates - for S2S VPN this has no drawbacks...

[Nik_Bloemers]

But we have a PKI infrastructure for which the CRL is publically available. This is not the case with CP PKI. It should be possible to use a different PKI infrastructure. It is also managed by different people than the CP ICA infrastructure. So there is a drawback.

[Nik_Bloemers]

They are part of the same community since they are trusted locations. They just don't have Check Point gateways at those locations (yet).

[Malopro]

Nik ...

I did it to stablish a Certificate authentication based Site to Site VPN with a Cisco appliance.

Did you delete the ICA Certificate on the IPSec VPN properties ??

Regards

[Nik_Bloemers]

@Malopro: indeed, I want to use the ICA certificate for the CP-CP centrally managed VPN's. Besides, what's the point of having a certificate repository if you can only actually use one certificate... Deleting the other certificate should not be the solution.

[Malopro]

Uff ... forget my previous post ... you have CheckPoint and no-Checkpoint on the same community ...

Regards

[PhoneBoy]

For the peers in question, do you have them configured to require presenting a certificate signed by a specific CA?
You would have to import and configure an OPSEC CA object.
This is described in the "Trusting an Externally Managed CA" section of the R80.30 Site-to-Site VPN guide: https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_SitetoSiteVPN_AdminGuide/htm...

Then you go into the external object and configure the matching criteria, as shown here:

[Nik_Bloemers]

Yes, I have the Matching Criteria enabled and that part works. The Check Point accepts the PKI signed certificate from the third party peer gateway properly (I have a one-way IKE Main mode), that's not the problem. The problem is that Check Point sends the ICA certificate to the third party, which is not trusted obviously and the negotiation fails. On the third party gateway I can easily configure what certificate to send to a peer, but on Check Point this seems either impossible or needlessly obscure, while they force you to use certs for authentication.

[PhoneBoy]

Specifically, we force the use of certificates for DAIP gateways in particular as Pre-Shared Keys are not entirely secure in this configuration.
Trying to confirm with R&D if it's possible to use different certificates.

[Nik_Bloemers]

Thank you. It would be really odd if it wasn't possible. What's the point of having a certificate repository for IPSec then... Also, it's something that's easily possible on even 10 year old ScreenOS devices. I can just select what certificate to use for a peer gateway from a simple dropdown.

[PhoneBoy]

What R&D tells me is that it should not be necessary to configure which certificate our gateway sends.
The gateway should send the correct certificate automatically based on the IKE negotiation, which includes what CA(s) are considered valid for a given gateway.
This, of course, assumes the CA is trusted (i.e. configured as an OPSEC CA) and the gateway has a certificate issued by that CA.
That suggests a TAC ticket might be in order.

[Nik_Bloemers]

Thanks for the information. It's good to know how it's supposed to work, though I find it very odd that as the admin I can't decide what cert gets sent, but CP does it on it's own. The CA should be correctly trusted (since the Check Point side accepts the certificate sent by the peer no problem, I get a Main Mode complete for that), but the other side doesn't accept the certificate obviously since it receives the default cert instead of the cert signed by the same CA. I will see about contacting TAC. We might just go with a slightly different setup because of the way Check Point handles this.

[_Val_]

@Nik_Bloemers IKE phase one completion usually means both sides trust their certificates. 

You also can add externally issued certificates for your managed GWs.

[Nik_Bloemers]

The peer clearly rejects the certificate, it's visible in the logging of that device (and it shows which certificate it has received). Why the CP side says Main Mode completion I don't know. I guess the CP side built an IKE SA successfully, since it has received a valid certificate.
Not sure what you mean by your second remark/screenshot. As stated a few times the externally issued certificate was added to the repository successfully, it's just not being sent the peer (only the default ICA signed one is).

[PhoneBoy]

Which, again, suggests a TAC case might be in order.

[wpronk]

Good afternoon,

We want just the same as described above, is there a solution or hotfix available for this problem?

Kind regards,

Wesley Pronk

[mihaime]

Hi,

I'm also trying to configure cert based auth between Checkpoint Cloudguard and Aviatrix and running into issues.

I imported the Aviatrix CA.

I created an "Interoperable Device" where under IPSEC VPN -> Matching Criteria I set the Aviatrix CA and did not check any fields (none would match currently from what I've seen).

Does it work without selecting any? (meaning validating just that the cert provided by the other end is signed by the Trusted imported Aviatrix CA).

Is there any other way to debug except activating debug here:

vpn debug trunc ALL=5 (or increase debug level here even more?)

and looking at 

$FWDIR/log/ike.elg*

$FWDIR/log/vpnd.elg*

I'm not getting the exact reason for cert auth failure while looking in the logs and get confused as to what the reason is.

[spottex]

When you say ANY do you mean not selecting a certificate or not selecting any of the alternate options like IP DN or Email?

Matching criteria cert section is the CA you want the other end to send a certificate from. In the VPN negotiations your FW will send a cert 'request' saying send cert from this CA only, and if you had IKEview app you would see the cert requests from each FW.
If the peer does not have a cert signed by that CA in the request it will send it's default.
Your FW will only succeed authentication if a cert now arrives signed from that CA. (i.e. if the default is differnet and sent it will fail)

The same will happen in the other direction. The peer will have a cert request and your FW needs to have the correct signed cert to send back or it usually sends it's Check Point Internal cert, and the peer will fail the auth.

If you select any in the cert field. Your FW will send a cert request with all your installed CA certs including your CP internal cert. The other end will try and match one and send it. If it doesn't it will send it's default and auth will fail (as you don't have its CA otherwise it would have matched)
For a shot gun approach both sides will need to have the CA for all possible certs each will send. But it is better to match the certs correctly.

As for the DN IP and email, On the check point side they can be left blank. They are extra levels of security. Some FW's like Sonicwalls you have to use them. And when creating the certificate on Checkpoint you need to add one e.g. add alternate IP to the cert if it is not the main IP of the gateway then configuring the Sonicwall to accept that IP (Also for Sonicwall it has to be the first alternate IP in the certificate if there are multiple)

In your debugs if R80+ the files should be legacy_ikev2.xmll and legacy_ike.elg
Look for the cert requests and compare them to certs sent - you can work out the direction of the packet by the arrows and then replies.
The auth can fail early before the second cert is sent so you may get one or two in the debug

If there is a way to get the debug to me I would decipher it for you.

[mihaime]

Hi spottex,

Thank you for helping out.

By ANY I meant not selecting any criteria (email, IP, DN).

Part 1 - Checkpoint gets connection from Aviatrix

Yeap the first phase was clear to me. I was not sure how Checkpoint behaves if I select no criteria -> if it just accepts the certificate (without any prerequisites) if signed by the selected/mentioned/trusted/imported from Aviatrix CA.

One confusing thing to me is what CA I should select (I assume OPSEC as it's not coming from an External Checkpoint).

Will download the IKEView utility (seems cool, makes it easy to follow what is going on).

Putting here also the helpful link I found while googling for it:

https://support.checkpoint.com/results/sk/sk30994

Part 2 - Aviatrix gets connection from Checkpoint

I already imported the Checkpoint Internal CA inside Aviatrix and there I have a remote identifier field which has to match on Subject or on IP Address (both are present in the internal cert signed by the Checkpoint Internal CA).

Part 3 - other points

I only have 1 x CA on each side so I'm safe on this point. I tried to keep it as simple as possible before increasing complexity so that I can troubleshoot it.

Ah similar stuff you said about Sonicwall applies to Aviatrix (just that I can match on Subject in the Cert or on IP Address).

I added the internal IP given I have a Cloudguard and the IPSEC packets have private IPs before Azure "SNATs" them to the Public IP.

I have R81.10 with the latest update/patch level. 

Thank you very much for the tip with those 2 x legacy_ike files and IKEView.

I have now something more to go on. I was feeling like hitting a dead-end.

I also noticed that my "vpnd" process (after playing around with the Certificates and matching criteria) started restarting in a loop.

Basically each time after IKEv1 auth and agreeing on the proposal, when passing to the certificate part -> bam process restart.

That I still investigate now if it's due to me having ECDSA certs (gonna replace with an RSA on Aviatrix side).

[spottex]

Actually another thing. If your gateway cannot reach the Cert revoke list that is presented in the cert the auth will fail. I.e. does not have internet access or DNS resolution. The later versions of CP default to use OSCP for checking and if it can't connect it will fail. You can't disable it like the old versions.
TAC say it is Ikev2 only has this issue but I never tested IkeV1. The fix is due in a jumbo HF but have not seen it yet. You will see this issue in vpnd.elg and an error containing:  error message for logging is: OCSP: could not connect to server
R81.10 ikev2 jumbo 79 and below definitely has this issue even when using sk179434
TAC can supply a HF if it is not in a Jumbo yet