Manfred123

Description: EEA e-mail SSL filtering with shared certificates Detail: Some ISPs offer access to e-mail services on their servers through their customer's server domain name (e.g. mail.customerdomain.com), while in fact the mail service is hosted on one of the ISP servers (e.g. mail.ispdomain.com). This results in the server certificate to be provided with CN=mail.ispdomain.com, as a response to a request to mail.customerdomain.com. The motivation (reported) is that the certificate is shared among the mail service names managed by the ISP. This can generate a name mismatch exception on some clients - namely on Thunderbird, but possibly on others too. Thunderbird deals with this by allowing to store an exception for the involved certificate (it remembers to accept the certificate for mail.customerdomain.com). The problem arises with ESET SSL filtering when the filter modifies the certificate by adding its signature, since this signature appears to change on a daily basis (or even more frequently) - apparently whenever the threat database is updated. This continuous change of the signature voids Thunderbird storing the exception (because each time it is presented with a different certificate), and results in the user to be continuously notified of a name mismatch. I reported this behavior in the forum, and i have been advised to store an exception in EEA so as to "allow" the certificate and "ignore" the scan action on the associated channel - this should result in the server certificate to be forwarded untouched to the client. But, I see two problems with this: 1) "allow" + "ignore" does not seem to behave as described: even if EEA is configured this way, the first time Thunderbird connects to the server after system startup, it gets a certificate that is re-signed by ESET. This means that in a common usage scenario the user is still notified of the exception every day. 2) Even if EEA were to behave as expected, configuring to "ignore" scanning of the e-mail stream voids the threat scan on that channel, as far as I understand. Would it be possible some improvement on this? e.g. by allowing "scan" for known certificates while still forwarding the certificate untouched to the client? (and BTW have "ignore" actually ignore even on first access?)

This is what I would expect too. But I see that the first time I start Thunderbird after system startup, it still gets a certificate signed by ESET. If I ignore the exception (and don't store the modified cert), subsequent accesses get the original certificate. This happens both if I re-access one of the mailboxes involved, and if I close Thunderbird and re-open it. Snapshots follow: I have the following configuration (actual CN renamed): In Thunderbird, I have an exception for the following certificate: After system startup, the first time I open Thunderbird it shows an exception for the following certificate: If I ignore this exception, at subsequent accesses and/or after restarting Thunderbird no exception is raised, and I verified that the exception stored in Thunderbird still uses the AplhaSSL-signed certificate. However, as an additional note, I have seen that if I re-configure the list of known certificates in ESET EEA by deleting and re-adding the certificate as above, after re-configuration the first access by Thunderbird again got the certificate modified by ESET. I have done this last part once, and seen it happen in that case.

I would love this, but even if I set "Scan" to Ignore, still ESET modifies the certificate - specifically it adds its signature to it. The problem is that ESET takes "Name" from the CN of the certificate, and it is not editable by the user. Since the server provides a certificate with CN= *.ispdomain.com, I get the wildcard in the name, and I cannot remove or modify it. Maybe the presence of the wildcard is why the channel gets scanned anyway?

We have mailboxes with multiple providers, and this problem applies to some of them: So, yes, all mailboxes that are managed by one such ISP are affected by the problem. But, we also have mailboxes that are managed by providers whose certificate matches the name of the mail server, and the SSL filter works fine with them. We would like to exclude the SSL filter only for the providers where the problem arises, and these are identified by their respective certificate.

This is the configuration I had when I first started this thread.

By the way, I had a similar problem with Dropbox, and I solved it by filtering Dropbox.exe to "ignore". This is OK for such application, since I want /all/ of its SSL traffic to be ignored by ESET. For Thunderbird this is different, since the problem applies to only some of our mailboxes, and I would rather keep the others fully scanned.

Marcos, thanks for the reply. Unfortunately no luck with "Allow" and "Scan" either. Still Thunderbird receives a certificate that has been modified by ESET, and the exception is raised.

We are having problems with EEA SSL filtering with Thunderbird. Some of our ISPs provide mailserver access names in the customer's domain: e.g. mail.customerdomain.com, and supply a TLS certificate that is shared among the domains that are managed by the ISP, e.g. *.ispdomain.com. This raises an exception at the first access with Thunderbird, but after storing once an exception for this certificate, all works fine. The problem arises when the ESET SSL filter adds its own signature to the certificate, which appears to be modified at every update - in practice every day or more. This results in Thunderbird detecting that the certificate is changed, and raising an exception every time ESET changes its signature - i.e. every day or multiple times a day. I have not been able to configure a proper exclusion in EEA. Policy mode looks interesting but it does not appear to do what is needed: " Policy mode – All SSL/TLS protected sites are filtered, except configured exclusions. Either applications or server certificates can be excluded" What I need is some "server certificates to be excluded", but I only see a list of "known certificates", and even if I configure the certificates I want to be excluded in this list with access "allow" and scan "ignore", still Thunderbird receives a certificate that has been modified by ESET by adding its signature. Is there a way to configure an exclusion for some certificates (*.ispdomain.com in this example) so that this certificate is passed to the application untouched? To me scan "ignore" should do exactly this, but it appears not to be so.. Otherwise, the only option I see right now is to exclude SSL filtering for the entire Thunderbird application, but this is not what I want, since this problem only applies to some of our ISPs