I have imported a trusted root certificate into the Windows local machine list. This works fine with my signed certificates, unless my AV (Bitdefender Antivirus Plus 2012) is set to "scan SSL", in which case my certs are flagged as untrusted.

I can manually turn off SSL scanning, or add my certificate to the CTL that they use for mitm, or sign my certificates with their fake root cert and key. None of these options are any good if I want to deploy my application to remote users who may use other AV's

The AV has its own CTL to which I have not added my root cert, so I am wondering how the AV gets the browser/OS to use this alternate CTL and can this be overridden?

  • I found that the AV actually alters the certificate according to its own CTL before handing it to the OS, not changes which CTL the OS uses. Aug 19, 2012 at 9:27

1 Answer 1


My understanding of this from using Fiddler 2 is that the AV would have to work as a proxy. Thus, it would act as the client to the website you request and all SSL pages would be signed by the anti-virus software's cert on the fly to make it appear to be valid. Most likely, in the case that the A/V software doesn't trust the source, it does not apply a valid SSL cert via it's own trust to allow the information to be relayed to the browser. Because your valid SSL trust has been stripped by the proxy (because the proxy is not in fact your server), the connection appears to be invalid.

It would be up to each client's AV software to respect the certificate trust and there isn't any way I know of to handle that in the general sense other than get a root or domain signing cert from a trusted CA that would most likely be seen as valid by most AV software.

  • I omitted the detail that the cert's I am feeding to the client are on-the-fly generated by my own SSL filtering http proxy. I had to import my own signing cert into the OS CTL, but the AV uses it's own CTL for SSL scanning and also somehow intercepts my proxy communications to the client. The real question I should be asking is "How can I guarantee that I am the final agent to talk to the client?" Aug 30, 2012 at 22:35
  • 1
    Hmm, that is a very different problem. I would start by trying to determine how the AV package is getting itself configured. My best guess for you would be to try configuring your proxy to work from the browser's settings directly. It would require browser specific configurations and isn't foolproof, but it should be the last thing that is run unless the AV is being really sneaky I would think. Aug 31, 2012 at 14:21
  • I've been led to suspect the AV is doing something sneaky with Winsock LSP which can sit between local proxy and browser. My concern is if I square off with my own LSP routine or tinker with the low-level browser settings, the AV might flag me as malware or I'll create some kind of competing deadlock condition. Currently I'm looking into a macro-esque solution to automate control of the AV's GUI. Messy business. Aug 31, 2012 at 19:43
  • Right, what I'm talking about is that most browsers have their own proxy settings. In theory, you should be able to hook that unless the AV is actually hooking at the level of any port that tries to act as a proxy, in which case things would get all kinds of screwy. Aug 31, 2012 at 20:25
  • In the case of Chrome, IE and FF the proxy settings are determined by the Windows OS internet settings; the socket my proxy listens on. I always assumed that is the browser interface with the network. Unless there is an accessible layer in between... Aug 31, 2012 at 20:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .