How does a gateway pick a given cert for 2s2 vpn?

[John_Fleming]

I just upgrade a MDS from 77.30 to 80.40. out of a quarter of a thousand gateways only 2 had problems post policy push. Both gateways (both R77.30 JH 351) were vpns in the same CMA and forced to cert base vpnd. 

The given gateways have 2 certs installed. defaultCert and one for client auth portal. What we found after looking at vpnd.elg debugs was this.

defaultCert - This cert is good and I can reach the CRL. We can use this!

... 

but lets keep searching!

This cert is good (client auth cert).. but I can't reach the CLR! This cert is terrible! (thanks for diamond catching the crl fetch error)

VPN FORPLAY FAILED - THIS CERT IS GARBAGE!

Thats the exact error message found in vpnd.elg if that wasn't clear (i'm pretty sure it was at least)

We added a host entry to resolve the CRL (no DNS on these) and then VPN went from down to plaid so things looked much better. 

After chatting with the diamond rep neither of us were sure how it was picking the cert. In the cert list defaultCert is first in the list. Its like its saying all certs have to be valid or maybe only the last? I see the cert option on the vpn client window and we tried  flipping that around but it didn't do anything. I stopped short of assassinating vpnd as there were other PSK VPNs we didn't want to mess with on this gateway, which never went down.

Also this worked fine before push from R80.40 so it seems related i'm just not sure how. Its working as is so we're fine with it for now.

[PhoneBoy]

I think it tries them all (probably starting with the ICA cert) until it finds one that works/is accepted by both ends.
Validating the CRL is part of that process.

[John_Fleming]

yeah I get the importance of CRL fetching just saying I didn't understand why the internal cert wasn't being used since it was fine and was seen in vpnd before the additional cert used for client auth. After posting this I noticed that big s2s vpn question that is somewhat close. Its like its choosing the last listed cert in the list or maybe its use defaultCert unless signed cert attached then use that? Not sure what the logic is. Again its working so we're not poking the bear anymore.

https://community.checkpoint.com/t5/Security-Gateways/VPN-certificates/m-p/70001#M12002

[Henrik_Noerr1]

Actually, the bear should be poked until it is submissive...

The fact that Check Point only offers cert validation in s2s vpn is beyond me. It has been broken for +15 years.

No warnings of certificate expire, no auto renewal, crl list problems when migrating etc - The list is long.

Please offer simple PSKs. Thank you

Henrik

[John_Fleming]

Technically there are cert expire warnings.. they're just a few lines in what is most likely a massive list of object warnings. 

Problem will be dealt with in a different way down the road.

[PhoneBoy]

The main issue with PSKs is that they are significantly less secure.
We allow them with third party gateways provided they are not behind HIDE NAT.

Are the issues you detail with ICA certs or with third party certs?

[Henrik_Noerr1]

I get they seem less secure, but a parameter regarding security is Availability. I'm not (intentionally) trying to be the grumpy old man, but the argument that "We don't provide this feature, because it is insecure" is simply not valid.

NIST standards own say on PSKs used for VPN is that they are perfectly valid (is s2s): - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1.pdf "PSKs must have a high entropy value. A good PSK is pseudorandomly created and has at least 128 bits of entropy." and "In fact, many VPN implementations actually
tend to decrease availability somewhat because they add more components, complexity, and
services to the existing network infrastructure."

But the simple fact when you use certs for the vpn is that you add on many dependencies.

- No checks warns the users that the crl is not reachable causing the vpn to go down in the future.

- You need to maintain firewall rules to allow crl access to the mgmt/cma on all in between devices

- DNS needed for 3rd party crl lookups

- Expire time warning is not usable

- no auto renew certificate

- And I'm sure there are many other reasons to avoid this.

Besides this - I'm quite happy 🙂

/Henrik

[John_Fleming]

Get off my lawn!