175225 - "Accept this certificate permanently" does not accept certificate permanently

Status: VERIFIED INVALID

(Core Graveyard :: Security: UI, defect, P2)

Description

[Olli Männistö]

I have to use a mis-configured IMAP server at work. They have a mismatch in the
domain name plus they're their own authority. I'm treated to a SSL certificate
warning each and every time I start fresh mailnews. To add insult to injury,
there's "Accept this certificate permanently"-option in the dialog. After I
select it and press "OK", I get the same dialog again. Arrgh!

Steps to reproduce:
1. start mailnews
2. select "Accept this certificate permanently" option in the dialog and click OK

Expected result:
Nag goes away

Actual result:
I get the same nag screen again!

Comment 1

[John Unruh]

Reporter, if you have FIPS enabled, please mark this bug a duplicate of bug
150697. Edit>Prefs>Privacy>Certificates>Manage Security Devices>Disable FIPS.

Comment 2

[Kai Engert (:KaiE:)]

regression

Comment 3

[Olli Männistö]

FIPS? Yech, another cool goverment acronym. No, not enabled, never has been enabled. FWIW, this bug has shown up in 1.1 and 1.2 beta.. All W2k. the "remember this certificate" has never worked. 

But regression? What? 

Comment 4

[John Unruh]

Please see comments 17-19 in bug 171219. This looks like another server cert
issued by Plesk.com with serial number 00.

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

Comment 5

[Olli Männistö]

From what I read in bug 171219, I think this one's related, but separate issue.
The problem here's bogus certificate PLUS domain name mismatch (mail8 vs mail4)
.. In bug 171219 it was expired bogus certificate.

Right? 

Comment 6

[John Unruh]

Will revisit after bug 175115 is fixed.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

AFAIK, an override for a cert name mismatch cannot be accepted permanently.
You can trust a cert from an unknown or untrusted CA permanently,
but you cannot permanently override a cert name mismatch.
You also cannot permanently override a cert expiration.

The cert database has no way to record either (a) the fact that you've
decided to override an expired cert, or (b) the name(s) of the server(s)
that don't match the cert name, but that you've decided to use the cert
with anyway.

Bug 171219 reports that the ability to override cert expiration is not 
working at all, not even in the non-permanent case.  When that bug is 
fixed, cert expiration override will work until the browser is restarted,
but it will still not be a permanent override.  We now believe the cause
of that problem is NOT duplicated issuer and serial number, but rather
a bug in a new implementation of the cert chain verification code.

The original problem reported in this bug is due entirely to duplicated
issuer name and serial number.  So, I agree that this bug is not a 
duplicate of 171219, but it is a duplicate of the bugs about duplicate
issuer and serial number.

Comment 8

[Kai Engert (:KaiE:)]

Bug 175115 was fixed in the external library, but the fix did not yet land in
Mozilla. I'm making this dependent on PSM bug 171219, which is for sure caused
by bug 175115. Once we resolve bug 171219, let's test this again.

Comment 9

[John Unruh]

*** Bug 178031 has been marked as a duplicate of this bug. ***

Comment 10

[Kai Engert (:KaiE:)]

The patch for bug 175115 just has landed on the 1.2 branch.
If you want, get a build from
http://bugzilla.mozilla.org/attachment.cgi?id=104600&action=view *tomorrow*.
If the problem is fixed on the branch for you, please comment in here.
Please do not yet mark the bug as fixed, because we need to wait until the patch
for 175115 lands on the trunk, too.

Comment 11

[Olli Männistö]

Nope, I still get two nag-screens. 

First one says the certificate is from unknown authority. I have options to
accept permanently, which does nothing, accept temporarily, which works ok and
cancel.

Second nag screen says there's a domain name mismatch. 

Comment 12

[Kai Engert (:KaiE:)]

According to you comment, I believe this bug is unrelated to the other ones.
Removing dependency.

It would be helpful if you let us know which server you are connecting to, so we
can try ourselves. Without that, we can't help.

You could try out what happens when you go to https://kuix.de
This site also uses an untrusted certificate, and when I try it, accepting the
certificate permanently does work.

Comment 13

[Olli Männistö]

The site I'm trying to access is an IMAP server with SSL. imap8.nebula.fi. I
don't think you're going to get much out of them without valid un/pw.

kuix.de works as expected. Nag screen goes away when you choose "accept
permanently". I just now logged into the imap server and the "accept
permanently" just refreshes the nag screen. So I have to pick "accept temporarily".

Comment 14

[John Unruh]

Olli, can you try a new profile, in case your certificate DB is corrupted?

Comment 15

[Olli Männistö]

Deleting the certificates for that server in fact did allow me to choose "accept
permanently" successfully. I still do get the "certificatet domain name
mismatch"-nag every time. 

Comment 16

[Kai Engert (:KaiE:)]

I remember we have a bug whose description is similar to "existence of
permanently remembered, but meanwhile expired web site cert confuses the
browser". I'm not sure whether that is related.

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

As I noted in comment 7 above, 
>  an override for a cert name mismatch cannot be accepted permanently.
So you will continue to be reminded of the cert name mismatch the firsrt
time you visit this web site after each restart of mozilla.  That is not
a bug.

This is another invalid cert problem, being caused by the issuance of 
multiple certs with the same issuer name and serial number.  As with all
such bugs, it is necessary to delete the old cert with the same serial
number from the DB before a new one can be accepted.  

IMO, This bug is invalid.  The only thing mozilla might do differently
is to detect the existence of invalid certs that reuse serial numbers
from older certs, and simply refuse to accept them, without offering any
option to accept them permanently.  In any case, the solution is to stop
issuing invalid certs with reused serial numbers.

Comment 18

[John Unruh]

Marking invalid. 

Comment 19

[Olli Männistö]

Oh come on. The bug here was that the "accept permanently" option did not work.
This was a bug-bug and it was fixed, too. 

Comment 20

[John Unruh]

Verified invalid.