Certificate Issues with S170

[spm]

Hello,

Some background first.  We use BitDefender Endpoint security for our AV solution.  One of the features of BitDefender is when a user goes out to a secure website it checks the validity of the sites certificate.  To do this Bitdefender replaces the sites root CA certificate with its own.  Essentially it does a man in the middle attack. 

Now most of the time this seems to work ok and secure sites load normally.  But we've been having issues with our browsers throwing up security messages saying it is unable to verify the site certificate.  Other times the browser down right refuses to load the site at all.  When I check the sites certificate there's nothing listed in the certificate path for a CA.

During my testing and some trial and error I've ruled out DNS or firewall issues.  The only thing left is our IronPorts.

My question is this.  How does the IronPort handle something like a man in the middle attack with a websites certificate?  I've been going through the log subscription but unable to find anything to point me at what may be causing the issue.

We're running in transparent mode with AsyncOS version 8.5.1-021.  If anyone has an idea or seen this issue before I'd be grateful for a lead.

Thanks,

Shawn

[Ken Stieers]

Ironports with the HTTPS proxy running do exactly the same thing, so the BitDefender is only seeing the cert from the Ironport.

It could be that the certs that don't work are ones that the WSA has failed on because it can't assemble the chain, so it throws a "bad cert" page at the browser which the BitDefender raises also.

Usually I have to upload the intermediate cert into the WSA to fix it, or occasionally the root cert if Cisco hasn't added it to the package.

[spm]

Hmmm.... My issue may not be with BitDefender.  I also having trouble with computers and mobile devices that don't have it installed.

[Ken Stieers]

Get on a machine that is NOT behind the WSA.

Hit the site, presumably it should get certs cleanly. Save the intermediate and root certs as base64 x.509 files.    (in IE, click on the "lock" in the address bar, then View Certificates>Certifcation path. Click on each cert, click View Certificate, then on Details tab click on Copy to file)

Then go to the WSA, go to Security Services/HTTPS proxy, near the bottom of the page click on the button for "Manage Trusted Root Certificates". Import the root and intermediate cert.  The gui will show you if already has it (typically happens with the root), and if so, you can delete it.  Then commit it.

[spm]

I believe I have found the issue.  The IronPort is blocking one of the sites used by BitDefender to check for malware and such.  ep-reverse.nimbus.bitdefender.net  It's being blocked because of it's reputation score.  (-6.4)  Is there a way to bypass the rules for this site and it's associated IP addresses?

[Ken Stieers]

Yep, there are a couple of ways.

If you're using WCCP, on the WSA under Web Security Manager/Bypass Settings, you can add this IP.   Only do this with stuff you trust, as this means that the WSA doesn't see this traffic at all.

If you're using explicit, you'll need to create a custom url category, put this in it, then create a new access policy with the reputation stuff turned off.

[spm]

Figured out what was going on.  I had to log a TAC case and the engineer figured out what the problem was right away when I showed him a traffic capture. 

It looks like requests for certificate revocation lists were being redirected back at the IronPort.  The engineer said it was a known issue. 

The fix was to add an expression to an auth exempt custom URL category .  Specifically it was \.crl$ .