The site's security certificate is not trusted! after renewing portal certificate.

[JorgenSpange]

Hi!

A couple of days ago I renewed the officially signed certificate for remote access vpn (Mobile access -> Portal Settings -> Certificate). 
After this the user was prompted with this:

When clicking details it says the following:

"The follow security risks were discovered:

-The site's fingerprint has changed from the original one.
-The site presents itself as xx.yy.com and not as 1.1.1.1"

I've made sure that the vpn site is setup on the client with dns name and also made sure that the root ca for entrust in the trust store on the client.

My question is the following: Is there any way to not get this prompt after renewing the certificate? My thought is that you should not learn your users to press "trust and continue" on this message, if that one day an attacker is the one changing the cert.
Wouldn't this prompt be the same as if you got prompted with a certificate warning whenever facebook or chekpoint renews their ssl certificates?

Hope to hear from you!

br
Jørgen

[the_rock]

I dont believe its possible not to get this...its same if user creates brand new VPN site, they will always see this warning, but only ONCE. After that, they should never get it.

[JorgenSpange]

Thank's for the response.
But I have to admit that it does not make sense for me, we have to renew our certificate every 12 months, this means that the user will be prompted with this once a year.
If a malicious actor would've replace the certificate for a mitm attack the users will already be learned up to click yes and continue their work.

[the_rock]

Maybe others can confirm 100%, but I am pretty certain it is expected behavior. I do agree with you, thats very true what you said, but at the same time, while its absolutely true that literally no end user will even pay attention to that message, its there for a reason and thats to make sure fingerprint matches with whats on gateway side.

[JorgenSpange]

I understand, but what does not make sense is that the users that were logged in during the renewal was not prompted with this message.

[the_rock]

I believe thats expected as well...while users are logged in, they would not see that pop-up.

[JorgenSpange]

Really seems like there is no way around this then... I guess we will have to warn our users once a year that this will appear.

[the_rock]

Dont give up yet...there might be a way around it. lets see if someone might have an idea.

[syedfahad1]

This is possible that user will not get any popup after certificate is renewed, for this we need to add the certificate fingerprint in the user machine registry, or at mass level get it rolled out using gpo policy.

remember dont remove the existing cert fingerprint from the user machine but under string variable add another cert fingerprint using ;

ex: fingerprint of cert1;fingerprint of cert2

Peace 🙂  

[freshwater84]

Hi together,

I am also first year renewing offical Wildcard Certificate on our R82 cluster.
Now I am wondering, what is really the recommended way for

• CheckPoint Mobile VPN Client
• with existing SSL Dial-In VPN profile (hitting on host.customer.tld)

SSL certificates get shorter and shorter lifetime, and by standard I see the DefaultCert set-upped on new Gateways
Well, the DefaultCert also has to be renewed once a year (until now), but at least not every 200 days for now

What is the best way, to avoid the warnings, if I switch my Wildcard SSL Certificate to eiter

• a new Wildcar SSL Certificate
• back to the Default Cert, which will be also renewed once a year, if I understood right

Does it make sense to Export the DefaultCert and distribute it via GPO (and if, under which Windows Certificate Section, the client will take it from, and bring no warning)?

[ccsjnw]

If you use the DefaultCert, your users will still receive the same Fingerprint warning once per year, when the internal DefaultCert auto-renews. So it’s not a solution to the problem.

[freshwater84]

I see, but with official Wildcard Cert (from offical external CA) that warning also comes, or not?
Would be sk66263 a solution?
Distributing with DefaultCert, exporting RegKey, and at least distribute it to the internal Computers?
Or how is the regular way with that?

[PhoneBoy]

Whatever certificate you use, you will have to deal with certificate expiration warnings.
And, in general, we plan to make this easier in the future: https://support.checkpoint.com/results/sk/sk184604 

[freshwater84]

Hi PhoneBoy,

Thanks a lot for that information. I am asking (including LocalOffices) already around since 1 year.
That means, practically it's the best to use the DefaultCert, because warning comes anyway once per new certificate?
And if we want to not see the warning, connect once and deploy the RegExport like described in sk66263?

DefaultCert remains (for now) still valid for 1 year, or is it planned, that this will be reduced too already? (last DefaultCerts I generated were still valid 1 year...)

[PhoneBoy]

Yes, adding the fingerprint to the registry per sk66263 should suppress the warnings.
At some point, it's possible we may adjust the lifetime of ICA-generated certificates.
Not aware of any specific plans in the near term to do it, though.

[Chris_Atkinson]

Please review sk66263 and see if it helps with your situation.

[JorgenSpange]

Thanks!

But from my point of view this seems like and incredible task?

As soon as you change the registry, the client will have wrong finger print for the current certificate.
You dont know the fingerprint for the new cert until you change it in management.
This means that all clients have to be online between cert change and policy push, so that you can push the registry setting.
If not the clients that were offline will not get the registry change and will be prompted either way.

So I think we still would have the same issue with this, at least to some extent.

[the_rock]

Maybe someone from R&D sees this post and replies, because you do bring up a very good point. I agree with you 100%.

