为提升您的使用体验,本站正在维护,部分功能暂时无法使用。如果本站文章无法解决您的问题,您想要向社区提问的话,请到 Twitter 上的 @FirefoxSupport 或 Reddit 上的 /r/firefox 提问,我们的支持社区将会很快回复您的疑问。

搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

Using StartTLS with IMAP connection to Exchange is giving me different certificates for machines different to the IMAP server, security exception each time

  • 3 个回答
  • 1 人有此问题
  • 1 次查看
  • 最后回复者为 Matt

more options

I'm using Thunderbird with my work email account, which is using Exchange, this is not officially supported but access is allowed via IMAP.

The problem is when I'm using StartTLS or SSL I'm getting multiple different self signed certificates being returned, seeming depending on which specific backend server is handling the request, each time it causes the Confirm Security Exception dialog to be displayed. If I confirm the exception I get the dialog being displayed again until eventually I get a certificate that seems to match the first certificate I confirmed, at which point I can download or send my pending mail.

Thus is seems that there is only one certificate being stored as an exception for each server connection. Is there some way round this?

Thanks.

I'm using Thunderbird with my work email account, which is using Exchange, this is not officially supported but access is allowed via IMAP. The problem is when I'm using StartTLS or SSL I'm getting multiple different self signed certificates being returned, seeming depending on which specific backend server is handling the request, each time it causes the Confirm Security Exception dialog to be displayed. If I confirm the exception I get the dialog being displayed again until eventually I get a certificate that seems to match the first certificate I confirmed, at which point I can download or send my pending mail. Thus is seems that there is only one certificate being stored as an exception for each server connection. Is there some way round this? Thanks.

所有回复 (3)

more options

What is the reason for the exception prompt in the first place?

more options

This the output from the error console:

Timestamp: 06/03/2015 10:51:46 Error: YYYYYY.XXXX.com:143 uses an invalid security certificate.

The certificate is not trusted because it is self-signed. The certificate is only valid for the following names:

 HQ-X10PRDCAS6, HQ-X10PRDCAS6.ZZZ.XXXX.com  

(Error code: sec_error_unknown_issuer)

This gets repeated several times until eventually the connection works and I can send and receive mail for a while until it starts again.

Note that I have a root certificate and an issuing certificate from my company installed in my Thunderbird certificate store, but this doesn't seem to help.

Also in the Thunderbird certificate store I also see:

HQ-X10PRDCAS5 YYYYYY.XXXX.COM:143 permanent 11/11/2019

Which seems to be one of the certificates above, however it seems Thunderbird will only allow one certificate per server connection, which perhaps might be relevant.

Note that I'm using Thunderbird 31.5.0 On Mac OS X 10.10.2 (Yosemite)

more options

Your employer, like many companies who have invested huge amounts of money in software from Microsoft are using self signed certificates to save a few dollars.

Personally I love the way companies will give Microsoft half a million dollars for software licenses and then skimp on the last point one percent of the expense and save a few bucks issuing their own self signed certificates that only they trust.

It is also questionable if your corporate tech people actually understand clustering if they are giving a separate certificate to each server. But none of that help you.

Given port 143 is actually designated for IMAP without security, I would suggest turning off the TLS and/or try port 993 which is the designated port for TLS. It might be the server admin only set up proper certificates for the TLS port.

Please view the details of the certificates and note the issuer shown. My guess in one of these corp you have in your store and the rest for some slight variation of spelling or name, thus breaking the actual chain of trust.