Troubleshooting Tip: When the browser shows ERR_CERT_AUTHORITY_INVALID from a valid certificate

It is very usual to find websites with a certificate (leaf) issued by an Intermediate CA, and, for example, in this article, they are as follows:

Certificate chain

CA root: GlobalSign.

CA intermediate: GlobalSign GCC R6 AlphaSSL CA 2025.

Leaf Certificate: onlinecompliance.org.

The CA root certificate is the issuer of CA Intermediate, which is the issuer of the leaf Certificate.

It is required to have the CA Intermediate to validate the leaf.

There are some cases where the entire chain (inter. and leaf) is not added to the Web server for many reasons, like reducing the handshake size for TLS negotiation, load balance strategy, or even a missing configuration on the way, as the Web server will present the certificate.

For cases like that (incomplete chain), the browser (client application) checks the extension field 'Authority Information Access' when available, and uses the URI with the source of the CA issuer to properly download the missing intermediate certificate, as shown in the image below:

In the specific case of this article, because of the company policy, it is forbidden to allow HTTP on the traffic (it is possible to see many TCP connection attempts on the port 80, but without answer - SYN/ACK), but the URI to download the certificate will always use HTTP.

To fix this situation and remain secure, it is just necessary to add a policy with the specific FQDN from the field and define the service to use HTTP as shown below:

policy

From CLI:

config firewall address     edit "secure.globalsign.com"         set type fqdn         set fqdn "secure.globalsign.com"     next end ------------------------------- config firewall policy     edit 3         set name "Allow_Intermediate"         set srcintf "port3"         set dstintf "port2"         set action accept         set srcaddr "port3 address"         set dstaddr "secure.globalsign.com"         set schedule "always"         set service "HTTP"         set logtraffic all         set nat enable     next end

After adding the policy as above, it is possible to follow the traffic from Wireshark, which shows the TCP handshake being established and the 'crt' file download with the command get, as highlighted in the image:

chain download

Reference:

It is possible to check if the certificate is presented with the chain already using the tool below:

SSL Server Test: onlinecompliance.org