Importing a WildCard SSL to use with GlobalProtect

[Jasoncull365]

Hi All,

Im trying to import a WildCard SSL to use for our Palo Alto GlobalProtect VPN. Im Having some trouble as this is my first time using SSL. I can import the WildCard but im not able to link it to its Root CA (GoDaddy). Do i have to have this signed by the CA before using it? We have also added an (A) hostname e.g. example.companyname.com.au, do I have to update the wildCard's subject name with this? Any input will be much appreciated.

Thanks

[Mick_Ball]

i'm not too goood with ssl stuff as new to it myself so perhaps someone will jump in with a solution. However...

we do use wildcard certs and have had no issues.

can i assume you requested the wildcard cert from godaddy and what is the subject? is it *.companyname.com.au

[Remo]

Hi @Jasoncull365

Yes, your certificate (the public key) needs to be signed by a public CA, GoDaddy in your case. If you're going to buy a wildcard cert then there is no need to add additional FQDN's to the cert as the wildcard cert will enable authenticated communication to *.companyname.com.au.

As soon as you have the signed cert, you need to upload it and also the private key to your firewall. In addition to that you also need to upload the GoDaddy intermediate CA cert to the firewall (and if there are more intermediates between your wildcard cert and the root you also have to upload them). This way the firewall is able to build ther certificate path up to the root CA. In addition, uploading the intermediate CA certs, will tell the firewall which certificates need to be sent in the TLS handshake to a client. The sending of the additional certs to the client is needed that also it will be able to build the certificate path up to the root (the client normally only has the root CA cert in his trust store, but not the intermediate CA certs) and can verify the identity of your certificate - without this verification the clients will see a certificate warning in their browsers.

Your wildcard cert then needs to be added to a SSL/TLS profilw, which you then could reference in the global protect gateway and portal configuration.

Hope this helps a little.

Regards,

Remo

[gwesson · Accepted solution]

When you're doing the import, you'll want to make sure that your install is for the full chain. Check out this guide I wrote a few years ago that may help:

https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Install-a-Chained-Certificate-Signed...

As for your certificate's CN, it depends on how many hostnames you've put. In a wildcard cert, each *. is a literal period. So if you have:

*.example.com.au

Then you can make anything with a single hostname that ends in that, such as:

site.example.com.au

secure.example.com.au

vpn-gp.example.com.au

But if you were trying to go 2 levels deep, that would require an additional set of *. in your wildcard, such as:

my.site.example.com.au

this.is.too.many.example.com.au

Cheers,

Greg Wesson

[Remo]

@Jasoncull365

In case you have the cert as pfx (PKCS#12) -> these files contain (in most cases) already all required certificates, so before you start with converting thw file into .pem and build the chain manually, you could simply try it with that. 

If you need to convert something, here are some useful commands for openssl: https://www.sslshopper.com/ssl-converter.html

@gwesson

Is this step still needed or is PA now (for example with PAN-OS 😎 intelligent enough to build the chain automatically when you import the intermediates to the PA certificates? I don't really know, because I had to build the chain only once manually. But this was back at PAN-OS 6.0 I think. And in addition, even if I only added the intermediate certs PA also automatically sent the Root CA cert also in the TLS handshake (what it still does).

[gwesson]

@Remo Yep, still needed. A lot of vendors (GoDaddy, Symmantec, etc.) will send you an already-combined chain cert, but sometimes they put the wrong certs in those or they're in the wrong order.

The firewall can show you the relationship, but unless you follow the procedure linked then that relationship is only in the UI and doesn't affect how the firewall sends the cert when making a connection.