Turns out, the CAcert was wrong. It presents as a “file not found” error, but it’s just a file that doesn’t work. It needs to include both certs from the chain, which is different to how the chain’s exported from the windows CA server normally.

SSL is great, except when you’re trying to audit access or filter things, let alone simple troubleshooting. Long story short, we run a Man In The Middle style system where our proxies are the HTTPS clients and they have an SSL certificate which all of our clients trust.

This relies on the proxies trusting the certificate chain, and these chains need to be updated periodically. Here’s an example of how to fix it when it goes wrong.

Open the site in a browser, which fails with a certificate trust issue.

Once you’ve established that it only happens when the Ironport is involved, we need to find the certificate chain.

Here’s what it looks like on Safari:

Or from the Qualys site:

The certificates stored in the Ironports are shown by logging in to each WSA individually, then clickingSecurity services -> HTTPS Proxy -> Manage Trusted Root Certificates

To verify we have the correct CA certificates, we need to compare the fingerprint to what’s in the results above. Starting with the root certificate, do the following.

Find it by name in the Ironport interface

Click the arrow next to the name, then right click on the “Download Certificate” link and download it.

To check the fingerprint matches, open a command prompt and run “openssl x509 -fingerprint -noout -in [filename]” Where [filename] is the certificate file you downloaded before.

This will show the fingerprint of the file, and you can match it up with the corresponding information above. It’ll be in hexadecimal, ignore any punctuation. If it’s correct, work up the chain until you find the one that’s wrong.

Once you’ve found the missing/outdated certificate, you’ll need to find the updated one online. Google’s your friend.