Open Bug 437683 Opened 16 years ago Updated 2 years ago

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

Categories

(Thunderbird :: Account Manager, enhancement)

Product:
Thunderbird
Component:
Account Manager
Type:
enhancement

Tracking

(blocking-thunderbird3.1 -)

Tracking Flags:
Tracking Status
blocking-thunderbird3.1 --- -

People

(Reporter: nelson, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [psm-auth])

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.
Flags: blocking-thunderbird3?
OS: Windows XP → All
Hardware: PC → All
(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.
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
Sounds like that "popular imap proxy" is aptly named.
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.
Summary: Select SSL client certificate in account configuration → Select SSL client certificate in account/identity configuration
SeaMonkey has the same identity system and manage identities in much the same way as Thunderbird, give or take a few unsynced fixes.
I don't think this would block tb3, although it sounds like a good thing.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
adding link to current hot bug.
Blocks: 456590
Blocks: 456593
Changing my mind on blocking flags based on the connection with large ISPs doing strange things, which I hadn't made.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
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.
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.)
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...
I don't even get a chance to click cancel. Yahoo just wouldn't let me send my Email. Stanley
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.)
>>>>>>>> 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
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.
Assignee: nobody → bienvenu
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.
(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.
Per account should be OK. Consider that multiple different accounts at the same server don't have to behave necessarily the same.
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.
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.
[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
I agree with Joaquin -- I support end users and this is really annoying those who have S/MIME certificates.
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.
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!
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.
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?
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.
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.
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.
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.)
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.
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.
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.
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?
(In reply to comment #35) > Eric, You are referring to your own bugzilla installation, and not to > bugzilla.mozilla.org, right? That's right.
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.
Sorry, wrong link in last message. Should be: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2642
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.
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.
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
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?
In reply to comment 42, Eddy, to whom was your question directed?
It was in reply to comment 37 and comment 39.
> 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).
(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.
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.
Flags: blocking-thunderbird3.1+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
Depends on: betterclientauth
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.
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.
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.
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.
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.
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!
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.
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.
Still, automatically "do not send any certificate" does not help much those who indeed use certificates ...
This would be a first stage solution (I had to be specific about that in my comment).
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.
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.
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.
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.
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+.
blocking-thunderbird3.1: --- → -
Flags: blocking-thunderbird3.1+ → wanted-thunderbird+
Whiteboard: [psm-clientauth]
Whiteboard: [psm-clientauth] → [psm-auth]
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
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.
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: example@yahoo.com) 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.
Blocks: 490429
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.
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?
Assignee: mozilla → nobody
Flags: needinfo?(bmurali5128)
Summary: Select SSL client certificate in account/identity configuration → Selection choices for SSL client certificate in account/identity configuration (or Option to automatically "Do not send any certificate"?)

It seems no one previously associated with this bug is in contact or has useful information

Flags: needinfo?(bmurali5128)

This bug is still relevant in Thunderbird 68.6.0. When I log into my Yahoo! account, Thunderbird asks me every time whether it should use my S/MIME certificate (which is for a different e-mail account) for the log in. In the dialog, I have to click on cancel to get to the regular password prompt. I would really appreciate if I could select to show no certificate in that dialog and if Thunderbird could remember that choice.

This has become really annoying in Thunderbird 78. In Thunderbird 68, it only asked for the certificate on startup, but in 78.4.1, it asks for the certificate every couple of minutes; probably every time it is checking for new e-mails in that account.

A personal (invalid, self-signed or otherwise) X509 certificate with the sole intended purpose of S/MIME message signing or encipherment (emailProtection OID) is still in November 2020 (TBIrd v78.5.0 64 bit Win) incompetently selected for presentation as CLIENT AUTHENTICATION to an asking mail server - even when the TBird server setting in the client is to authenticate by 'normal password'

The selection is incompetent because any certificate is offered for presentation in the server initial SSL/TLS handshake on port 995 whether it is relevant to the POP3 account or not.

Any by any I mean specifcally an X509 S/MIME certificate which has been specifically created with extensions to ADD emailProtection trust and REMOVE clientAuth and serverAuth trust. The only standards-approved role for the certificate is therefore emailProtection - honoring these X509 extensions should be sufficient to fix this issue, of course.

The selection occurs whether the POP3 account has a selected S/MIME certificate for the default main identity or any sub-identity or not. If a personal certificate exists in the Software Security Device it is selected and presented to the server whether the email address of the personal certificate matches the main or default email identities of the POP3 account or not. ( it is either silently selected or the only option presented in the 'ask' pop-up).

The hack UI fix seems to be to clearly distinguish the intended role of the personal S/MIME certificate ( even though OIDs may be present in the certificate itself that pre-define and constrain these roles already) - the role list (at importation time) needs to be extended to include the rare use case of 'server authentication', so it can be excluded. That dialog could also respect the OID extensions that already pre-determine the certificate role or not.

UPDATE
I created another personal S/MIME certificate via CSR from my personal self-signed CA, except this time I used the openssl magic

openssl x509 -req -sha256 -days 3650 -in smime.csr -CA ca.crt -CAkey ca.key -set_serial 1 -out smime.crt -setalias "Self Signed SMIME emailProtection use only" -addtrust emailProtection -addreject clientAuth -addreject serverAuth -extfile email-extensions.txt -trustout

where email-extensions.txt contains two lines

--
extendedKeyUsage=1.3.6.1.5.5.7.3.4
keyUsage=digitalSignature

which results in a key which contains valid X509v3 key usage constraints. The OID 1.3.6.1.5.5.7.3.4 is 'emailProtection'
http://oid-info.com/get/1.3.6.1.5.5.7.3.4

Now, with the certificate response setting set to 'ask every time', nothing is asked for, as expected.

Further research about the recipe to use the -addtrust, -addreject, -trustout and -alias flags reveals that

a) they are NOT part of the X509v3 spec
b) they are OpenSSL-specific additions and can be ignored
c) they should only be used when making root CA certificates, not for end-user certificates

