Closed Bug 493980 Opened 13 years ago Closed 12 years ago

If a SSL security certificate expires, Thunderbird goes into an infinite UI loop


(Thunderbird :: Security, defect)

Not set


(Not tracked)

Thunderbird 3.0b4


(Reporter: cmtalbert, Assigned: Bienvenu)


(Whiteboard: [workaround comment 4][no l10n impact][has potential fix])


(4 files)

An SSL certificate expired on one of my mail accounts.  I have no idea how to fake a certificate, but to reproduce this bug, that's what you'll need to do.

1. Create an SSL mail account (IMAP in this case) in thunderbird
2. Allow the SSL certificate to expire

= Expected =
Thunderbird would notify me about this, and would provide some mechanism to allow me to say "ok, stop telling me about it".  The proper thing would be to perhaps shut down that mail account and/or switch to non-ssl (with appropriate warnings of course).

= Actual =
I get the same dialog over and over, every 10 seconds.  There is no way for me to tell thunderbird to stop showing the dialog, no way for me to tell it that this is expected and ok, no way for me to do anything except clicking "cancel" for the rest of my life. :(

This might be a core NSS bug, but I couldn't find one when searching.  My problem here though is less about how the certificate expires, but more about the UI that notifies the user about the expiration being completely worthless.
Flags: blocking-thunderbird3?
Obviously as a workaround, you can turn off SSL for the offending mail account. However, going to the webmail site directly in firefox works fine, so I what I suspect is that the Certificate did expire, was renewed, but Thunderbird can't seem to get past the detection that the certificate expired.  Turning SSL off obviously stops the popup from occurring.  But that's not really a solution. :(

Checking the cert in Firefox, the cert being used there is much newer and was issued on 4/30/09, expires in 2012.  So, I think there are two issues here:
1. The broken UI when a cert expires
2. The fact that the cert was renewed and Thunderbird did not detect it.

Do you want a separate bug for 2?
I have the same behavior here with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2. Expired certificate and no chance to accept it anyways.
(In reply to comment #3)
> I have the same behavior here with Mozilla/5.0 (Macintosh; U; Intel Mac OS X
> 10.5; de; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2. Expired certificate
> and no chance to accept it anyways.
update: when i press command+Q (shortcut for quitting thunderbird) while the warning window (cert expired) is open, the window to add an exception for this certificate opens. When i click on this window it changes back to the warning window immediately. With the right timing for the mouse click it was possible to add an exception for the expired certificate.
Whiteboard: [workaround comment 4]
This infinite-loop also happens for me with an invalid SSL certificate.  (My certificate will always be invalid, because I'm using a proxy and the certificate is only certified for the mailhost behind the proxy.)

Here's what happens for me:

When checking for mail, I get the dialog entitled "" uses an invalid certificate".  I can "view certificate" or "cancel."  About half the time, clicking cancel shows the "You are about to override" dialog.  But it only shows up for a split second, too fast for me to click the "confirm this exception" button.  Then it loops back to the first "invalid certificate" dialog (sometimes without showing the "override" dialog).
(In reply to comment #5)

Forgot to mention, I'm using this version:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
accepting as blocking hoping we can deal w/ the infiniteness of the loop.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Whiteboard: [workaround comment 4] → [workaround comment 4][no l10n impact]
Target Milestone: --- → Thunderbird 3.0b4
I'll have test IMAP servers with expired and invalid certificates setup by the end of the day to help in testing this.
See for details.

The cyrus IMAP server on can now be reached via SSL with 2 more certificates:
 port 9999: hostname mismatch
 port 9998: valid hostname, expired certificate
Is this an issue in PSM ?
I'll try to reproduce this.
Assignee: nobody → bienvenu
I didn't have a problem with either of those certs - both times, connecting to the imap server gave me a chance to confirm the cert exception. So either we don't have the right kind of cert error to cause this issue, or we're not following the same steps, or there's something different in the profiles of users who are having a problem. I wonder if there are some prefs that control how these cert dialogs are put up...
or perhaps the new cert override dialog stuff is not getting hooked up in some situations (no msgWindow for the url?) and we're falling back to some older PSM dialogs...
OK, I can get that dialog when biff fires for an account with an invalid cert, because biff doesn't set up a msgWindow for the url. But if you click on a folder on the imap server, or click get new messages for the server, the url will have a message window and should put up the cert dialog that allows you to add an exception for the cert. Is anyone who is having this issue clicking on the imap folder and seeing the same problem? If so, it may be that our bad cert listener is not sufficient in some way...
If the ssl code is going to pop up its own dialog on background urls like biff, there's no reason for us not to always provide a cert override dialog on all our urls, even those w/o a msg window. That might be easier said than done, however, since we hang the notifications callbacks off of the msg window. I could do the topmost msg window hack to find a window that has a bad cert handler. Or perhaps we could make the bad cert handler a js component that we can get access to from the backend...
Or I could just write some c++ code that puts up the bad cert handler dialog - might be easier than trying to hook up the backend urls to a front end js component. I'm particularly worried about someone closing a msg window while a url is running...since we're required to set the notification callbacks when the url starts running.
Attached patch possible fixSplinter Review
this makes pop3 and imap try very hard to find some notification callbacks to use, even if the url is a biff url.

I figure it's pretty unlikely the notification callbacks will get used more than once (i.e., the user will override the exception, if appropriate).
Attachment #398064 - Flags: superreview?(bugzilla)
Attachment #398064 - Flags: review?(bugzilla)
it's mostly imap and pop3 urls that run w/o msg windows, which is why I only fixed them up...
Whiteboard: [workaround comment 4][no l10n impact] → [workaround comment 4][no l10n impact][has potential fix]
re the infinite loop, I don't know what's trying to run a url every 10 seconds. Gloda may have used to try to fetch messages from the server (it doesn't now), or auto sync might have been kicking in on each 10 second idle interval.
Comment on attachment 398064 [details] [diff] [review]
possible fix

I've done a few tests and this seems fine.

>+nsresult nsMsgProtocol::GetTopmostMsgWindow(nsIMsgWindow **aWindow)
>+  nsresult rv;
>+  nsCOMPtr<nsIMsgMailSession> mailSession ( do_GetService(NS_MSGMAILSESSION_CONTRACTID, &rv));

nit: no space before or after the (
Attachment #398064 - Flags: superreview?(bugzilla)
Attachment #398064 - Flags: superreview+
Attachment #398064 - Flags: review?(bugzilla)
Attachment #398064 - Flags: review+
fix checked in, with comment addressed.
Closed: 12 years ago
Resolution: --- → FIXED

Still have the problem on thunderbird 68.11.0 on linux fc31 x86_64.

I have this happen periodically, and if it helps as a clue, my server uses Let's Encrypt, on a certificate that is shared by multiple domains. When this happens, no button on the modal window has any effect except to close the window, which immediately pops back up, preventing me from doing anything else in thunderbird, requiring me to close the program down and starting it back up.

Not sure what the difference between this bug and bug #539939 is, but from what I can tell they are duplicates.

(In reply to insaner from comment #22)

Still have the problem on thunderbird 68.11.0 on linux fc31 x86_64.

Please don't comment on long-closed bugs. Your issue is most likely a different one or something that has re-occurred. Please file a new bug.

For anyone landing here from a search engine, I filed Bug 1708933.

You need to log in before you can comment on or make changes to this bug.