[JorgenSpange]

Thanks, lets hope so!

[JozkoMrkvicka]

End users should be able to verify the fingerprint visible within that pop-up. IT admins should be able to provide it to all users in order to confirm that they are really connecting to the correct gateway with correct fingerprint.

You can somehow try to open some web page (internal over intranet) where all fingerprints will be stored for comparison.

Or store all fingerprints on user's desktop, as text file, and replace it everytime you change the certificate or fingerprint is changed for whatever reason.

[JorgenSpange]

Seems like a poor user experience especially given that our user base consist of production workers with next to none IT competence, would be a rough job for our servicedesk.

Thanks!

Br

[JorgenSpange]

Did some more testing on this now, seems like you can just delete the "accepted_cn" key. It does not give you the prompt whenever it does not have a finger print already stored.

Seems like the vpn client does not care about the certificate being verified by trusted CA or not.
Tested by deleting the entrust root and intermediate ca from the trust store on the machine and the client did not care.

With this to our knowledge we could evne discuss that it would be better security to have self-signed certificate with 100 year expiration time, so that we don't learn our users to click okey on certificate errors.
But as long as the address is available from the internet we of course want an officially signed cert.

Not trying to be difficult, but I find it weird that such a big vendor does not have a solution for this 🙂

Br

[the_rock]

I dont think you are difficult at all. I agree with you 100%. Though, I will say this...yes, it might be difficult for users, BUT, Check Point is security company, so better safe than sorry, right?

[JorgenSpange]

Good to hear. Yeah I agree, and that's why I find it weird that the Check Point vpn client does not care about trusted CA, only the fingerprint.

[the_rock]

No argument there my friend. If I were you, personally, I would definitely get an official TAC case, so that way users can get vendor's answer as well.

[JorgenSpange]

Received a reply from TAC today:

"My name is Gil, I will be assisting you throughout this ticket.

I've noticed that sk66263 was already suggested to Jorgen at the CheckMates thread.
That is indeed the answer I would have given out as well.

As for the fact that the client cares about fingerprint only - that is true but only after the client has saved its first fingerprint to the registry.
But at the very first connection by the client when it is first installed, the registry is empty, and then it does consider factors such as Subject and Issuer.

The whole point of the fingerprint being stored at the registry is so that the client will "remember" the decision to trust that certificate and won't keep pestering the user to approve the cert again or not.

From that point, if a new certificate is presented to the client, it will NOT trust the certificate regardless if all its fields are legit - and the reason will be that the fingerprint is different than what it "remembers".


Now about distributing the fingerprints via GPO - even if users are offline, is it not possible to "queue" the push until they are online?

Remember that indeed you will know what fingerprint to push after you renew the certificate in the MGMT server, but it won't actually be replaced until the policy is pushed, giving you some time to prepare.

Additionally, once you have the new fingerprint in hand, the employees can be updated via email that should they see the "trust" message with the mentioned fingerprint, it's fine to approve it.


Hope this helps a little!
Please let me know if you have further questions.

BR,
Gil Fridman"

[Tobias_Moritz]

From my expirience (its a little aged), I can tell you that you will get this prompt green instead of red, when the certificate is valid (matches the FQDN of the site e.g) and the cert chain is trusted by Client OS.

But you will get the prompt.

You were wondering, why you did not get the prompt again after deleting the trust fingerprint from the registry key mentioned in sk66263. I think this is because the trust is also written to trac.conf. Deobfuscate this file (I guess you know how) and you will find something like this in it:

<PARAM ccc_fingerprint="KING MOST FIVE CLOG LOP TONY LENT CAKE MAC RECK ROY GLUM"></PARAM>

This is the RfC#1751 encoded representation of the SHA-1 fingerprint of the Root-CA of the certificate used for this portal (platform portal for legacy IP-Sec-VPN blade only, Mobile Access Blade Portal for MOB). Please verify this. Sometimes, it seems to be the fingerprint from intermediate instead of root CA.
If this fingerprint changes, there is popup for your users. This means renewals of portal cert do not trigger popups for users, when the CA cert keeps the same. Of course, also CA cert expires eventually. This reduces your problem a little.

<PARAM internal_ca_fingerprint="TELL ACE RUB SANK JUNK ARE ROOT LEO ANA VOID POD MOVE"></PARAM>

This is the RfC#1751 encoded representation of the SHA-1 fingerprint of the certificate configured in SmartConsole -> IPSec-VPN .
Changing this cert does not seem to trigger a user popup. Warning: This expirience was from an environment without MOB, only Legacy IPSec-VPN blade for Remote Access with Endpoint Security VPN client.

[JorgenSpange]

Hi,

Getting a green prompt would atleast be much better, the cert we're using has full cert-chain and is fqdn and root ca from entrust is in the trust store on the client so I would assume that the cert is ship shape.

But your input is very valuable, if you could add the fingerprint of the intermediate CA instead, that would be a huge mitigation in consideration of the prompt.

Br

[the_rock]

Very logical point!!

[syedfahad1]

Check my reply above I gave you the solution.