So Thunderbird appears to be working and respecting the actual X509v3 key usage constraints.

This is further confirmed because this certificate can ONLY be used for digital signing, and Thunderbird prevents its selection as a mail encryption certificate.

I'll generate another certificate that adds encipherment to the usage constraints and see if that certificate brings the problem back, but a sign-only seems not to have the mail server problem.

OK, another personal certificate as above, but this time the extfile contains

extendedKeyUsage=1.3.6.1.5.5.7.3.4
keyUsage=digitalSignature,keyEncipherment
nsCertType=email

and the POP3 mail server prompt does not appear. I assume nsCertType is deprecated, but it still seems to be there in the OpenSSL code at 1.1.1l, so I added it.

Thanks for this work, Aldus.

When this is taken care of, please tackle Bug 188988, encrypted emails are not searched. That one has been, for some eighteen years, crippling Thunderbird users who must use encrypted e-mail.

(I gave up some years ago trying to get across the principle that privacy in transit and privacy at rest are two different problems and call for two different solutions. The folks who have the ability and willingness to work on this bug--and are working on it now or recently--appear to be committed to continuing to prohibit users from having the option to store all messages, decrypted, on their encrypted storage devices. Using encrypted storage for privacy, with messages in the clear for Thunderbird (and other software) to search.)

I know this is a 13 year old bug report, but it's still an open issue.

I have 4 IMAP accounts:
Account #1 - IMAP mail server, has a PGP cert
Account #2 - IMAP mail server, has a S/MIME cert
Account #3 - Gmail
Account #4 - Office 365 Outlook, IMAP enabled, MFA with app passwords

All accounts work fine... except Account #4. I can receive emails perfectly fine... except when I send an email I get the pop-up dialog box "User Identification Request" and it presents the S/MIME certificate for Account #2. This cannot be correct because they are unrelated and different email addresses.

If I click Cancel, the dialog box goes away and the mail is sent successfully. So sending mail works, but the dialog box is a real annoyance.

After 13 years, is there going to be a plan to fix this?

Thanks.

I just started hitting this issue but I did nothing for that... I got that PKCS#11 popup every 10-15 minutes now . Well , I did move my .thunderbird folder to another computer . Is there something I can technically do to solve this ? Will it ever get fixed ?

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.