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.

[jerem42]

emnoc wrote:

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

Thank you, I understand. Can you just explain shortly or guide me to understand what's the difference that these sites work in the main browsers if I am on my mobile data plan for example. Thanks!

[mvonhatten]

Are you using proxy-based inspection mode?

[Kevin_Shanus]

How can this make sense?

support.sectigo.com = Old Cert

sectigo.com = New Cert

[aleilmago]

Kevin,

I have already informed Sectigo about support.sectigo.com, but they have replied me that there is no issue:

[...] I don’t see any issue with our certificate. Thank you anyway for your email. [...]).

My idea after that I have informed some owners of the websites with expired certificate: Fortinet should find another solution, because in my personal opinion the owners of the websites will not replace the expired certificate soon.

In fact Sectigo officially writes that it's not mandatory to replace the certificate, because the new browsers/clients are able to "exclude" the expired certificate.

I don't agree with this theory: I replace the expired certificates with valid certificates.

Best.

Alessandro

[aleilmago]

Hi.

Temporary workaround (also if I don't like it): create a new SSL/SSH Inspection profile with "Validation failed certificates" allowed.

I don't like it, but there are too many websites with this expired certificate.

Best.

Alessandro

[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.

[alex_valenzuela]

Is there a way for the firewall to make SSL inspection exceptions for some sites?

this site.. https://sistema.contpaqi.com/loginContpaqi/Login, if I open it on Firefox and check the certificate chains, all are valid.

But when we enable Fortinet SSL inspection it fails...

Its not clear to me, why fortinet is failing some sites, that check ok with firefox, chrome, edge..

[Kevin_Shanus]

alex.valenzuela wrote:

Is there a way for the firewall to make SSL inspection exceptions for some sites?

There are two ways that I know of:

1 - You can create a new IPv4 Policy with SSL Inspection set to no-inspection and for destination put the site addresses you don't want inspected. 

2 - I know with deep packet inspection you can add addresses to the Exempt list in its profile. 

A temporary work around is to select "Allow invalid SSL certificates" under Common Options but I think if we collectively do what SomeDude101 said it will help resolve this problem quicker and properly. 

[Admin_FTNT · Accepted solution]

You may like to check the article at https://kb.fortinet.com/k...amp;externalId=FD49028

[aleg]

The web server admin should not have to replace all certs to fix this problem.  The problem is with the inspection method being performed by the Fortigate.

When these sites/service are accessed _outside_ of an environment using a Fortigate for SSL inspection, they work.  The error message is coming from the Fortigate.

It takes 10 seconds of testing on a mobile phone.  And, maybe 1-2 minutes using https://www.ssllabs.com/ssltest/

There are three paths to roots for each of these leaf Sectigo certs:

[ol]

trusts USERTrust CA root cert from an on-board CA certificate store;

is the 'hard-coded' one followed by using a chained cert with intermediate and root specified.  This path leads to an expired AddTrust root CA cert.

follows the intermediate to USERTrust, and requires an additional download of a new CA cert.[/ol]

We're forced to use proxy-based inspection (because flow-based disables web profile overrides).  So, we will be forced to replace all of the bundled certs with leaf-only.  For normal use (not behind a Fortigate), this is unnecessary because the browser will ignore the expired CA and follow the path to the valid CA.

If you have public servers/services behind a Fortigate, you can disable the SSL inspection on your outbound policy.  This will make the sites accessible to the public again.