Using corporate wildcard certificate for Global Protect

[MichaelMedwid]

To get up and running with GP I set things up with a locally generated a root cert on the PAN and then generated a server cert tied to the root cert. The server certificate used the IP address of the outside interface as the Common Name. Then I created an SSL profile which pointed to the server certificate. 

Everything works well although it has the initial error to push through about the certificate when using GP. Now I'd like to use our corporate wildcard certificate instead of the locally generated one. So say we're acme.com and we have *.acme.com certificate. How do I add that to the SSL profile and GP portal and gateway such that GP gives no error when trying to connect? I tried just importing the wildcard cert and selecting that into the SSL Profile and I got errors with the GP client. So I must be missing something. 

Thanks.

[Mick_Ball]

what error do you get when you browse https:// to your portal address?

If you still get a certificate error then use this tool...

https://www.ssllabs.com/ssltest/

 paste your portal address into the hostname field for the test.

[MichaelMedwid]

This morning I'm getting Certificate name mismatch if I put the name gp.acme.com in at the SSL checker site you listed or in Global Protect. 

At this point if I enter the IP address GP successfully logs in without a cert error. Although if my users went in for the first time I think they'd have to click through an initial error about untrusted or unverified site. 

I am seeing the error message below which may or may not be related. I connect successfully w GP but I see..

"The network connection is unreliable and GlobalProtect reconnected using an alternate method. You may experience slowness when accessing the internet or business applications."

[Mick_Ball]

what happens when you browse to the portal, if it allows you to continue then find out what the certificate name mismatch actually is.

is this a self signed certificate ?   are you sure it's a wildcard?  and are you sure you have applied it to the correct ssl/tls service profile and removed all others...   and also make sure the portal is using it.

cant think what else could be the problem....   as we just do the same when we change or renew...

[MichaelMedwid]

If I browse to the portal by name or by IP I get:

"Your connection is not private" - from there I can proceed and I see the login screen. 
If I put in credentials I will see the screen where I can download the GP client/agent. 

The certificates that are currently in play were generated locally on the PAN - both

the CA cert and the server cert which points to it. The server cert common name is

the IP address of the public interface which had been recommended in one of 

the tutorials I watched and which did let me get things going.

Can you clarify "we do the same"? You use a locally generated cert pair? Thanks!

[Mick_Ball]

so when you are here.....

"If I put in credentials I will see the screen where I can download the GP client/agent. "

select the padlock in the browser address  window to view the certificate.

find out who it is issued to or the subject.

Our wildcard certs are not locally generated so cannot advise on best option, what document did you follow for wildcard self signed certificate.

[Mick_Ball]

@MichaelMedwid 

Just as a side note here...    

I was messing with self signed wild card to see how i would do the same and when i added the new cert to the ssl profile I was also getting CN name mismatch.  I found that i had not changed the ssl/tls service profile for the gateway with the same ip address.   this may be the same issue for you.

[MichaelMedwid]

I had another case open with PAN TAC but they helped me on this too. We ended up creating an intermediate cert off the local generated root cert and a server cert off of that. The server cert had the CN of the name of the gateway and an attribute with the IP address. This is working for the Global Protect client. Though I should go back and and try test more from scratch. I'm not sure why the intermediate cert was needed in this instance.

[Mick_Ball · Accepted solution]

OK glad you got this sorted, perhaps some corruption with cert generation first time round but clutching at straws really,,,

the process for me...

generate a self signed cert with CN of interface IP and select CA.box

generate another cert with CN of *.fred.com and signed by first CA and also select CA box  for this.

simply shoved *.fred.com into ssl profile and put first cert into user trusted store.

Perhaps update on your next attempt from scratch...