437683 - Selection choices for SSL client certificate in account/identity configuration (or Option to automatically "Do not send any certificate"?)

Status: NEW

Description

[Nelson Bolyard (seldom reads bugmail)]

The configuration for each email/news account in Thunderbird should include
a selection of which certificate to send to the server when the server 
requests that the client authenticate itself with an SSL client certificate.
The choices should include:
  - choose automatically, every time (default)
  - ask me every time 
  - Send no certificate (do not authenticate with a certificate)
  - Use this certificate [ list box of usable SSL client certs ]

There are numerous bugs getting a bunch of activity recently, complaining
that when their IMAPS, SMTPS or POP3S server requests that their MUA 
authenticate itself to the server using an SSL client certificate, the 
client silently responds with some cert that the server subsequently rejects.

The result is that the user is unable to use the IMAPS, SMTPS or POP3S 
account until he either 

a) deletes his SSL client certificate, so that it is no longer available to 
   be automatically chosen by Thunderbird, or
b) selects "ask me every time" (which may only be an option in SeaMonkey,
   I'm not sure).  

Apparently, many users whose mail servers request SSL client certificate authentication do not implement SSL session caching correctly, with the 
result that their server requests client authentication on EVERY connection
from the MUA.  For a user who has selected "ask me every time" the frequency
of the cert selection dialogs makes his MUA unusable. 

The solution to these problems is to give the user the ability to configure
each account, one time, with his choice of certificate (including the choice NONE) to be sent every time that server asks for that account.  

Ideally, one solution would fit both Thunderbird and SeaMonkey.

I will add the numbers of related bug to the list of bugs depending on this one.

Comment 1

[J. Scott Berg]

(In reply to comment #0)

> b) selects "ask me every time" (which may only be an option in SeaMonkey,
>    I'm not sure).  

It is an option in Thunderbird, just not available from the UI.

Comment 2

[Hungerburg]

perdition, a popular imap-proxy, is an example of a server that is easy to be (mis)configured in a way to make the choice "do not authenticate with cert" a useful enhancement in thunderbird. several muas stumbled upon this one before, see there: http://article.gmane.org/gmane.mail.perdition.user/408

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Sounds like that "popular imap proxy" is aptly named. 

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

One of the differences between this bug (437683) for Thunderbird and bug
437685 for SeaMonkey is that Thunderbird UI has facilities to manage 
identities, which are separate from (orthogonal to?) mail/news accounts.  
Accounts seem to correspond to servers, and identities to email addresses.

In such an environment, configuration of a cert to be used for SSL client
authentication needs to be tied to both the identity and the server.  
Separate identities may well have separate certs on the same server,
and a single identity may have different client certs for one server than
for another, or may have a client cert on one server, but no client cert
for another server.  

Figuring out how to present this to the user is a UI challenge.
I personally like the idea that each identity/server combination is a 
separate account, with separate account configuration.  That's one reason
I use SM for mail/news.

Comment 6

[Magnus Melin [:mkmelin]]

SeaMonkey has the same identity system and manage identities in much the same way as Thunderbird, give or take a few unsynced fixes.

Comment 7

[David Ascher (:davida)]

I don't think this would block tb3, although it sounds like a good thing.

Comment 8

[David Ascher (:davida)]

adding link to current hot bug.

Comment 9

[David Ascher (:davida)]

Changing my mind on blocking flags based on the connection with large ISPs doing strange things, which I hadn't made.

Comment 10

[Joaquin Miller]

I'm sure it is clear to everyone that Thunderbird users who must use end-to-end encryption can't delete the certificate they use to decrypt incoming encrypted mail.  

That's one important reason for the third choice in Comment 1: Send no certificate.

Comment 11

[Joaquin Miller]

Thanks, David, for setting the blocking flag.

The AT&T+Yahoo! position is that their recent mail server configuration change has uncovered a design flaw in Thunderbird.

(I am trying to get to someone at AT&T or Yahoo! who will 1) hear that they ohave a problem and 2) fix it. But you folks, I'm sure, want Thunderbird to just work for users, regardless what large ISPs think.)

Comment 12

[Cyril Bouteille]

Is it possible to at least initially just to add the new option (3) "send no cert" (ever) (even if I have some defined) to the existing security.default_personal_cert property (globally) and get it in the next v2 patch? It's a real pain for Yahoo users to have to click cancel all the time...

Comment 13

[Stanley]

I don't even get a chance to click cancel. Yahoo just wouldn't let me send my Email.

Stanley

Comment 14

[Joaquin Miller]

Stanley:

I expect that you will find that the configuration item, security.default_personal_cert is not set to: Ask Every Time

If you do not see this window pop up, you need to change that configuration
item.

I believe you must use Firefox to do this; in any case, you can use Firefox.  

Type about:config in the address field  (colon, not dot); hit Enter
You will get a warning, and if you promise to be careful, will see your giant configuration file.
Type security.default_personal_cert in the filter field.
Double click on security.default_personal_cert.
Type Ask Every Time in the text field.
Click OK.
Close the tab.

(I wrote ask every time at the other bug.  I don't know if case matters. Ask Every Time works.)

Comment 15

[Joaquin Miller]

>>>>>>>>   Fellahs and Gals:  

Only one change to Thunderbird is required:

Add an option to the configuration item security.default_personal_cert: do not send any certificate

See Comments 5 and 10, where the problem at AT&T+Yahoo!is explained.

>>>>>>>  I hope someone will own making this small change to Thunderbird.
(Lots of us have been living with this for a third of a year now.)


(Additional--and better--suggestions are made at Comment 5 of Bug 456590, too.  It will be excellent when those are also implemented.)

Cordially, Joaquin

Comment 16

[David :Bienvenu]

taking, but I'm not sure this is going to happen for 3.0 - I worry that setting security.default_personal_cert: do not
send any certificate

should be per-account, and Nelson indicates that should be a per-server setting, which would require PSM support.

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

David,  

I'm not sure I understand your comment 16.  A per-account setting should 
work OK.  A user who has multiple accounts on a single server and chooses
to select "do not send any certificate" for one of them is likelt to do so
for all his accounts on that server, and so, as a per-account setting, the
user would have to configure each account.  That may be less than ideal,
but it would still be a WHOLE lot better (IMO) than not having any such 
configuration at all (where we are today).  I hope that helps.

Comment 18

[David :Bienvenu]

(In reply to comment #17)
> David,  
> 
> I'm not sure I understand your comment 16.  A per-account setting should 
> work OK.  A user who has multiple accounts on a single server and chooses
> to select "do not send any certificate" for one of them is likelt to do so
> for all his accounts on that server, and so, as a per-account setting, the
> user would have to configure each account.  That may be less than ideal,
> but it would still be a WHOLE lot better (IMO) than not having any such 
> configuration at all (where we are today).  I hope that helps.

Nelson, what does the mailnews backend code do if that pref is set? We don't have any code that decides to send a cert or not - so presumably, we have to call some sort of API that prevents the SSL layer from sending the cert.

Comment 19

[Eddy Nigg (StartCom)]

Per account should be OK. Consider that multiple different accounts at the same server don't have to behave necessarily the same.

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

I see.  OK.  I have no specific knowledge of the division of labor between
the mailnews back and and PSM.  I thought your comment 16 was saying that 
it would be easier to implement as a per account setting than as a per 
server settings, and I was merely saying that per-account is OK, too.
But if both are equally difficult, given that the relevant code in not in
the mailnews back end, then please ignore my comment 17.

Comment 21

[David :Bienvenu]

Yes, sorry for being unclear - per server, per account, per identity+server, I don't know how we would implement any of those. in any case, in the account manager, accounts and servers are pretty much the same thing; there's a one to one mapping. Identities can be mapped in different ways. We can call SetSecurityCallbacks on the transport, but that's about it as far as our ability to affect SSL is concerned.

Comment 22

[Joaquin Miller]

[I don't know the Thunderbird code.  I write as a user. Please excuse any ignorance.]

There are a lot of us that are stuck with what appears to be a configuration error at Yahoo! mail servers.  This affects many whose ISPs use Yahoo! for e-mail.

Today we start Thunderbird and a window pops up, User Identification Request, which (I assume) is generated by Thunderbird.

We check Remember this decision and click Cancel.   As I understand, Thunderbird then, since we have not chosen a certificate, sends no certificate.  Then we can connect to check for mail.  We may get be required to do this little dance again when we first send mail.

We don't see the window again (at least, not as long as the mail servers remember us).

So, it seems to this ex-programmer that it must be pretty easy to set a configuration option which, instead of popping up the window, just returns no certificate.  The handle in the code must be where this window is popped up.

Ths simple configuration addition will help the many people who use one account (or more) with their ISP.  It will help people who have this problem and also have other accounts on servers that do not request a certificate. There may be a few users who have an account with this problem and another account that requires that a certificate be returned.  This simplest fix won't help them.

.......

Please don't delay a simple fix while waiting for a more elegant fix.  

This simplest fix will help many people.
It will remove an irritation that can't help Thunderbird to spread.

.......

Thanks, folks, for your work.

Cordially, Joaquin

Comment 23

[Mark Rousell]

I agree with Joaquin -- I support end users and this is really annoying those who have S/MIME certificates.

Comment 24

[David :Bienvenu]

here's the code that checks the existing pref:

http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSIOLayer.cpp#2447

Nelson, I don't see any other alternative than to allow Thunderbird users to globally set this pref to "don't send" for client certs. Is that an avenue worth exploring? The other option I can imagine is to allow per-host overrides in this code, perhaps by having per host prefs, but I don't know what the chances of getting that change into this file are.

Comment 25

[Joaquin Miller]

David Bienvenu: The simple global "don't send" will help lots of users.  Now these users must remember to check the box and click Cancel--not OK.  If a user every slips up and clicks OK, they must exit Thunderbird and restart.

David Ascher: Yes.  Please keep this blocking Thunderbird 3. Thanks.

Thanks again for the work, folks!

Comment 26

[Nelson Bolyard (seldom reads bugmail)]

David,  seems to me that a good design might work like this:
1) First, see if there is a pref for this host.  If so, obey it.
Otherwise,
2) obey the existing global pref as a fallback.  

Perhaps this function needs additional parameters for host name,
or Perhaps another function should be called first.  It's all a SMOP.
Let's ask Honza for his advice on how best to change this in PSM.

Comment 27

[David :Bienvenu]

Honza, ping? If we don't get traction on this really soon, we're going to miss our string freeze date for tb 3. I don't know how possible it is to get into PSM either...Nelson, who were you thinking would do the PSM part of this bug?

Comment 28

[Joaquin Miller]

I can see that this item is about offering flexible control.  Please forgive me for being off topic.  Please forgive me for repeating myself.  

I write because this item is blocking tb 3, but Bug 456593 is not.  4546593 needs a much simpler fix that this item asks for. 

If the flexibility called for here can make it into tb 3, great.  I hope at least a minimum change to let users work around the misconfiguration at AT&T+Yahoo! will be in tb 3.  

This can be very simple.  All we need is a single global "don't send" that is checked whenever Thunderbird is about to display the User Identification Request dialog.  The effect of the don't send setting can be the same as if the user checked Remember this decision and clicked Cancel.  (If this does not work for those who need flexibility, they are no worse off.  At the same time, many will benefit.)

My guess is that there are only two places that need to be changed, one in checking mail and one in sending mail.

Please don't hold up the simple fix for something nicer.

Thanks.

Comment 29

[David :Bienvenu]

Perhaps we could do that for Thunderbird. I don't know if it's a good idea for SeaMonkey since it controls browser behavior as well. Nelson could probably describe the bad things that would happen if we turned that pref on - we would also have to think about html in mail.

Comment 30

[Honza Bambas (:mayhemer)]

After bug 295922 has been fixed the *global* client cert selection behavior option has changed for all moz applications (not sure about Thunderbird) to show a dialog to choose a cert for each secure connection. The user decision is kept as long as a related ssl session is cached (AFAIK).

If those who suffer from this bug will switch that option manually to "send no cert" I am not against to introduce this new option. Just to let you know:
- when you do it in Thunderbird, you cannot any longer authenticate to mail servers that require a client cert
- when you do it in SeaMonkey, the browser won't sent client certs e.g. to the bank server and won't let you change that decision

To have a better solution we should do decisions per host[+identity] mapping and remember it in the preferences, it's a lot of work, but I believe it is the most correct solution. It needs changes to PSM API and I have no idea how to pass the "identity" part to PSM.

What appears strange to me is that a client cert for a completely different CA and/or a different purpose is sent to the server. Is it likely that the filtering is wrong? Certificate for decryption purposes should never be used for ssl client authentication.

Comment 31

[Joaquin Miller]

FYI: My only (unexpired) cert in CertificateManager YourCertificates is marked, according to CertificateViewer: Email Signer Certificate, Email Recipient Certificate. (The others are the previous years Class 1, now expired.)

That is, I do not have any authentication certificates.

(I do know that in the past Class 1 certificates issued by VeriSign, by a goverment research corporation, and by the government, somehow showed up under WebSites, instead of under OtherPeople's.  This may be unrelated.  And they are all now expired.)

Comment 32

[Nelson Bolyard (seldom reads bugmail)]

As you know, there is a significant number of bugs related to cert selection
for client auth.  One of those bugs (which may have been fixed by now) was 
that when you don't use automatic cert selection, and select a cert by its
nickname, the code that later attempts to honor that selection does not 
check to ensure that it is using a cert that is valid for SSL client auth.
It just uses any cert with the right nickname.  That needs to be fixed.
I'd say it's a prerequisite to any other bugs about client auth.  

I'd site the bug number, but I can't find it at the moment.  We have many 
bugs about client auth, but they're not well organized (IMO) by the real
underlying problems.

Comment 33

[Eric Woodruff]

As a Thunderbird user, I'd like to point out that there are scenarios where Thunderbird needs to present certificates to web servers, not just email servers. In my situation, the Bugmail add-on connects to Bugzilla, which requires an SSL certificate to authenticate. Adding the certificate to Thunderbird unexpectedly causes all SSL mail account connections to now prompt for a certificate, as well as any LDAP server requests (which is very annoying when tying a mail recipient). In some cases, like selecting the certificate for use with my smtp server, it causes the connection to fail with error -12195.

Comment 34

[Eric Woodruff]

Also, the "Remember my decision" check-box is always selected, but seems to make no difference. It doesn't seem to remember that my decision was to "Cancel" so that no certificate is sent.

Comment 35

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 33:
> In my situation, the Bugmail add-on connects to Bugzilla, which
> requires an SSL certificate to authenticate.

Eric, You are referring to your own bugzilla installation, and not to 
bugzilla.mozilla.org, right?

Comment 36

[Eric Woodruff]

(In reply to comment #35)
> Eric, You are referring to your own bugzilla installation, and not to 
> bugzilla.mozilla.org, right?

That's right.

Comment 37

[Zhang Weiwu]

Hi. The typical case that TLS server asks for client certificate while thunderbird offer user to choose from a list of PGP certificates that none gonna work is frastrating for admins like me. At the moment I either have to configure email server to not to ask for client certificate or recommend user switch to Outlook Express (damn). So I try to change email server configuration.

For those other frustrated email admin went to this bug posting through google like me, if you run Cyrus imap server, there is no option to stop it asking for client certificate! There is a more-than-4-years-old patch for this issue but never seems get to the patch acceptance pipeline:
https://bugzilla.mozilla.org/show_bug.cgi?id=437683

I hope cyrus have such an option and people push them to add this option too.

Comment 38

[Zhang Weiwu]

Sorry, wrong link in last message. Should be:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2642

Comment 39

[Nelson Bolyard (seldom reads bugmail)]

Zhang, You say that your server asks the client to authenticate, but then 
rejects the certificate sent by the client.  A properly coded and configured
server will send out a list of CAs whose certs it will accept.  Then, the 
client will only send back a client auth cert if it has one from one of those
named CAs.  If the client is sending back "PGP" certs, it means that your 
server is sending out an empty list of CA names, which implies that the server
will accept ALL client certs.  So, your server says "send me any client cert
you have and I'll accept it", but then it does not accept the cert it receives.

Now, that wouldn't be so bad, if the server allowed the connection to go 
forward when it gets an cert it doesn't like, but your server then drops the 
connection.  This is two server errors:
1) asking for certs it will not accept
2) failing the handshake when it gets a cert it will not accept, instead of
allowing the handshake to complete normally and then request another form of
authentication, such as a password. 

I suggest that you see if it is possible to configure your server to send out a list of names of CAs whose certs it will accept.  If so, then give it a name of a non-existent CA.  That will stop the clients from authenticating with certs.

Comment 40

[Zhang Weiwu]

You explained the case exactly as I faced it, thanks for more detailed explanation which would be important reference for other readers. In my post I am not complaining to Thunderbird, because from my level of understanding it didn't do anything "wrong". The reason I post this is because when I try to configure the server right I followed google to this bug and thinks other people probalby also does the same, so I share my experience on getting the server working right way HERE.

I think in my post I failed to show my complaints directs to mail server. I also want other readers be aware this issue rooted on server side.

Comment 41

[Joaquin Miller]

You are right, Zhang (and, of course, so is MisterSSL).  There are certainly serious problems with mail servers.

There is also a problem with Thunderbird.  The Thunderbird problem is that it, so far, insists on interoperation only with standards compliant mail servers. (Well, Thunderbird will interoperate with these broken mail servers if users carefully perform a magic dance twice each time they start Thunderbird.) 

Hundreds of thousands of people, probably many times more, must live with broken mail servers.  They, for reasons good enough for themselves, use mail servers operated by large providers such as AT&T and Yahoo!, who will not correct the behavior of their mail servers. (Myself included.)

If Thunderbird wants to be different from these large providers, it can implement the configuration options specified by Nelson last summer, in the first comment  of this bug.

Cordially, 

Joaquin

Comment 42

[Eddy Nigg (StartCom)]

Pardon me, but can you clarify that you attempt to send a PGP key to the server? Or did you mean a S/MIME client and authentication certificate?

Comment 43

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 42, Eddy, to whom was your question directed?

Comment 44

[Eddy Nigg (StartCom)]

It was in reply to comment 37 and comment 39.

Comment 45

[Zhang Weiwu]

> Pardon me, but can you clarify that you attempt to send a PGP key to the
> server? Or did you mean a S/MIME client and authentication certificate?

Honestly I don't know what you are asking. I don't attempt to send PGP key to the mail server, the Thunderbird offers me to do so (and for a reason too, which was explained in 38).

Comment 46

[Eddy Nigg (StartCom)]

(In reply to comment #45)
> Honestly I don't know what you are asking. I don't attempt to send PGP key to
> the mail server, the Thunderbird offers me to do so (and for a reason too,
> which was explained in 38).

OK, all clear. The server asks for a S/MIME client certificate, not PGP key.

Comment 47

[Mark Banner (:standard8)]

The Thunderbird drivers wish to release Thunderbird 3 as soon as possible. As a
result, we feel that this bug shouldn't stand in the way of all the other good
work getting into the hands of users sooner rather than later. Therefore we are
retargeting it for 3.1. See http://ccgi.standard8.plus.com/blog/archives/242
for more details. The 3.1 release is expected to be a quick release soon after
Thunderbird 3.

Comment 48

[Joaquin Miller]

In posting this bug, Nelson proposed a general fix:
The configuration for each email/news account should include:
  - choose automatically, every time (default)
  - ask me every time 
  - Send no certificate (do not authenticate with a certificate)
  - Use this certificate [ list box of usable SSL client certs ]

The Thunderbird drivers feel this proposal should not stand in the way of release of Thunderbird 3.  

My technical quesiont: If we accept that, is there some reason not to implement, for Thunderbird 3, the simpler solution to Bug 456590 (SMTP), Bug 456593 (POP), and for IMAP users?

All that is necessary to resolve 456590 and 456593 is to add a single configuration editor choice (not a per account configuration) to set
   security.default_personal_cert 
to 
   Send no certificate

That is, do not authenticate with a certificate,

Adding this option won't harm anyone who uses a certificate for authentication.  It will enable those who use a certificate only for encryption to live with stubborn AT&T+Yahoo!, without having to do the magic dance of canceling the User Identification Requests.

Few AT&T Yahoo! customers use certificates for authentication. Many use certificates for encryption.

Comment 49

[Joaquin Miller]

My process questions: 

What does it mean that this Bug 437683 is blocking Bug 456590 and Bug 456593?

Can't 456590 and 456593 be fixed in Thunderbird 3, without fixing 437683?

456590 and 456593 are Assigned To: Nobody; OK to take it and work on it
Is there anyone who will work on adding the config option described in comment #48 to Thunderbird 3?

set
   security.default_personal_cert 
to 
   Send no certificate
(not a per account configuration) 

Thanks everyone. Please forgive my ignorance of how Blocks: is used.

Comment 50

[Andrei Boros]

Consider this : 
2 mail accounts, 2 SMTP servers, each accepting SSL connections with
authentication based on SSL certificate. 
Both certificates installed in TB, but there is no way in the UI to associate a
certificate to a server connection. 

Consequently, only one account works, the other fails authentication because
the wrong certificate is used. Apparently TB uses the first one it finds in the
list (?) but unsure. 

Please reconsider priorities on this one.

Comment 51

[Joaquin Miller]

Of course, Andrei is correct in Comment #50.  The simple fix will not solve the problem for users who have accounts on two servers, one server misconfigured (like AT&T Yahoo! and others) and the other server requiring an authentication certificate.

But the proposed configuration change will not harm those users.  They simply don't use it. Nor will the proposed change interfere with work on the improvement proposed by Nelson, which will solve the problem posed by Andrei.

Meanwhile, everyone who does use an encryption certificate and does not need an authentication certificate will be helped.

Comment 52

[Magnus Melin [:mkmelin]]

I don't think a "silently ignore such cert requests globally" is an option. There would be major pain to figure out what's going on if you later at some point want to add an account that uses client certs, or when browsing web content inside tb, or when someone just clicked it to see what it did, and forgets to change it back.

Comment 53

[aldebx]

Are there any updates on this issue?

Thunderbird 3.0 is approaching and I cannot see any improvement on this side. 

I either have to not use any certificate or always hit cancel if not willing to authenticate ssl with my own certificate. 

This is indeed annoying, especially given that along with "select automatically" and "ask every time" developers could easily add "never use certificates" into options (even hidden into the about:config would still be really appreciated!) Thanks!

Comment 54

[Andrei Boros]

In TB 2.0.0.23 I see some improvement. The first time during a session I am asked which certificate I want to use for that connection. (older behaviour was to just use the first one in the list). 
There is a checkbox "remember this decision", but it only applies to the current session. Next time when I start TB, I will be asked again. 

Not a setting in accounts prefs, yet, but a step in the right way.

Comment 55

[Honza Bambas (:mayhemer)]

So, it seems that many people have agreed the simplest solution would be to have an option to automatically "Do not send any certificate".

We can create a silent (no UI) option modifiable only from about:config. 

Nelson, would you agree? This should be relatively simple change.

Comment 56

[Andrei Boros]

Still, automatically "do not send any certificate" does not help much those who indeed use certificates ...

Comment 57

[Honza Bambas (:mayhemer)]

This would be a first stage solution (I had to be specific about that in my comment).

Comment 58

[Joaquin Miller]

I want to urge the creation of the simple option.  As soon as practical.

Nelson's proposal is definitely correct and useful.  When it can be implemented
it will cover many, perhaps all cases.

Until then, please help us poor folks stuck with the stubborn mail providers,
who won't correctly configure their servers.

Andrei is correct, this won't help many people who use certificates.  

But it will help those of us who MUST use certificates for encryption and who are stuck with mail providers who ask for a certificate for identification, even though they don't really want one (not from us anyway).

Seeing the pop-up and canceling so as to send no certificate is what us folks have to do twice every time we start Thunderbird.  (If we get sloppy and click OK, then we must close and restart Thunderbird.) 

Thanks for the work.

Comment 59

[Nelson Bolyard (seldom reads bugmail)]

I don't understand why there is such tremendous resistance to fixing this bug
the right way (as described in comment 0 and summarized in comment 48), but
that resistance clearly exists and has kept this bug from being addressed for 
18 months now, amazingly.  I believe that a lame partial fix will reduce or 
eliminate the pressure to completely fix this bug, and therefore is a bad 
thing, but I think that having NO fix for much longer is far worse, so I do
NOT oppose Honza's proposal in comment 55.

Comment 60

[David :Bienvenu]

I don't see any resistance to fixing this the right way. I'm not a module owner in this area, but as far as I'm concerned, patches fixing this the right way are more than welcome.

Comment 61

[Andrei Boros]

I'm sure patches are always welcome. 
Myself I don't want to resist a potential fix, but neither do I want to happen that a partial fix postpones the other aspects of the problem for who knows how long. 

IMHO, the proposed fix in comment 55 probably helps some people, so why not. 

On another hand, I would also welcome a fix for what I described in comment 54, seems very similar in nature.

I'm only sorry I don't know enough programming, for I'd tackle some of these myself and propose some patch.

Comment 62

[Dan Mosedale (:dmose, :dmosedale)]

While I'd love to see a patch for this land, 3.1 is mostly about providing something that Thunderbird 2 users will be comfortable upgrading to.  Since this isn't a regression from Thunderbird 2, marking it as blocking-, but wanted-thunderbird+.

Comment 63

[Ron Sidell]

Its been over a year since the last comment on this bug.  I stumbled upon the bug yesterday when I installed a client certificate for email signing and encryption.  It appears that nothing has been done to address this problem?! Why not? Where did all of those people go, who cared so much about a fix?  I just would like to know if there is any hope of getting this addressed in the near future.
Thanks for your attention

Comment 64

[Onno Ekker [:nONoNonO UTC+1]]

I get prompted for a certificate when I start Thunderbird Chat in version 14.0a2 (Earlybird). I Cancel the request only to get prompted again on next start.

Comment 65

[Nhat Anh Huynh]

Tools > Account Settings... in ThunderBird.

 - press Add Account..., chọn Email account và nhấn Continue để tiếp tục.

 - type your name in Your Name, type your you mail's address (ex: [e-mail]) in Email Address and press Continue.

 - Select POP in Select the type of incoming server you are using, type localhost hoặc 127.0.0.1 in Incoming Server. press Continue.

Comment 66

[hostmaster]

More problems with Thunderbird (17.0.8): If IMAP server asks for client certificate and retrieves username from certificates subject it is impossible to have multible accounts on a single server.

This szenario prevents user from using multiple IMAP accounts on same server. To set up a secure 2 factor authentication it is mandatory that client certificates for authentication may be assigned to each account.

This is really a shop stopper to use Thunderbird with client certificates.

Comment 67

[Wayne Mery (:wsmwk)]

bmurali,
do you have any insight on this?

Wow.  blocking bug 511384 is in the graveyard, and the comments read more like BUG than ENH.
Is this really still a thing?
Are anything from https://mzl.la/1Tbut7i missing in the dependency list?