Jump to content


  • Content Count

  • Joined

  • Last visited

Profile Information

  • Location
  1. 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?)
  • Create New...