267923 - Thunderbird IMAP/SSL login will not permentantly accept a unsigned certificate

Status: RESOLVED DUPLICATE of bug 255025

(Thunderbird :: General, defect)

Description

[Chris Josephes]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

When logging into a local IMAP server using a self-signed SSL certificate,
Thunderbird will not let you choose the option to "Accept This Certificate
Permenantly".  It will let you accept the certificate temporarily.  It will also
bring up the error that it cannot verify the identity of the remote site.

One possible error in the certificate is that it has an empty CN field.  Other
than that, the certificate works.


Reproducible: Always
Steps to Reproduce:
1. Log into private IMAP server
2.
3.

Actual Results:  
Thunderbird will let you click on the "permentant" option, but it won't let you
finalize the choice.

Expected Results:  
Thunderbird should accept my chosen actions since I understand the error
involving the certificate.

Comment 1

[Christophe Porteneuve]

It works fine with me, on a self-signed certificate.

Try checking the options in Tools | Options | Advanced | Certificates: Manage
Certificates | Web Sites. Try editing the certificate for your IMAP server. What
does it say? Trust or do not trust? If not, try setting it to Trust, saving and
retrying (possibly after restarting TB). Does this help?

Comment 2

[Noel]

A variation on this bug is that it is not possible to accept a mismatched
certificate permanently. For firewall reasons, I run a local proxy that connects
to www.messagingengine.com - which presents its (valid) certificate. However as
the remote hostname is seen as localhost, Thunderbird brings up a warning.
Outlook Express does this too, but once you accept the mismatch it will not ask
again for the remainder of the session.

With Thunderbird, it repeatedly asks for confirmation - presumably once every
time it establishes a secure IMAP or SMTP connection making it very frustrating
to use. An option should exist to:
1. Accept the certificate mismatch for the remainder of the session or to
2. Permanently accept the certificate mismatch

Comment 3

[Christophe Porteneuve]

This is pretty weird.  My TB presents a mismatch dialog on first connection, but
not on later refreshes.  I get prompted only once per session.  However, I *do*
want to be able to accept this permanently!

BTW, Scott, why don't you move that to ASSIGNED, or even just to NEW?! This
UNCONFIRMED status for 3 months is just ludicrous!

Comment 4

[Mike Brown]

I am getting the same behavior; you can select to permanently accept, but you
just keep getting prompted again right away; it never really gets accepted until
you choose to temporarily accept for this session.

The cert in question does not have CN or OU fields defined. Apparently the lack
of CN field (which is typically the FQDN and is checked against the name used to
access the server, I believe) is the problem. Thunderbird is considering it a
mismatch.

Christophe Porteneuve suggests "Try checking the options in Tools | Options |
Advanced | Certificates: Manage Certificates | Web Sites. Try editing the
certificate for your IMAP server." -- but the certificate does not appear there,
even if it was accepted temporarily for this session. The only place where the
cert can be viewed is when being prompted whether or not to accept it. As I
mentioned, the only thing unusual about the cert is that CN and OU fields are
showing as not defined.

Comment 5

[Jack Eidsness]

Why not just create a valid self-signed certificate with a correct CN?  The CN
really shouldn't be empty . . . I'm surprised openssl (i'm guessing) would
create a certificate like that. 

If we were to accept this lower standard, for empty CN's, or permanently
ignoring a hostname mismatch, the next logical step would be to have the "other"
name be stored in the config somewhere, so if it is ever a different mismatched
name, you would be alerted to the potential security breach . . . but of course
with the benefits of the PKI.  It's just not a road that you want to go down.

  I don't think SSL is what you want, if all you want is encryption . . . as it
happens, an encrypted VPN or SSH tunnel seems to be more what you are looking
for, but those are ironically less convenient.  :(

  This does seem to emphasize the (percieved) vacuum for trivial encryption with
no identification infrastructure, but generally the people capable of creating
these things are capable of seeing the importance of these other layers of
security.  i.e. anyone who is capable of sniffing your traffic should very
likely to be capable of a man-in-the-middle attack, and therefore, if there was
a mass-market encryption-with-no-host-verification product, it would invite the
black hats of the world to trivially defeat it by that method.  I certainly
sympathize with whatever your SSL problem may be, but I wouldn't want
thunderbird to become that product.

I admit, the bar for entry to the world of SSL service configuration may be a
bit high, but it is important that it stay there for the benefit of millions of
casual users.

I suggest this become a WONTFIX.

Comment 6

[Ingemar Nilsson]

Even if I follow your line of thought about the empty CN field, I think that
there is still a bug there. If the certificate cannot be accepted for any
reason, please tell the user, instead of letting them select "Accept
permanently" and then ignoring it.

The current behaviour of letting the user accept the certificate permanently,
and when they click OK show the same dialog again with the "Accept temporarily"
radio button checked, is not acceptable. Clear and usable error messages should
be promoted.

I suggest something along the line "The server presented an incomplete
certificate. This certificate cannot be accepted permanently. Contact the server
administrator if the problem persists". This should also make the "Accept
permanently" radio button disabled.

Comment 7

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 255025 ***