Ahh...I didn't use the edit button! But simply wanting to check whether or not the cert was disabled it wasn't clear to me that "edit" was what I wanted to use to accomplish that as I didn't want to "edit" anything. Fx Help is of little help when it comes to this entire area of Certificate Management. That section of Help really needs a HUGE rewrite. Your explanation is excellent. Why can't something like it be incorporated into Help? I think the Certs section of Help is the skimpiest, most unsatisfactory area. Even Help for Fx 2.0 beta 1 is poor in this regard.
I'm glad you filed a bug report and I will follow the progress of this bug (too tired now to look at it...but I will and I will put myself on the mailing list). I have another question: How do the profiles affect, if at all, the certs? I am asking partly because I recently installed Fx 2.0 beta 1 on a virtual machine running XP Pro SP1. I already had Fx 1.0.6 on that machine. I have 2 profiles for 1.0.6. On 2.0, earlier tonight, I used the second profile "Umi" for the first time with 2.0. I looked at the Certificate list and when I clicked on beTRUSTed Baltimore cert I was informed that it could not be verified for "unknown reasons". I closed Fx and then opened Fx 1.0.6 and chose the "Umi" profile. I rarely used this profile on 1.0.6 and had never used it until tonite with 2.0. Anyhow, I check the same cert and on this version of Fx it says the cert cannot be verified because the issuer is not trusted. I am positive that I have never tried to delete ANY cert from this profile on this version of Fx on my virtual machine. I don't believe I ever tried to delete beTRUSTed Baltimore cert on Fx 1.5.0.4 on my host machine either. I don't recall doing that and logically if I had decided (and have now forgotten) that beTRUSTed was "bad" and I wanted to delete the certs, I certainly would never have deleted only one of beTRUSTed but would have deleted all of them and the others all verify. Plus, on my host machine, the profile that I use is NEW, as of just a few weeks ago, (I have my profiles go corrupt very frequently and have to create new profiles) and I would remember if I had tried to delete a cert in the past few weeks. So, I think there is something else going on with the beTRUSTED Baltimore cert which may be unique in this respect for some odd reason. As to GoDaddy cert, I have been experimenting with it on Fx, on both my host and virtual machines, and with all three versions of Fx I have. It behaves in the manner that you described for ABA.ECOM root CA. Before I fall asleep here: beta.microsoft.com blogs.technet.com Two sites that Fx says the certificate cannot be trusted. There are not as many Microsoft secure sites with this problem as there were even six months ago. I no longer get that popup from Fx when I logon to Passport and used to get it then also. There are more than the two I listed though...I just can't think of them right now. I believe mostly on technet. I hope this is half way coherent...I must get some sleep. "Frank Hecker" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Mele wrote: >> I have tried to delete a root cert from Fx and have found that the cert >> comes back and appears FULLY FUNCTIONAL rather than being disabled. So, >> I don't understand your statement. > > Actually I saw your post elsewhere and decided to check this out. Here's > what I observed (using Firefox 1.5.0.4 on Windows XP SP2): > > 1. I started with a root CA certificate that was pre-loaded and marked as > trusted for all uses (in my case the ABA.ECOM root CA). (I verified this > using the "Edit" button.) > > 2. I then used the "Delete" button to attempt to delete the root CA > certificate that was pre-loaded . The operation attempted to succeed and > the root CA cert disappeared from the displayed list. > > 3. I then exited Firefox, restarted it, and went back to the root CA list. > The root CA certificate I had "deleted" was still in the displayed list of > root certs, but when I checked using "Edit" it was *not* marked as trusted > for any purpose. > > Background: Pre-loaded root CA certs in NSSCIBK.DLL can't really be > deleted from that file, because it's a read-only shared library that is > separate from the modifiable Mozilla certificate database. I haven't > verified this, but I suspect that root CA certs in the modifiable database > (which is populated by the user) can in fact be deleted "for real", but > root CA certs in NSSCKBI.DLL can only be marked as untrusted. > > From a security point of view the effect is the same -- any certificates > issued under the "deleted" CA are no longer recognized as valid -- but I > agree that this is confusing from a UI point of view. I've filed a bug > about this against the PSM component of Firefox (the component that I > think is handing the UI for this): > > https://bugzilla.mozilla.org/show_bug.cgi?id=345934 > >> I would like to ask why are there root certs for Fx that cannot be >> verified because, according to Fx, the issuer is NOT trusted? > > To my knowledge no root CA certs shipped pre-loaded with Firefox (and > other Mozilla-based products) are marked as untrusted "out of the box". > However it is certainly possible for a user to explicitly mark a root cert > as not trusted; this can be done for both pre-loaded root CA certs and for > root CA certs that the user might have later downloaded into Firefox and > marked as trusted on their own. > >> It makes me nervous having certs that cannot be verified and that, when >> deleted, promptly return to the list and appear functional. Those certs >> are not even on the list that is on your web page. I assume they are >> legacy certs > > That is correct. The list on my web page covers only CA certs that were > added since the Mozilla Foundation took over the task of selecting new CAs > to be added. There's currently a bug filed relating to creating an > official page that lists all pre-loaded CA certificates: > > https://bugzilla.mozilla.org/show_bug.cgi?id=333272 > >> but why are certs that cannot be verified there at all? I am referring >> to beTRUSTed Root CCA Baltimore Implementation, beTRUSTEed Root CA RSA >> Implementation, and beTRUSTed Root CA Entrust Implementation. > > In my vanilla installation of Firefox all of the beTRUSTed root CA certs > are marked as trusted. If they are not marked as trusted in your copy of > Firefox I suspect that it's because you attempted to delete the beTRUSTed > CA certs in the past, with results as I describe above. > >> I am unable to delete the GTE CyberTrust Root CA that expired in >> February. That one also comes back. Why? I also deleted the GoDaddy cert >> and it comes back. > > These CA certs are also in NSSCKBI.DLL and hence cannot be deleted "for > real", but only marked as untrusted. > >> If these are actually disabled then why are they back in the list and not >> at least grayed out or have "disabled" beside them? Should I not be >> informed that they are disabled if they truly are? > > I agree that this is confusing behavior, which is why I filed a bug report > about it as noted above. > >> I have another question regarding Fx certs that is not directly related >> to PSC's findings but would like to ask it. Why does Fx not have any >> certs from Microsoft? It is very irritating every time I go to a secure >> Microsoft site on Fx to have Fx tell me that the certificate cannot be >> trusted (Microsoft Secure Server Authority which is an intermediate >> cert). > > Can you give an example of such a site, so we can try it out? Also, note > that we don't pre-load intermediate CA certs, only root CA certs, so if > the Microsoft CA in question is an intermediate CA then we would not > pre-load it, but instead would have to pre-load whatever root CA cert it > was ultimately issued from. > >> Along these lines, I also would like to know why Fx jumbles up the >> intermediate and root certs all on one tab? They should be on separate >> tabs. > > As mentioned above, as a matter of policy we don't pre-load intermediate > certs, only root CA certs, so as installed "out of the box" the Firefox CA > cert list will contain only root CA certs. Also, unlike Internet Explorer, > Firefox does *not* cache and store intermediate CA certs that it > encounters in the course of doing SSL connections and the like. > > As a result the only intermediate CA certs that might end up in the > Firefox cert database are those that are explicitly added by the user. > This is a relatively uncommon thing, which may be why we don't split > intermediate CAs out as a separate list in the Firefox UI. However I'm not > really the expert on this particular aspect of Firefox, so I'll defer to > others more knowledgeable than I. > > Frank > > -- > Frank Hecker > [EMAIL PROTECTED] _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
