NET::ERR_CERT_COMMON_NAME_INVALID GAIA Portal.

[LazarusG]

Hi

A customer has a requirement to prevent this message from appearing when accessing GAIA.

I am aware of  sk174383.

However I have explained that this certificate is generated automatically by the system and pragmatically the fact that you trust the Checkpoint ICA, and all certificates signed by it, should be sufficient to mitigate any concerns.

The customer could generate a CSR and submit to an internal PKI I guess as per sk69660.

But that's quite a lot of work to do per gateway (they have a large estate) and every time the certificate expires.

The customer also has no internal PKI and I see no reason why they should pay for third party certificates just so a malicious user would trust the certificate chain.

I also suggested they export the certificate chain and push out by GPO but this will still likely get picked up by external scans and tests.

So my question is: is there any way to influence the behaviour of the SAN via the built in ICA to avoid this problem going forwards?

Is this something that is being looked at for upcoming JHF?

Am I just being dumb and missing something obvious? 🙂

Any Input would be appreciated - thanks!

[the_rock]

I dont think you are missing anything, that sk seems valid for the issue they have. Just curious, does it make any difference if they try private browser window?

Andy

[LazarusG]

Hi unfortunately not and it seems exporting the ICA cert and importing to the Root Certificate store on the PC doesn't solve the issue (even if the appliance gaia cert is also imported into Personal and the chain is shown as OK in mmc).

[PhoneBoy]

The certificate for the Gaia portal is not generated via the ICA.
There appears to be a procedure to add information to the SAN for the Gaia Portal Certificate in sk97648, but the SK is internal.
Please consult with TAC: https://help.checkpoint.com 

[LazarusG]

Thanks Phone boy, Can I clarify on the signing? I just exported the gateway cert from the Gaia browser and added it to personal store but it was shown as untrusted. I then exported the ICA cert from Smartconsole and imported to root store and now the certificate chain is shown as ok.

I will maybe engage TAC but if customers will have requirements to address this browser warning it would be good if it was something we could influence easily (or automatically in the system without effort on customer part).

I just found sk181410 which looks like this would address the issue (?) still seems like a lot of effort for something that 'isn't' broken just to make a browser happy.

##update although I didn't get this Phoneboy so apologies (I thought the appliance gaia cert was chained)
sk181410
"Note - Each Gaia OS has a unique self-signed certificate"

##Update again = ok so I was confused, when a firewall is built it has a self signed cert, but if you enable VPN blade and push policy the gai cert becomes the vpn cert - which is signed by the ICA.

So it seems we need to follow sk181410 to generate new self signed certs that satisfy the browser CN/SAN requirements - and/or renew the vpn cert with additional criteria? 

[the_rock]

Maybe TAC case is not a bad idea, just to confirm the steps, but sounds logical to me.

Andy

[LazarusG]

looks like sk181410 made the mgmt server agreeable to the browser.

Then adding the ICA cert and vpn gateway cert to the trusted and personal store made the vpn gateway ok too

[the_rock]

That fixed it?

[PhoneBoy]

sk181410 looks like the correct procedure in this case, yes.