Global Protect config problem: The server certificate is invalid.

[Clermont]

Hello,

we are not able to connect to one of our Gateways anymore. We get the error: The server certificate is invalid.

I checked the following but this looks correct:

• Incorrect time settings on the firewall.
• Check the certificate's validation dates (valid from and valid until) to make sure the date range is correct.
• Check the Time Setting on the firewall. Use NTP if the time stamp isn't accurate.

We have a certificate with an IP adress, no FQDN.

Here is the log of the client:

The Gateway was wortking normally until today.

Anybody that can help me out with this?

[BPry]

@Clermont,

Are you positive that the server certificate is actually valid and wasn't pulled by whoever issued it to you? Do you connect via the IP address or an FQDN that you've configured? 

[Clermont]

Thank you very much for your reply.

The certificate is self issued from our local root-ca.

The local firewall and the portal-firewall show it as valid:

 

We caonnect to the IP-adress, FQDN is not used in this case.

[jarbu]

Did you tried to add this certificate as trusted in portal configuraion? Portal will send this certificate to agent as trusted. It helps a lot if there is an issue with verification of root certificate on client.

Do you have IP address of gateway configured on portal configuration?

[LukeBullimore]

1. If you browse to the GP portal address, do you receive any certificate errors?

1.1 If yes, and this is a publically signed certificate, there is an issue with the certificate chain. From the screenshot you sent there is only one root certificate, when I would expect one more, the intermediate certificate.

1.2 If yes, and its a self signed certificate, no issue we will get to this next.

2. The common name of the certificate needs to match the IP address of the GP gateway as specified in Network -> Portals -> Portal name -> Agent -> Agent name -> External/internal -> Gateways -> "IP Address"

3. If yes to 1.2 then you can get the GP client to automatically import the root certificates to the machines trusted root store as per the below configuration. However as per point 1.1 I believe not all root certificates are present on the firewall.

Network -> Portals -> Portal name -> Agent -> Trusted Root CA

Select the boxes "Install in Local Root Certificate Store"

Thanks,

Luke.

[Clermont]

Hello,

Thank you for the advice. Can you tell me please where I can find ths point (add this certificate as trusted in portal configuraion)?

Is it unbder Network --> Global Protect --> Portals --> <Portal_Name> (GlobalProtect Portal Configuration) --> Agent  ?

I'm sorry, I'm not that familier with the GlobalProtect Configuration, because I have not setup iut by myself

In the portal configuration we use the IP-adress  (not FQDN)

[LukeBullimore]

Hi.

This step is only necessary if the certs are self signed. If you check both check boxes "Install in Local Root Certificate Store" the GP client will install the certs in the trusted root CA store so the client trusts the certs.

Are your certs publically signed? If yes, this isn''t necessary. If you browse to GP portal do you get cert errors? If yes there is something wrong with chain.

Thanks,

Luke.

[Clermont]

Hello Luke, thank you for your reply.

1. On the GP portal website we get a warning (issuer of the certificate is unknown). But this is always happening and there are no problems with GP gateways in other locations wich are also configured with this portal.

1.1 That is correct. It was just filtered out. Here a screenshot with all certificates of the gw:

2. IP and CN are exactly the same. It was working with this configuration over months without problems before.

3. I will activate this setting and check again

[LukeBullimore]

Hi,

There is definitely something wrong with the certificate chain. The primary certificate looks to be signed by the root CA and not the intermediate. The primary certificate also marked as "certificate authority".

What I would expect

Root CA (Common name can be anything), marked as Certificate Authority

Intermediate CA (Common name can be anything), marked as Certificate Authority, signed by root CA

Primary Certificate (Common name is IP address), not marked as Certificate Authority, signed by intermediate CA.

Then attach the primary certificate to a SSL/TLS profile; attach this profile to the "authentication" tab of any relevant portals and gateways.

Thanks,

Luke.

[Clermont]

Hello,

the strange thing is that it was wortking with this configuration for a long time before.

We have other similar configured gateways, that are still working now without this issue:

Here an example from another gw.