Open Bug 1209482 Opened 9 years ago Updated 2 years ago

No way to permanently disable/deny certificate identification requests

Categories

(Thunderbird :: Security, defect)

38 Branch
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: shapeshifter, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150827193320

Steps to reproduce:

I have a dozen email accounts in thunderbird and today, rather suddenly, I ran into a really annoying problem. Everytime I start thunderbird, I get a dialog like this:

--- User Identification Request ---
This site has requested that you identify yourself with a certificate:
*.your-server.de (:143)
Organization: ""
Issued Under: "GeoTrust Inc"

Choose a certificate to present as identification
[Combobox with my only certificate which has nothing to do with your-server.de as the only option]

Details of the selected certificate:
[A bunch of cert infos]

[v] Remember this decision

[Cancel] [OK]
---------------------------------

If I click Cancel, it goes away but when restarting Thunderbird, the dialog returns.

I do NOT want to identify myself to this server with any certificate. I use the certificate I have to sign/encrypt emails on a different account that has nothing to do with my account at your-server.de. It is not necessary anyway, since the server authenticates fine via STARTTLS or SSL/TLS.

I googled the issue and found plenty of really old postings (2008 and earlier) with people suggesting going to Preferences->Advanced->Certificates and setting "When a server requests my personal certificate" to "Select one automatically", but this is not what I want. As I said, this server has no business seeing my unrelated certificate and it should be possible to permanently deny its request.

The settings of the account at your-server.de are
 Server Name: mail.your-server.de, Port: 143 (or 993)
 Username myuser@mydomain.de
 Connection security: STARTTLS (or SSL/TLS)
I.e. it doesn't matter if I use SSL or STARTLS, the message appears anyway (with the port depending on the setting).

There should be an option to ignore/deny certificate requests by servers permanently.

Honestly I'm confused why I'm running into this problem now, since I've been using thunderbird in its current account configuration for several weeks. My assumption is that the admins at your-server.de enabled this request on the server side recently.

Some system info:
thunderbird 38.2.0 built August 15, 2015
openssl 1.0.2.d built July 09, 2015
linux 4.2.1 built September 22, 2015

Related bugs and forum posts:
http://forums.mozillazine.org/viewtopic.php?t=652927
https://bugzilla.mozilla.org/show_bug.cgi?id=431819
https://groups.google.com/forum/#!topic/comp.mail.imap/UNj2yMbrqyA


Actual results:

The dialog keeps popping up every time


Expected results:

There should be an option "deny request" which is remembered permanently for the given server.
A possibly related issue, that I am seeing in current trunk (on MacOS) is that it does not remember the decision, in the case where you have multiple certs and choose one.

I have multiple S/MIME certs for sending email. First email I send in any TB sessions, it asks me to choose one, which I do. I click "remember this decision", but it forgets.

FYI: This was recently fixed in Firefox, so maybe the fix carried over to TB too. See bug 634697

This should be in code that is shared by FF and TB.

I see it was fixed in FF 81. Could you experiment with TB 83 beta (please make sure you use a separate user profile, separate from your primary stable 78.x settings), and check if it already works in the way you expect?

See Also: → 634697

After updating from Thunderbird 78 to 91 last week, I can happily confirm that this problem with the dialogue box frequently popping up whenever certain accounts (in my case it was an old AOL/AIM mail account) check for mail are no longer a problem. I think Kai is right and the shared code from FF81 applied correctly to Thunderbird, too.

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