Changing Checkpoint Mobile Desktop Client wildcard Hostname

[NorthernNetGuy]

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? 

[PhoneBoy]

Is it a certificate error or?

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

[NorthernNetGuy]

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.

[PhoneBoy]

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

[NorthernNetGuy]

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.

[PhoneBoy]

Understood.

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

[NorthernNetGuy]

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.

[PhoneBoy]

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

[NorthernNetGuy]

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)

[Chris_Butler]

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.

[NorthernNetGuy]

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.

[Chris_Butler]

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... 

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.