307977 - Cannot "accept permenantly" an expired certificate

Status: RESOLVED DUPLICATE of bug 92410

(Thunderbird :: Security, defect)

Description

[Albert H]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

When retrieving mail through port 995 using SSL/POP3, if the server certificate
is expired, the user cannot select "Accept Certificate Permanently".  Selecting
this option simply causes the message to re-display.  Only accepting the
certificate temporarily works, but then must be repeated each time email is checked.

Reproducible: Always

Steps to Reproduce:
1. Use a pop3/ssl server with an expired certificate.
2. Attempt to download email.
3. Click OK on the "Server Certificate Expired" dialog.
4. Select "Accept this certificate permamently" on the "Web Site Certified by
Unknown Authority" dialog.

Actual Results:  
"Web Site Certified by Unknown Authority" dialog is redisplayed.

Expected Results:  
Certificate should be saved by the program and the program should proceed to
download the email via SSL.  The user should not again be prompted, either in
the current or future sessions.

This problem is similar to bugs 221552 and 292249.  The end result may in fact
be the same result, but the path to the dialog is different in that in this case
it is an expired certificate that leads to the problem.
Below, I selected "A major feature is broken" because this prevents the program
from automatically checking email at specified intervals.

Comment 1

[Adam Guthrie]

Could you be seeing bug 225849, or do you have the master password set?

Comment 2

[Albert H]

Attachment: First dialog screen shot

Comment 3

[Albert H]

Attachment: Second warning dialog

Comment 4

[Albert H]

(In reply to comment #1)
> Could you be seeing bug 225849, or do you have the master password set?

I didn't have a master password set.  I tried setting one. It did not resolve
the issue. The dialog warnings come up before the master password is requested,
so it would seem unrelated to the master password. Also, 225849 looks more
related to web pages than email.

Comment 5

[Adam Guthrie]

Okay. Possibly a dupe of bug 221552, then?

Comment 6

[Albert H]

(In reply to comment #5)
> Okay. Possibly a dupe of bug 221552, then?

Possibly so.  The cause is slightly different (unverifiable certificate rather
than expired one), but the end result is the same.  The program will not allow
the user to permanently accept the certificate, though the option appears on the
dialog.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Albert, Please test this possible workaround.
Visit this URL:   https://specta.swgo.net:995/
You'll get a similar first dialog and the same second dialog.
Tell the second dialog to accept the cert permanently.  
Wait a bit (the page will appear to be continuously loading), and then stop
the page loading.  
Then try the POP3/SSL connection again.   Maybe it'll be better then.

Please let us know the outcome of that experiment.

BTW, in this case, the server cert is self-issued, so the problem is neither
expiration of this cert, nor expiration of the issuer (this cert is its own
issuer).  Consequently we know that this is NOT a regression caused by the
fix for bug 216701.  

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

This bug and bug 221522 have in common that both used a self-issued server cert.  
This one has the additional wrinkle that the self-issued cert is expired, 
but expiration is just another cause of being unverifiable.  So, I think it
very likely that this bug is really a dup of bug 221522.  If my suggestion in
the previous comment works around it, and if that suggestion also works
around the problem for bug 221522, then I'd say this one can be treated as a 
dup of the other.  

Aside: since the cert is self-issued, there can't be much reason not to 
replace it with a new one.  Cost certainly can't be a factor. :)  
Just be sure the new one does NOT have the same serial number as the old one.
(That's the MOST COMMON mistake made when creating self-issued certs.)

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

It just occurred to me that TBird doesn't yet share FireFox's cert DB. :(  So, 
there's going to be one more big ugly step required to test this workaround.  

After visiting the URL cited above with FireFox, shut down and exit both 
FireFox and TBird.  Then you need to backup (copy) the file cert8.db from 
third's profile directory to somewhere safe, and then copy the cert8.db file
from FireFox's profile directory to TBird's profile directory.  Then restart
TBird and see how it goes, and let us know here.   If things go awry, then 
make sure TBird is NOT running, and put TBird's original cert8.db file back. 

Comment 10

[Adam Guthrie]

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