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!
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
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!
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 :(
Great thread guys, many thanks indeed. Currently i also only see 'allow expired' as a temporary workaround.
the issue has been so far seen by us on 6.2, 6.4 and 7.0
NSE8
Fortinet Expert partner - Norway
Word has it Fortiguard are working on an update
NSE8
Fortinet Expert partner - Norway
simonorch wrote:heard the same, but quite sceptical they can solve this on the FortiGuard side. it feels like it needs an actual code change.Word has it Fortiguard are working on an update
boneyard wrote:I think removing the X3 certifcate from the trust store on the Fortigate should also solve this.simonorch wrote:heard the same, but quite sceptical they can solve this on the FortiGuard side. it feels like it needs an actual code change.Word has it Fortiguard are working on an update
This workaround works for us (200E, 7.0.1, Policy mode Proxy & Deep inspection)
Jirka
boneyard wrote:heard the same, but quite sceptical they can solve this on the FortiGuard side. it feels like it needs an actual code change.
My thoughts exactly. I guess they will just make an exception for the expired DST_Root_CA_X3 certificate and ignore its expiry date.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.