Sudden HTTPS certificate errors - Sectigo AddTrust External CA Root Expiring May 30, 2020

[jerem42]

Hi, I have a FortiGate 50E running v6.2.4build1112 The following issue occurs with different browers (FF, Chrome, Safari) and also on different platforms (Win,OSX,iOS,Android) For the last 24h I have suddently started receiving certifiacte errors on various websites which have worked flawlessly before. I get the typical HTTPS warning in my Browser (e.g. "Your connection is not private" in Chrome) and the exact error message is "NET::ERR_CERT_AUTHORITY_INVALID". Interestingly if I look at the certificate details it shows "Fortinet Untrusted CA" as the issuer. If I access these sites via mobile data these pages work fine and also the issuer is shown as a know institution (in all cases noticed so far it's "Sectigo"). In the SSL Logs I see "blocked" actions for the respective website: Message: Server certificate blocked Reason:    block-cert-invalid Type:    utm Sub Type:    ssl Event Type:    ssl-anomalies These actions are triggered by the Standard FortiGate pre-configured SSL/SSH Inspection profile "certificate-inspection" (SSL handshake inspection.) Any ideas what could be the reason for this sudden new behavior or how I could trouble shoot? Thanks in advance for any help!

[emnoc · Accepted solution]

To repeat what was said earlier

"The problem is that those websites have an expired certificate in their chain (expired on May 30)."

Use ssllab to verify the cert on the web-server. If the cert is expired nothing you can do can get pass that issue. It does NOT matter that you have the cert of the CAs or webserver

https://www.ssllabs.com/ssltest/

If you would like to paste the name of the site we would gladly check for you.

Ken Felix

[SomeDude101 · Accepted solution]

I just registered for an account so that I could weigh in here. I'm actually not a Fortigate customer but I'm using a competing product with SSL inspection and I've been battling this same problem all day. If you're doing SSL inspection and you care about the integrity of website security the only way to correct this is to contact website owners. I've been doing this all day and successfully resolved the issue with many websites. I provide the website owners with a Qualys SSL Server Test report showing the expired certificates, explain the problem it's causing, and kindling request that they remove the expired certificates from their certificate chain. Removing the expired certificates form the chain resolves the issue and causes no detriment that I can see.

[unknown1020]

Friend I am having the same problem with access to other pages but the certificate expires in 2024.

[sysinit]

Hi!

I am new to Fortinet, but with other vendors you simply delete or at least deactivate the expired root certificate from the firewall, so that another certificate chain path is chosen. But on my FortiGate, I only can see a very short list of locally installed certificates, so I am not sure if there is at all the possibility to influence the used root certificates in any way.

Kind regards,

Daniel

[sysinit]

Hi!

These certificates are are signed by an Intermediate CA that by itself is signed by multiple Root CAs, one really old ("AddTrust External CA Root", the one that has expired) to be compatible with old devices, and by a current one ("USERTrust RSA Certification Authority"), known by up-to-date devices. So the "solution" to this problem is to discard the really old CA and instead use the certification path to the current Root CA, which is perfectly fine. This is what browsers do and what is possible with other firewall vendors.

Best regards,

Daniel

[lakshman]

This issue happening in 6.2.x ver.  Untrusted SSL cert blocked by default. Try to create a new SSL inspection policy where you can exempt the website temporarily or allow an untrusted SSL certificate in GUI. 

If I am wrong   - correct me

[mcdaniels]

Hi,

well I did not get the point. In my opinion this is a problem of an outdated certificate in the certchain of some websites. (using Sectigo's legacy AddTrust External CA Root certificate).

I may be wrong, cause I am no expert in this, but the fortigate reacts correct to this issue, as far as I understand right.

Outdated cert -> security issue -> block

for example if you test: https://www.ssllabs.com/ssltest/analyze.html?d=www.post.at

you can see the outdated cert.

The only way to resolve this issue at the moment is to switch to flow mode, or allow invalid ssl certificates in the ssl/ssh protection profiles.

[aleilmago]

Hi.

I agree with mcdaniels.

FortiGate reacts correctly to this issue, because that certificate is expired.

In my opinion it's not useful to check certificates and then permit also the expired ones...

Best.

Alessandro

[lakshman]

I understood but in My case, the certificate not expired.  based on https://www.ssllabs.com/ssltest/   the particular website rated A+. So I tried to exclude the particular FQDN, but I am not able to add to the exempt list in the SSH profile.  

[J13224]

I just ran into this for the first time.  While it is a little fuzzy, I'm not sure what the confusion is on who's responsibility it is.  There is an RFC for TLS, and my understanding; feel free to correct me if I am wrong,  is that the RFC allows a certificate to remain valid even if 1 of multiple chains had an expired certification path.  Every modern web browser and OS behaves this way.  

"Certificate path validation is done client-side from leaf to root. Modern clients that receive Trust Chain A with the cross signed intermediate (see below) from servers should ignore it and instead follow Trust Chain B. This applies even after the root of Trust Chain A expires on May 30, 2020." - Carnegie Mellon Certificate Authority 

So how is this not a Fortigate issue.  It is either compliant behavior or it is not and in this case it appears that Fortigate may not be. 

To clarify: I dont' think some people understand that a certificate can have multiple authentication chains to the CA root.  The path you see in your browser is not necessary the only chain it is just the one the particular OS is using.  In this case COMODO/Sectigo has 3 chains and only 1 of the 3 has expired.  Updating the certificate on the host will resolve the issue but a better long term solution would be for the client end (Fortigate) to update the SSL inspection to comply with the more sophisticated modern accepted behavior.  Or if there was a security concern give the FW administrator an option to manually comply with modern behavior and ignore the default behavior when multiple authentication chains are encountered.

[mcdaniels]

J13224 wrote:

I just ran into this for the first time.  While it is a little fuzzy, I'm not sure what the confusion is on who's responsibility it is.  There is an RFC for TLS, and my understanding; feel free to correct me if I am wrong,  is that the RFC allows a certificate to remain valid even if 1 of multiple chains had an expired certification path.  Every modern web browser and OS behaves this way.  

I am no pro when it comes down to certification-issues. Fortinet-support told me that it is NOT a firewall issue, and the website-owners / webmaster / hoster has to remove the outdated cert. in the chain. I run in this problem quite often. If you have activated SSL logging there are numerous ssl-certification errors (big companies -> microsoft for example...)