Some .gov sites blocked, others are not?

Forum|Forum|4 years ago
September 30, 2021
4 replies
46250 views

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!

Web Filtering

LucD

New Member

use a lets'encrypt issued certificate. There is a problem since yesterday for letsencrypt issued certificates.. Using flow-based mode could help... We are using an explicit proxy so I think we have to use proxy-based mode.

Tibo

Visitor III

Hello,

Looks like you're impacted by Let's Encrypt's Root Certificate expiration issue.

Here's an article of a similar case, last year:

https://kb.fortinet.com/kb/documentLink.do?externalID=FD49028

Somehow the FortiGates still choose the wrong certification path.

When bypassing certificate inspection, you can clearly see that modern browses choose the right path.

Here's a link to an article of Let's Encrypt, written back in May:

I hope Fortinet gets this right for future cases...

Good luck!

ffischer

New Member

Have same problem here on 6.4.7 i.e with "https://mathefachschaft.de"

Here is what happens: They use Let's Encrypt Certs for their server as well. https://www.ssllabs.com/ssltest/analyze.html?d=mathefachschaft.de shows, they send the complete chain with an "ISRG Root X1" Fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f which is signed by the DST Root CA X3 expired yesterday.

The factory default trusted store on FortiOS contains the old, expired

fortigw (ca) # get DST_Root_CA_X3
name                : DST_Root_CA_X3
ca                  :
        Subject:     O = Digital Signature Trust Co., CN = DST Root CA X3
        Issuer:      O = Digital Signature Trust Co., CN = DST Root CA X3
        Valid from:  2000-09-30 21:12:19  GMT
        Valid to:    2021-09-30 14:01:15  GMT
        Fingerprint: 41:03:52:DC:0F:F7:50:1B:16:F0:02:8E:BA:6F:45:C5
        Root CA:     Yes
        Version:     3
        Serial Num:
                44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
        Extensions:
                Name:     X509v3 Basic Constraints
                Critical: yes
                Content:
                CA:TRUE

                Name:     X509v3 Key Usage
                Critical: yes
                Content:
                Certificate Sign, CRL Sign

                Name:     X509v3 Subject Key Identifier
                Critical: no
                Content:
                C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10


range               : global
source              : bundle
ssl-inspection-trusted: disable
scep-url            :
source-ip           : 0.0.0.0

as well as and the new

fortigw (ca) # get ISRG_Root_X1
name                : ISRG_Root_X1
ca                  :
        Subject:     C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Issuer:      C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Valid from:  2015-06-04 11:04:38  GMT
        Valid to:    2035-06-04 11:04:38  GMT
        Fingerprint: 0C:D2:F9:E0:DA:17:73:E9:ED:86:4D:A5:E3:70:E7:4E
        Root CA:     Yes
        Version:     3
        Serial Num:
                82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00
        Extensions:
                Name:     X509v3 Key Usage
                Critical: yes
                Content:
                Certificate Sign, CRL Sign

                Name:     X509v3 Basic Constraints
                Critical: yes
                Content:
                CA:TRUE

                Name:     X509v3 Subject Key Identifier
                Critical: no
                Content:
                79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E


range               : global
source              : bundle
ssl-inspection-trusted: enable
scep-url            :
source-ip           : 0.0.0.0

Now,

ssllabs shows that there are 2 possible verification paths: One with the new self-signed X1 as the root CA,

another with the expired DST_Root_CA_X3 as the rootCA; here X1 is only an intermediate CA.

The web server sends the X1 cert pointing to expired X3 in the chain:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            40:01:77:21:37:d4:e9:42:b8:ee:76:aa:3c:64:0a:b7
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3
        Validity
            Not Before: Jan 20 19:14:03 2021 GMT
            Not After : Sep 30 18:14:03 2024 GMT
        Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    ....
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            Authority Information Access:
                CA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c

            X509v3 Authority Key Identifier:
                keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10

            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.root-x1.letsencrypt.org

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.identrust.com/DSTROOTCAX3CRL.crl

            X509v3 Subject Key Identifier:
                79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E
    Signature Algorithm: sha256WithRSAEncryption
         .....
SHA256 Fingerprint=6D:99:FB:26:5E:B1:C5:B3:74:47:65:FC:BC:64:8F:3C:D8:E1:BF:FA:FD:C4:C2:F9:9B:9D:47:CF:7F:F1:C2:4F

So the Fortigate simply follows the path suggested by the webservers' chain and fails verification.

I would not say this is a bug incorrect but would consider it as misconfiguration of the webservers cert chain. If the server admin would simply remove the x1 cert from the chain, the FG would use the built in, new X1 CA and could verify successfully.

The only was FN could resolve the issues is by not only follow the path suggested by the servers' chain, but check any cert against the factory and user trusted certs as well.

Well.. this explanains the errors, but it does not help to get the websites unblocked until the server admins correct their configs.

As a bad workaround I have set "allow" expired certificate in the ssl inspection for the moment :(