User cannot connect to Global protect portal.

[SammiSolmonson]

The error message on this users GP client says they have an issue with they're certificate. The helpdesk apparently installed a certificate but I am not sure which one or where exactly. Now its telling me it cant access the portal at all. I want to doublecheck the user has the correct certificate. I know where the certs are in the palo alto and there are two offered through the GP portal. Although I don't know where the GP client looks for these certs on the client side or if the certs look exactly the same on the client side. Does anyone know?

[Adrian_Jensen]

Depends on how you are using certs and what it is using certificates for. Is this an error that the client doesn't trust the Portal? Or is this an error that the Portal can't confirm the clients certificate for authentication? Certs can be used/pushed in GP in 4 different ways:

1) The client should trust the certificate used to sign the Portal/Gateway communications. This can either be a public CA signed certificate (i.e. an "internet" cert from Verisign, Entrust, LetsEncrypt, etc.) or an internally signed certificate from your internal CA. This check can be overridden in your GP client settings.

2) You can push trusted root and intermediate certificates to clients. This is used for clients to trust internally generated certificates and company root trusts. These are the public-facing certificate chains (public meaning used for authentication of cert signatures, not necessarily valid on the wider internet). You would use this, for instance, to push your internal CAs to clients so they trust your internal certificates, or possibly your Portal/Gateway if you don't use a public CA certificate externally.

3)  You can push a personal certificates to all clients. This is the same certificate pushed across all clients and includes the private key (meaning the cert can be used to sign communication as the cert holder). This can be used to authenticate against the Portal/Gateway but is fairly dangerous as the client now holds the keys to a trusted certificate that is in use/common across all clients (i.e. not revocable to a particular client and if you accidentally push your PA root cert then you have just allowed every client to generate new certificates as your CA).

4) You can request a client identify itself to the Portal/Gateway using a personal identity certificate signed by your CA. This certificate can be a user certificate or a machine certificate. A certificate with a "Client Authentication" purpose assigned. The client configs can be set to allow one of the other.

If the problem is with the client not trusting the Portal/Gateway, then the client most likely has invalid/expired CA chain certificates and can no longer verify the certificate used on the Portal/Gateway. These CA certificates should be in the trusted authority certificate folders (either root or intermediate depending on what it is):

Current User->Trusted Root Certification Authorities->Certificates

Current User->Intermediate Certification Authorities->Certificates

Local Computer->Trusted Root Certification Authorities->Certificates

Local Computer->Intermediate Certification Authorities->Certificates

If you are using client certificates to authenticate user VPNs, then the Authentication tab for the Portal/Gateway should have a Certificate Profile assigned to it. This certificate profile should list the root/intermediate CAs that are valid to sign a user connection. The GP user should have a valid client authentication certificate signed by one of these CAs, in either their user or machine certificate stores:

Current User->Personal->Certificates

Local Computer->Personal->Certificates

I use user certificate authentication on the Portal as it simplifies several connection issues. But if the user machine hasn't connected for months, or your AD is not refreshing certificates before expiry, it is not uncommon to have the client certificate expire. At that point you need to either manually push a new certificate to the client, or have the client go to an alternative Portal that doesn't require a certificate.