topic Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname in SASE and Remote Access

Changing Checkpoint Mobile Desktop Client wildcard Hostname

NorthernNetGuy — Fri, 12 Oct 2018 11:55:57 GMT

We use a wildcard for our mobile blade platform portal, which is also used for the desktop client. The platform portal is working correctly and has the correct hostname selected.

The desktop client gets a certificate error, saying the site is presenting itself as the wildcard instead of the proper hostname

"The site presents itself as *.domain.xxx and not as mobile.domain.xxx"

How do I get this hostname to match up?

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

PhoneBoy — Sat, 13 Oct 2018 09:03:17 GMT

Is it a certificate error or?

A screenshot (with information obscured if needed) would be helpful.

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

NorthernNetGuy — Mon, 15 Oct 2018 14:37:04 GMT

Here is what displays. I opened a ticket with support, who said this is expected and that wildcards can work if you trust them manually for each first connection, but the Mobile client doesn't fully support wildcards in this format.

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

PhoneBoy — Mon, 15 Oct 2018 16:37:43 GMT

So are you saying the Mobile client never trusts it, even if you manually accept it the first time?

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

NorthernNetGuy — Mon, 15 Oct 2018 16:53:57 GMT

It does trust it after we manually accept it.

Ideally the endpoint client would recognize the wildcard and apply it to the expected hostname.

Seeing an error like this causes concern for many of our users, which bogs down our helpdesk with calls even if we try to inform our users that it is okay to trust and continue.

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

PhoneBoy — Mon, 15 Oct 2018 17:22:28 GMT

Understood.

I'm guessing this is expected behavior but will ask the experts to confirm

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

NorthernNetGuy — Mon, 15 Oct 2018 17:42:06 GMT

According to the TAC rep I had it is expected behaviour, but an RFE has been created to have the mobile client better support wildcards.

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

PhoneBoy — Fri, 26 Oct 2018 23:02:38 GMT

Is the site's FDQN specified as part of the SAN of the certificate?

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

NorthernNetGuy — Mon, 29 Oct 2018 13:12:29 GMT

No, as this is a wildcard cert and not a SAN cert.

Wildcard certs will just contain *.domain.com and domain.com as the SANs. You never see it contain further subdomains.

You'll sometimes see a Wildcard SAN cert that contains multiple domains such as *.domain.com , *.domain2.com, and, but again, no subdomains. (yahoo cert is a good example)

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

Chris_Butler — Mon, 29 Oct 2018 13:55:05 GMT

My firm has a wildcard cert with Digicert, and we can request free duplicates with up to 10 SANS per duplicate, the SANs can be individually specified FQDNs of subdomain hosts, i.e. the (obfuscated) wildcard cert is :

*.contoso.com

matches

<AnyHostname>.contoso.com

contoso.com

But you can specify up to 10 SANs on a given duplicate which could cover:

ethernetswitch1.corp.contoso.com

mail01.corp.contoso.com

etc.

It works beautifully for us, allowing all our internal device management and printer web management etc etc to work without certificate errors, and it saved us a TON of money.

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

NorthernNetGuy — Mon, 29 Oct 2018 14:01:16 GMT

I'll see if I can add a SAN that is covered by the wildcard onto the wildcard, but this still seems to be a problem with the Mobile Client.

*.domain.com should match with <anyhostname>.domain.com. However the Checkpoint Mobile Client errors when it sees this, and does not recognize a match.

Re: Changing Checkpoint Mobile Desktop Client wildcard Hostname

Chris_Butler — Thu, 08 Nov 2018 15:09:36 GMT

Hi David,

I have gotten it to work, and I will have a write-up posted on another thread here which shows the most direct and efficient way to do it as far as I have found.

TAC pointed me toward this SK.

How to generate Server Certificate Signing Request (CSR) and import the new 3rd Party certificate to Mobile Access Blade

There are two command line examples there in stage one, they are not two steps. That bit me because I did the steps without reading ahead. You want to use the second example, as nobody is supporting 1024bit signing anymore

====================================
To Generate the 2048 bit CSR please use below command:
[Expert@GW]# cpopenssl req -new -newkey rsa:2048 -out <CERT.CSR> -keyout <KEYFILE.KEY> -config $CPDIR/conf/openssl.cnf
====================================

Bottom line, when you use the cpopenssl command to generate the CSR and the KEY files, it will prompt you for a few attributes; put the FQDN of the host in as the CN when it asks you for it.

When you go to your CA they usually have a field where you can add SANs when you request a duplicate, put that FQDN hostname in as one of them, and that is half the battle.

My write up will cover the whole generation and import process, stay tuned.

Note, there is a significant delay after importing the finished cert, publishing the changes, and installing the policy.

I am not sure if the gateway waits for a window before the new cert becomes internet facing, but in my case it was more than 10 minutes. I did not restart any services to get it to happen, either.