Feature Request: Do Not Require Machine Certs to be Imported on the Firewall

[tszafalowicz]

For some background: We recently impelmented a data protection strategy within our organization and would like to restrict the Global Protect remote access VPN service only to domain-joined laptops.  Since all our endpoints within our environment receive a machine certificate signed by our Internal PKI Root CA, we wanted to leverage those certificates to validate domain membership.  I have our Trusted Root CA certificate (and key) imported on the firewall and leveraged that in a Certificate Profile.

After a failed implementation and a 4-hour support call with Palo, TAC determined that either A) the certificates need to be generated on the firewall or B) the machine certificates (all of them) need to be imported into the firewall.

For obvious reasons, managing all our domain's machine certificates for external laptops on the firewall is not feasible.  We've explored implementing a SCEP server in the past, but had nothing but issues.  This leaves us with generating the Root CA and generic machine certificate on the firewall and then having to deploy those to all the endpoints, rather than using existing certificates that are machine-specific.

It would be helpful if Palo Alto leveraged the benefits of PKI and a chain of trust and only required the Root CA certificate to be on the firewall and approve any certificates signed by it.

[Remo]

Hi @tszafalowicz 

---

@tszafalowicz wrote:

I have our Trusted Root CA certificate (and key) imported on the firewall and leveraged that inAfter a failed implementation and a 4-hour support call with Palo, TAC determined that either A) the certificates need to be generated on the firewall or B) the machine certificates (all of them) need to be imported into the firewall.

---

Wait? ... What???

If this is what TAC told you then this is A) totally wrong or B) I don't understand what you are trying to do.

I can only speak about what I have done since years: I have never even imported a private key for global protect client cert authentication. For this only the cert is needed and this works for me since years. Our certs are managed by an internal PKI (not on a PaloAlto firewall) - probably like yours.

Are there some special requirements in your infrastructure with these certificates? As I wrote, normally this works like you have described it and is also how it is supposed to work.

Regards,

Remo

PS: Feature Request need to be created by telling this to your SE. Here kn the community you cannot ask for feature requests.

[tszafalowicz]

Hi Remo,

Thanks for your feedback and input!  "Wait? ... What?" was my exact reaction when I was informed that by TAC.  I did also immediately reach out to our SE after the implementation failed and got off the phone with TAC.  He was stumped as well and he was under the impression our implementation strategy would work, just like me.

No advanced use case here; just simply looking for a certificate that is signed by our internal PKI CA.  If the certificate is found, we can safely assume that the endpoint is a domain-joined asset and allow it access to connect to the GlobalProtect Gateway.  No certificate, no access.

Interestingly enough, when I generate the certificates on the firewall, specify the CA certificate in a certificate profile and test like this, it works as you would expect it to work with our own certificates.

So maybe the issue is with our own PKI?  Still stumped with this one.  TAC did inspect the certificates we were trying to use for this while on the call and determined they are valid as well.  Confused on this.

Thanks,
Troy

[Mick_Ball]

To confirm, as posted by @Remo and your own suspicions....  this does work so yes i would imagine its a PKI issue.

i was gong to suggest check subject names etc in cert profile but if it works with self signed on palo then seems you have all this covered....

could it be worth just checking that your PKI is rolling out client auth certs and not server certs... probably sucking eggs but the kind of thing that catches me out now and again...