Problem with ssl certificate - Quantum spark 1590

[aMatthew]

Good evening, everyone,

I hope someone can help me in this issue :

A few weeks ago we updated the ssl certificate for both the gateway portal and the VPN client.

Currently the portal is exposed on port 4434 while 443 is used for VPN RA.

When I access the portal on port 4434 the certificate is displayed correctly and the expiration date is correct .

However, if I check on port 443 it tells me that the certificate has expired, showing me the date of the last certificate.

We cleared all the cache and there is no trace of the old certificate.

We have opened a case at TAC and it tells us that all the operations were done correctly.

However on any site that checks on the certificate (ssl shopper or Qualys) it tells us that the certificate has expired.

It is the quantum spark 1590 series.

Has anyone ever encountered such an issue ?

Has the gateway already been rebooted/updated and any other tests with TAC

Thank you all.

[Lesley]

I don't think it is possible as listed in: https://support.checkpoint.com/results/sk/sk110533

• The Quantum Spark Appliance always presents its internal VPN certificate when it tries to establish a connection between the client endpoint and the site. The client host does not have this certificate installed.
• The VPN site certificate changed.

Solution

This is expected behavior.

Locally Managed Quantum Spark (SMB) appliances do not support internal certificate administration. These appliances always present their own VPN certificate, even if there are other certificates installed on the appliances.

Note - You can verify the internal certificate in the appliance WebUI: Device > Certificates (Internal Certificate). This page shows two certificates: Internal CA Certificate and Internal VPN Certificate. 

They speak of local managed gateways, what about this gateway?

[aMatthew]

Hi lesley,

I don't know if I explained myself well , I try to clarify:

Until a few weeks ago we had a third-party certificate that worked for both the web portal (port 4434) and the RA VPN (port 443) .
When we renewed the certificate if we connect to example.com:4434 the expiration date is correct. If we connect to https://example.com it keeps giving us the old expiration date.

[Lesley]

So it is central or local management what steps or guide you have followed? 

[Ted_Serreyn]

I have seen this multiple time with renewal of third party certificates and was just about to open a ticket on this.  The main portal on 4434 uses the new certificate successfully, but the SSL portal still used the old (expired) certificate.  The only work around I have found is to undo the certificate, turn off the SSL, reboot the box, then re-install the new certificate and turn ssl portal back on.

I believe that this is a problem where the ssl portal is storing this certificate elsewhere and it is not being updated when the ssl certificate is updated.

Given the amount of time that we have all been using SSL certificates, you would think that these cert renewals would be straight forward by now and update correctly.

[PhoneBoy]

Just to clarify, you mean the SNX portal, correct?

[aMatthew]

Hi PhoneBoy,

thanks for the comment.

the problem was solved by the TAC after a long analysis.

We deleted some files and references of the old certificate via CLI. In these days I will try to publish the solution .

thank you all for your time .

[Ted_Serreyn]

technically yes, but not how it is displayed or labeled on a 1500 series box running R81.10.10 or later.

[PhoneBoy]

Would be “SSL VPN” in that screenshot.
Had the SNX Portal on my mind for a different thread 😉

[aMatthew]

Hi Ted ,

thanks for the comment.

the problem was solved by the TAC after a long analysis.

We deleted some files and references of the old certificate via CLI. In these days I will try to publish the solution .

thank you all for your time .

[aMatthew · Accepted solution]

hi ted,

as already discussed the problem is related to DB corruption.

Although the new certificate is loaded, doing an ssl check still detects the old expiration date.

I solved it this way:

1. Delete $FWDIR/conf/fwauth.NDB.
2. Run 'sfwd_restart'
3. Run 'vpn_configload;fw reconf_sfwd'
4. Add a new local user (it might be a temporary user, just to apply the change),
5. Optional : re-add the 3rd party certificate.

[PhoneBoy]

You can replace step 4 with fw_configload which does a full policy recompile.

[genisis__]

I'm not sure this classes as the same issue, but I've uploaded some external certificates (device and cluster) to spark devices I have in order to replace the default device cert presented for administration over port 4434.  

In the WEBUI its applied. I raised a TAC case, and was a little surprised what they told me, I need to also install the certificate on the client! (I hoping this is just a communication issue).

We are not running any VPNs on these device, and the objective is for the valid certificate to be presented to the client when we attempt to access the WEBUI.