Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

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

  • 3 replies
  • 1 has this problem
  • 1 view
  • Last reply by 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.

All Replies (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.