![]() With the removal of the expired IdenTrust DST Root CA X3 in Certificate Bundle version 1.28, it is possible to prevent fallback to the expired root CA by blocking FortiGate access to, resulting in the correct root CA being used. Workaround 1 – Prevent fallback to the expired Root CA ![]() If this URL is not available, however, FortiGate will attempt to rebuild the chain of trust from the start and use the ISRC Root X1 Root CA Cert, which does provide an additional potential workaround.įor sites under your own control, changing your server certificate to using the alternative chain will remove this issue, except for pre-7.1.1 Android devices, as described above. So, FortiGate heads off to the URL and downloads the now-expired certificate and we are back to square one, failing the connection due to an incomplete certificate chain of trust. This tells the client how to rebuild the chain of trust if the anchor is not available in the local certificate store. We have removed the offending expired certificate from the certificate store, however, this still does not solve the problem due to the Authority Information Access – CA Issuers entry. ![]() The issue being seen by Fortinet customers is due to Fortinet devices validating the full chain of trust and then invalidating the chain when it sees that the CA IdenTrust DST Root CA X3 is expired, even though the cross-signed ISRG Root X1 root is valid for longer. Scott Helme has his own description for the cross-signing in his post. The reason this workaround worked for Android Devices is that they do not check the notAfter field of trust anchors. The cross sign still is in place (by default) for new LE issuance (even after the expiration of DST Root CA X3). Let’s Encrypt stated that the reason for the cross-sign was to improve compatibility with pre-7.1.1 Android devices.
0 Comments
Leave a Reply. |