problem with CRL distribution point address

[Wolfgang]

Dear Checkmates,

we had a problem with the CRL distribution path after migration of a SMS.
We moved SMS from old one to a new machine and changed the hostname and IP-address.

This process was successful, but now we got some problems with VPN between gateways.
The root cause of the VPN problems is a false path in the CRL distribution list point address.Looking in the details of the certificates, there is defined the old path "URL=http://old-SMS.domainname.com:18264/ICA_CRL0.crl"
Every certificate for gateways will be issued with this path, pointing to the name of the old SMS.

Is there a way to change this path without recreating the internal_CA?

As a workaround we added the DNS name for the old SMS to the gateways hosts file and everything is fine, but we want to solve it basically.

Thanks

Wolfgang

[PhoneBoy]

Pretty sure the only way to change the CRL address is to regenerate the ICA. 

[Vladimir]

Can someone explain which components of the Check Point infrastructure serve as CRL distribution points? I have run into the situation where SMS that had CRL updated was removed from the infrastructure, its earlier version (snapshot) brought online and, when the gateways that were offline throughout this process, re-connected to the network immediately losing SIC.

During this operation, the only other components remaining online were a log/SmartEvent server and another cluster.

Thank you.

[PhoneBoy]

Management server(s) are the CRL distribution point.

[Vladimir]

If only primary and secondary management servers are the CRL distribution points, it does not explain the observed behavior: management server that was brought online before old gateways rejoined the infrastructure never had SIC for these gateways reset. Or does management servers broad definition includes the Log/SmartEvent server as well?

[PhoneBoy]

If the CRL is not available for whatever reason, SIC will assume the certificates are still valid...at least for a period of time.
With site-to-site VPN using ICA certificates, if the management server is unavailable for more than 24 hours, the VPNs will start failing. 
While I don't know for certain, I assume SIC will do something similar.

In any case, when the management server was brought back up with an older version of the ICA database, the certificates those gateways had were no longer considered valid, thus breaking SIC.
This seems like expected behavior.

[Vladimir]

@PhoneBoy , but it does not look like that's the intended behavior:

In my case, the time between old SMS and the new and the old gateway swap was less than 6 hours. The only explanation for the persistence of revocation is that either the Log/SmartEvent (or it and the other gateways) is/are acting as a CRL distribution point(s).

As per sk62873 "A SIC Certificate is valid for 5 years from its creation. At the 75% threshold, it will be renewed automatically."

Can we get someone in the group working on it to verify?

Thank you.

[PhoneBoy]

You can use the command cpca_client get_crldp to see what the CRL distribution points are.
It should only be the management server(s) listed there.

[Vladimir]

@PhoneBoy  Thank you! I'll try it today I will let you know the outcome.

[Vladimir]

I am seeing:

"Bad input while trying to get the ca name"

response when running that command on the gateway or a secondary management server in R80.40.

In R81.10, I am seeing "This operation is supported for MGMT only".

[PhoneBoy]

Right, you run it on the management.