User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925 Preferences - Privacy & Security - Certificates - Manage Certificates The Authorities tab contains multiple certificates for VeriSign, Inc, labelled "Builtin Object Token". I do not trust VeriSign, and wished to delete these certificates. Unfortunately, Mozilla wouldn't let me. It pretended to accept my command, but the certificates were still there afterwards. Upshot: Users apparently can't revoke built-in certificates, even if they are known to be compromised or issued by an untrustworthy organization. Reproducible: Always Steps to Reproduce: 1. Go to VeriSign certificates. 2. Try to delete them. 3. Dismiss dialog with OK, go back and look again. Actual Results: The VeriSign certificates were still there. Expected Results: Mozilla should either have deleted the certificates, or at a minimum it should have thrown an error saying I couldn't delete them. Accepting the current restricted functionality would definitely be a bad move, as it means end users can't revoke compromised certificates! (Personally I think VeriSign should be removed from the list of trusted authorities, but that's a whole separate political discussion.)

And why is this a security hole in Mozilla ? This looks like a crypto/certificate problem -> PSM

It sounds to me like you don't want to delete it, but rather you want to mark it explicitly untrusted. It's not that you've never heard of it before, but rather you choose not to trust it. You don't want a dialog about unknown issuer every time you visit a Versign site, you want action that reflects that you've chosen not to trust it. SO, the solution is to edit the trust on this issuer, not to delete it.

Reasonable things would be to grey-out the delete button for builtin CAs, generate an error when trying to delete, or have the delete button mark the CA as untrusted. Nelson, is there any way for PSM to tell that those CAs can't be deleted?

I'm adding Bob Relyea to the list, because this is all his code we're discussing. The built in root CA list is in a separate PKCS11 module, and a separate PKCS11 "token", which is read only. There is no way to delete or modify its contents in any way (except editing the source and rebuilding). However, NSS has attempted to provide ways to OVERRIDE the contents of the built-in root CA, both with respect to the presence of certs in it, and to the trust of certs in it. Trust is relatively simple. When you "edit" the trust on a built in cert, you actually create a trust record in the software database token that explicitly says that you do not trust the cert in the built-in root CA list. That works pretty well. There is also some means, that I do not now recall, and think is documented nowhere, by which something can be written into the software database token that causes NSS to effectively no longer see a certain cert in the built-in trusted roots module. It makes it appear as if the cert has been deleted in that module, even though it has not. This feature is not widely known, and IMO, has worked in some releases and not others. I think it is also possible that some NSS functions will continue to see the cert in the built-in roots module, even after it has been supposedly hidden by this other means. Another implication of this approach of storing info in the database token to conseal the true presence or trust of a cert in another token, is that if the cert DB is lost or replaced, the suppsedly deleted or untrusted certs in the built-in token suddenly reappear and become re-trusted. My advice would be this: It should be possible to determine if the module/token on which a cert resides is "read only" or not. If so, then you could surely gray out the delete buttons for certs on those tokens.

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

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