Let's Encrypt Fun (NOT) - Yet another workaround

Note: this article expresses my opinions, however incorrect you may feel they are. They don't reflect the opinions of anyone else or any other organization.

Back on October 2nd I released Let's Encrypt Fun (NOT) - a workaround, and it got a lot of reads (THANK YOU!) however while it seems to have alleviated most issues, I still see a few holdouts out there that don't seem to work with this workaround. In working with u/pabechan we noticed that sometimes the server is still providing the expired DST Root CA X3 cert. This can be validated at SSL Labs, and if the server is presenting the expired CA, it will tell you:

If that's the case, then the workaround proposed in the previous article won't work. To understand why, let's take a look at how it works:

1. FortiGate looks at the request sent to a website

2. Server authenticates itself and sets up TLS using its issued cert, which typically will stop at ISRG Root X1

3. The FortiGate will be inspecting the default chain, as in the figure above

4. As discussed in the previous article, it will see that the ISRG Root X1 has a path to the IdentTrust DST Root CA X3, and the FortiGate will attempt to look up that cert at "apps.identust.com", but our workaround "blocks" that communication. So the FortiGate see's that the ISRG Root X1 Self Signed exists as well and everything is happy

5. The problem we run into with some sites is they're presenting the full default chain - including the expired IdenTrust DST Root CA X3, in which case the FortiGate doesn't have to look up the cert (and there will be no blocking) since it already has it presented. The FortiGate will inspect the full chain, see that the Root Trust Anchor is expired and block the connection if your policies are running Flow/DPI or Proxy mode

Now, before you start writing a heated "well no where in the X.509 standard does it..." stop, nobody is blaming Let's Encrypt, nobody is blaming Fortinet - save that for another discussion. I am only stating the status quo. Until Fortinet releases the anticipated fix for cert path lookup, this is where we are.

With that out of the way, let's talk about the current available workarounds:

1. Switch the policies affected to Flow based inspection if running in Proxy - this feels a bit over arching, and can impact operations, especially if Proxy features are in use

2. If using Flow with Deep-Inspection switch to certificate inspection, again, part of the reason we're inspecting SSL/TLS traffic is to find threats, this would effectively blind us to all traffic

3. Allowing expired Certs - This is bad, don't do this

4. Use the IdenTrust DNS blackhole as suggested - this works well enough, however it can't fix the sites presenting the full certificate chain. Which leads us to another way to work around this

5. Create an address object with the domain (*.domain.com) and build a flow/certificate-inspection policy referencing the address object as the destination address - this would help with the "Stragglers" not addressed by #4. Combined with #4, I feel a bit better about this than 1-3 due to the fact you're limiting what domains you're willing to switch to certificate inspection

Here's how we do it:

For this example I am going to use generic terms due to not wanting to single out any entities, as it's hard to know which entities may still be advertising the DST Root CA X3

Creating the FQDN address object:

1. Browse to Policy & Objects > Addresses

2. Create a new address object

   1. Name: input a meaningful value

   2. Type: FQDN

   3. FQDN: *.domain.com

   4. Interface: any

3. Click OK

Once we've created the FQDN Address object, we'll create a policy.

Creating the Policy:

1. Browse to Policy & Objects > Firewall Policy

2. Click Create New:

   1. Policy Name: input a meaningful name

   2. Incoming interface: select the incoming interface(s)

   3. Outgoing interface: select your outgoing interface(s)

   4. Source: specify any and all desired source addresses

   5. Service: I selected HTTPS, use any and all ports you feel are applicable

   6. Destination: your FQDN address object(s) that you wish this workaround applied to, in this case I am adding our *.domain.com FQDN address object

   7. Inspection Mode: Flow Based

   8. Apply NAT as you see fit

   9. Apply security profiles as necessary, with the exception of SSL Inspection, set this to certificate inspection

   10. Select session logging as you desire

3. Click OK

Don't forget to move this to be above your policy for general traffic, so that it catches the intended traffic!

What I like about this, is it's one rule to manage any of those additional entires. When Fortinet releases the fix, you can disable the rule (for validation), and then delete it at a later time once you've verified all is working correctly.

And that's it! Hopefully this provides another avenue to ensure your users can access the web services they need access to without hampering your security posture. Thank you for reading, I hope this is helpful.

Madman out!