Some .gov sites blocked, others are not?

[adder666]

I'm a novice with this, but I have web filters enabled and still having trouble reaching a few government sites, for example www.pittsburghca.gov. But others, like [link]https://www.dmv.ca.gov[/link] work fine. I've explicitly allowed the blocked sites and still same error:

This Connection is Invalid. SSL certificate expired.

A secure connection to www.pittsburgca.gov cannot be established.

When you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.

Sitewww.pittsburgca.govCertificate CNsan-g2.granicusgovaccess.netCertificate AuthorityR3Certificate Validity Not Before: Sep 20 16:46:45 2021 GMT Not After: Dec 19 16:46:44 2021 GMT

What am I missing? And remember, I'm a real novice with the Fortinet equipment (new job, this is what they had in place) so explain to me like I'm a 5 year old. It's a Fortigate 100E with firmware v7.0.1 build0157 (GA). Thanks!

[adder666]

I saw the Let's Encrypt thing after I posted the question. I spent a lot of time trying to get it to work. Unfortunately, the original 4 templates for SSL/SSN (certificate-inspection, custom-deep-inspection, deep-inspection, no-inspection) are the only ones there. I wasn't able to clone the certificate-inspection template, which is the one being used and I can't change it.

I cloned the custom-deep-inspection and tried modifying it to match the certificate-inspection, but must have missed. It screwed up everyone. I was able to go to the .gov sites that were blocked, but it messed up other sites. Might be easier to tell the staff to wait it out.

That or try again with the cloning deep and matching as best I can to the one in use. thanks for all your input everyone!

[adder666]

One more update. So I copied it all and enabled it, broke things again. Like Google was blocked, though others were allowed now. Like the previous City of Pittsburgh, CA site. That was available, but Google wasn't. Not sure what the hell is happening on this device, but it's obvious I need to spend way more time in there learning.

[boneyard]

found this one today, didnt pop earlier in my search results, but is from Thursday (September 30th) already

https://www.fortinet.com/blog/psirt-blogs/fortinet-and-expiring-lets-encrypt-certificates

this also seems to indicate that only changing the bundle wont be enough. the bundle which seems now updated to (around 20:00 October 1st for me) but you also need that checked blocked in some way. which hopefully doesnt break other things.

communication wise Fortinet isnt doing very well here in my opinion. not reaching out on this when it occurred (or even weeks earlier so we could prepare), but letting people contact them. too many places with parts of information that doesnt match. announcing bundles which aren't out yet.

Solution

Fortinet is working on a longer-term solution to improve certificate validation and add additional intelligence to rebuild missing certificate chains in these cases going forward, and will include this in a future release.

this has happened twice now, certainly hope not a third time.

[boneyard]

adder666 wrote:

One more update. So I copied it all and enabled it, broke things again. Like Google was blocked, though others were allowed now. Like the previous City of Pittsburgh, CA site. That was available, but Google wasn't. Not sure what the hell is happening on this device, but it's obvious I need to spend way more time in there learning.

certificate inspection and deep inspecting are quite different things. where deep inspection simply will require quite some exceptions as not all sites work with the man in the middle process. i advise you to try again for one IP (policy source) and work on an acceptable setup before going broader. if that fails start a new question / thread to get help on that.

[Toshi_Esumi]

Through the ticket we opened for our customer who encountered this situation, TAC L2 said that they removed the expired DST Root CA X3 from the certificate bundle and pushed yesterday as version 1.28. I now can see it like below:

FG1xxxxxxx-fg2 (global) # diag autoupdate versions | grep 'Bundle' -A 6 Certificate Bundle --------- Version: 1.00028 Contract Expiry Date: n/a Last Updated using push update on Fri Oct  1 13:23:41 2021 Last Update Attempt: Sat Oct  2 17:23:41 2021 Result: No Updates However, he also said since it's still receiving expired cert from the server as one of multiple chain paths, it would block it since AIA fetching pulls the same expired cert. Therefore DNS blocking is necessary for "apps.indentrust.com". Once apps.identrust.com removes and stops sending the expired cert, it would be solved and you can remove the DNS blocking. All are described below: https://kb.fortinet.com/kb/documentLink.do?externalID=FD53305

For the fix they're intending, when I asked about these situations with cross-signing, he mentioned "... making FGT behavior something similar to web browsers. ... trust the chain that the website is providing and ignore the untrusted certificate chain."

[Toshi_Esumi]

I haven't upgraded any of our FGT to test, but they said the fix is included in 6.2.10, which was released last week.

In the release notes you can find below in Resolved Issues list:    750551 DST_Root_CA_X3 certificate is expired.

[Toshi_Esumi]

Although the L2 TAC guy couldn't reveal the detail how they fixed, he at least said: "The fix was to make fnbamd more intelligent ... try its best to find an alternate certificate path if the peer-provided chain contains any CA expired."

He also said the same fix would go in to 6.4.8 and 7.0.3.

[Aldanar]

toshiesumi wrote:

I haven't upgraded any of our FGT to test, but they said the fix is included in 6.2.10, which was released last week.

Can confirm. 6.2.10 does fix this issue.

[ffischer]

Update: Fortinet removed the expired  DST_Root_CA_X3 from the factory certificate bundle and published an update.

As expected, this does not help if the webserver is misconfigured and keeps sending a certificate chain still containing the old X1 Cert signed by the expired DST_Root_CA_X3.

I'd say, 'fixing' this on the FGT side by ignoring the chain would require a code change... what means we can expect a behavior similar to browsers only with the next release/build.

[krzysztof]

Hello,

I have implemented the workaround 1 from here:

Fortinet and Expiring Let’s Encrypt Certificates

and it looks like it did the trick.

I pushed following config to all the Fortigates (using the scripting on FortiManager):

config system dns-database     edit "1"         set domain "identrust.com"         config dns-entry             edit 1                 set hostname "apps"                 set ip 127.0.0.1             next         end     next end

Then I also cleared the DNS cache:

diag test application dnsproxy 1

Some of the users had to restart their machines and then it started to work OK.

It is a bit dirty solution but definitely better than trusting all invalid certs or entirely disabling deep inspection .