165920 - Certificate manager is no longer able to edit trust on my certificates.

Status: VERIFIED DUPLICATE of bug 150697

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

Description

[Sten Carlsen]

This bug is not precisely repeatable, I can not get back to start. Browser is
initially 1.0 rel. (official)
Here is the approximate sequence things happened in:
- I set up a https server on my internal network (to learn some)
- I create a selfsigned root ceritficate (an official one is too expensive
before you really need it)
- works perfectly on all tested platforms and browsers.
- I set one dir to require a client cert., and I produce one. Works fine.
- now I have one page set to show all connection parameters, so I play with
disabling TLS, SSL3 and various cihpers to see that the actually used cipher
changes accordingly. At this stage I try to look at the server, assuming the
browser works correctly.
- Having only SSL2 enabled I can not connect with https. Ok, enable everything
again so all back to normal.
- Only point is all is not back to normal, I can not use TLS any more! IE5.0 can.
- Next time I try my test page, I can not connect because the server certificate
is not trusted any more.
- Enter prefs, priv... cert... cert. manager. Locate the server cert. click edit
and select trust this cert. click ok, no response, only cancel works.
- Now I can load my page, next time I start the browser, we're back to the cert.
being not trusted.

At this stage I upgrade to 1.1 rel. after uninstalling 1.0. No change in this at
all! On the other hand I find all certificates present in 1.1 at start, so db
most likely not changed?

Any experiments you would like me to do?

Comment 1

[John Unruh]

Reporter, can you read bug 152397 to see if this bug is a duplicate? If you have 
FIPS enabled, and are not logged in with your Master Password, you cannot edit 
the Certificate Authorities. To log in to your Master Password if you have FIPS 
enabled, visit a secure site, like https://www.verisign.com.

Comment 2

[Sten Carlsen]

Bug 152397 is very close, but is not quite about the same thing.

- My problem was with a web-site cert, not a CA-cert. (So far I don't see much
difference, anyway)

- I had things working fine for some days, no need to edit anything. Until I
tried to disable different types of encryption and protocols to see if my
webserver would accept different requests. After having only SSLv2 enabled (did
not function) I switched back to all enabled and troubles began.

- I run with a blank FIPS password (I know, ...) I get asked for it any time I
should.


Basically things only got messed up when I tried all sorts of different
combinations of protocols and ciphers.
I also have an experiment with a webpage, I only can access if I have the
correct client side cert. (I don't know if this has any influence).


BTW: after a couple of days mozilla will again connect using TLSv1, it did not
do that when problems were happening. Today trust has also returned to the cert
I could not set it on the other day. (self healing SW?)

Ok, it is fishy. More systematic tests should be done. But which?

Comment 3

[Sten Carlsen]

One further comment:

Now using rel. 1.1 on linux, connecting to the same webserver, I get a message
box: there is a problem with this cert. .. not recognised by any CA, moz. knows.

Quite correct, I have manufactured it myself.

Ok, mark "remember this certificate permanently". click ok. This box will simply
not die, no matter how many times I mark it and click, it returns eternally. If
I don't mark "remember...", it accepts and disappears. On this installation I
have a password for FIPS and logged in (just imported a personal cert).

I have no idea if these two are related, but somehow it seems to be related to
"homegrown" certs.

Comment 4

[John Unruh]

This seems like a dupe of bug 106604, bug 150697, and bug 152397. Reporter, 
please open a new bug for each reproducible bug that you find, if the bugs just 
mentioned are not the same ones that you are experiencing. You should also 
consider upgrading to a nightly build at www.mozilla.org which has some bug 
fixes not in Moz 1.1.

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

Comment 5

[Sten Carlsen]

Comment #3 is quite correctly a duplicate of bug 150697.

I will add additional info under this bug no.

Comment 6

[John Unruh]

Verified.