Identity Awarness Certificate Change

[SomAustrianCity]

Hi

I have a question regarding Identity Awareness, i'm not sure how to do that.

Basically, i have a nice setup running. I have a cluster which is my PDP gateway. All other firewalls (14 single gateways and 8 clusters) get all IA information from this gateway. The PDP is fed via 4 IDCs, a lot of MUH agents and a couple of client agents.

I have an internal PKI, which i used to create a certificate fot the portal, so when a user accesses https://mypdpgateway.local/connect/PortalMain, they are not greeted by an error 🙂

Now, the certificate on my pdp will expire on 2023-12-20. And in order for everything to still work, i have to exchange it to a new one. Sadly all the IA agents use certificate pinning, instead of simply trustin my internal PKI (like Windows).

So my question is, how can i exchange the certificate, without breaking my environment?

Reconfiguring the IDCs to the new certificate is easy. Just four machines where i can import it the moment the policy install is done. But the Agents?

For the client agents i use the AD distributed config to control them, but i can only store one fingerprint per gateway, if i'm not mistaken.
For MUH agents, it's even worse. Most of them are on Citrix terminal servers, which are recreated from an image every night. So i have to update the fingerprint with my colleage, and then only on the next day it'll work again, not in between.

I see two ways that i can go now.
Either configure another cluster als PDP and have everything report there. All other gateways will have to query from both PDPs during the transition time.
Or i try switching to http instead of https. I the "Distributed Configuration" tool i can enter a port, so entering 80 may work, i've never tried. But disabling TLS is not my favorite way 😞

Does anyone know of a better way, which is not as complex and time-consuming? IMHO it would be best if all clients simply trust the certificate chains that the OS trusts, instead of cert pinning. But Checkpoint apparently doesn't like that.

Here a few statistics about my environment:

# pdp con ts | wc -l
77

# pdp mon sum a | wc -l
9255

# pdp mon all | grep "Client Type: Identity Agent" | wc -l
120

# pdp mon all | grep "Client Type: Terminal Server Identity Agent" | wc -l
628

The PDP is running on R81.10 JHF Take 110, the Manager on R81.20 JHF Take 26.

Thanks for any help.

[SomAustrianCity]

bumpin' my post up. No one got any ideas? **bleep**...

[Tobias_Moritz]

Please check, if the trust pinning you find on client side is indeed fingerprint of the server cert. As far as I know, it should be the fingerprint of the issueing CA or even root CA.

If that is the case, you can exchange the server cert without any change on client side. At least as long as you do not need to exchange the CA cert.

The fingerprint, the IA agent (normal or terminal server) is saving in Windows registry, is the RfC1751 representation of the SHA1 fingerprint of the ca cert (issueing or root).

If you do not have or find anything to convert RfC1751 strings, just drop your string here and I convert it for you, so you can compare it to you cert chain yourself 🙂

[Tobias_Moritz]

One thing to add: To avoid any change on Identity Agent side, you also need to keep the CN of the server cert unchanged, because that's the name of the registry value.

[SomAustrianCity]

Thank you for your answer, but i'm sorry to say that's incorrect. The Fingerprint is of the Certificate, not the PKI.

I can easily show this, as i have two PDPs (for different Domains), but i'm using the same PKI for the certificates. Alas, the Fingerprints are different, see attached screenshots. Both certs were created by SubCA32, but the IDCs show different Fingerprints.

[Tobias_Moritz]

I thought we were talking about Identity Agents. I never said, that IDC do its trust pinning based on CA cert. As you say, changing config on ICDs is easy, as there are only a few, but the Identity Agents on maybe thousands of clients and servers are.

Your screenshots don't show any SHA1 fingerprint of any certificate, so I cannot compare.

You show screenshots from two IDCs but only one for Identity Agent, so I cannot compare.

🙂

What I can tell you: That string "MINT BUB NE TAN GAME DOWN ..." you see in Identity Agent Dist-Config Tool belongs to a SHA-1 cert fingerprint beginning with BC:41:18:AC:9F:A8:90:EC:16.

Please compare this to the SHA-1 fingerprints of your two server certs and your ca certs.

Than we know for sure, how it works in you environment.

[SomAustrianCity]

I'm posting the fingerprints of all three certs. BC:41: clearly belongs to the cert of usfwrz.

The goal is to replace the PDP certificate, and yes i have IDCs, MUH Agents and Client Agents installed. So all of them need to be taken into consideration. (Luckily no broker 🙂 )

IDCs are easy, as there are usually only a few of them.

For Client Agents, i can set the fingerprint in the distributed config tool, but i don't know how fast the clients will query the new settings. Could be hours in between, so there's a big gap here. And sadly i can only configure one fingerprint, otherwise it would be no problem.

Finally, for MUH Agents, i am firmly believing they too use cert pinning. But neither them nor my client agents display the fingerprint, so i can only rely on my memory of that, and have no screenshots of it.

So my problem still stands, i have to change the certificate, which will change the fingerprint. And i cannot pre-distribute the new fingerprint, in order to prevent any outage.

The only outage-free solution i can currently see is to setup a new PDP and have everything switch over to that one.

[Tobias_Moritz]

Thank you for checking that. That's very interesting. I've an environment here, where its clearly the fingerprint of the issuing CA cert.

And that behaviour never changed from R77.30 to now R81.20 and over various versions of Identity Agents.

I did a test on a test client and replaced that cert pinning in HKLM\SOFTWARE\WOW6432Node\CheckPoint\IA\TrustedGateways to the RfC1751 representation of the actual server certs SHA1 fingerprint, but the agent does not accept that. Instead, it prompts me to trust the fingerprint of the issuing CA cert.

[SomAustrianCity]

Hi

Huh, you're right. I've imported new certs into other gateways, and they now have the same fingerprint - probably the root CAs print. I assume back then, i just imported a cert+key without a chain. So the clients can't create a trust chain to a root, thus the certs own fingerprint.

That will help the next time i have to exchange the certificates, as the Root will be the same. Well, at least until 2037, when the Root expires.

But when that happens, i'll have the same problem. Thus i still think the components should either accept multiple Fingerprints or - even better - trust the client's cert store for these purposes.

Regardless, thanks for your help!

[Duane_Toler]

This may help:

https://community.checkpoint.com/t5/Scripts/rfc1751-py/m-p/194975#M1130

#ShamelessPlug