Re: Unable to remove certificates permanently through options
Eddy Nigg
> Is this a known bug or intended behavior? (i.e. anything that is a
> "Builtin Object Token" cannot be deleted?).
>
Those certificates can't be deleted, the correct way is to disable their
trust bits. Simply click on "Edit" and remove the flags.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
David E. Ross
> So I decided to try and remove some certificates from Firefox 3.6 (on
> Windows XP 32 bit). I went to Tools-Options-Advanced-Encryption and
> clicked on "View Certificates", I then highlighted the first one,
> TurkTrust and clicked on "Delete". It asked me to confirm if I wanted
> to delete the certificate, saying that it would no longer be
> available/etc. I clicked on Yes and the certificate was no longer in
> the list. So I restarted Firefox, went back to the certificate
> properties and it's back in there. It was not deleted. It's back in
> there.
>
> Is this a known bug or intended behavior? (i.e. anything that is a
> "Builtin Object Token" cannot be deleted?).
>
> deleting doesn't delete the certificate (i.e. gray out the button), if
> it's a big it's a pretty damn serious one.
>
> This seems to be a problem going back many versions (i.e. 3.0.3 on XP in 2007):
>
> http://www.techspot.com/vb/topic92117.html
> http://support.mozilla.com/tiki-view_forum_thread.php?locale=fr&forumId=1&comments_parentId=201140
>
> Why is there a delete option if it doesn't work?!?
>
> -Kurt
Go to <https://wiki.mozilla.org/CA:UserCertDB> for an explanation.
Under "Deleting a Root Certificate", read the paragraph for "Important".
Under "How Mozilla Products Respond to User Changes of Root
Certificates" read the entire section.
The delete function removes certificates in your own certificate
database. This database contains certificates you imported and
certificates from the read-only NSS database (installed with Mozilla and
Mozilla-based products) for which you changed the trust bits (the NSS
database being protected from such changes).
When you have the same certificate in your own database and in the
read-only NSS database, your own database supersedes the NSS database.
If you delete such a certificate from your own database, the
corresponding certificate in the read-only NSS database is enabled the
next time you restart your Mozilla application.
Certificates are deleted from the read-only NSS database only by the
Mozilla NSS development team. That deletion takes effect for you when
you next install an update of a Mozilla application that includes the
updated NSS database.
If in the meantime you have changed the trust bits for a certificate in
the NSS read-only database, that certificate is copied to your personal
certificate database. If that certificate is then deleted from the NSS
read-only database in an update to your Mozilla application, it is not
deleted from your personal database until you explicitly delete it.
Does all this seem confusing? It can easily confuse even expert users.
Thus, I submitted bug #545498 to check for inconsistencies between the
NSS read-only database and the user's personal database and provide user
capabilities for resolving those inconsistencies. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=545498>.
Until that RFE bug is implemented (if it ever is), I suggest you turn
off all trust bits of a certificate that you would like to delete. That
will completely disable the certificate even after you terminate and
then restart your Mozilla application.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. � 1997
Kurt Seifried
function, it even asks for confirmation, and it then shows the
certificate as removed.
1) if something can't be deleted when I select that certificate the
delete button should be greyed out
2) it should definitely not ask for confirmation to delete something
if it can't be deleted
3) it should definitely not shows the certificate as deleted (i.e.
removed from list) when it fact it is not deleted.
It's like the Mozilla developers went out of there way to convince
users that they deleted something when in fact it is not (and only
shows up again after a firefox restart)
Also how can I do a mass unset or trust bits? I can select multiple
certs and hit edit and am then presented one by one the certificates.
I can't, for example, export them without trust bits set, and then
import them in another browser and overwrite the trust bits. There is
apparently no way to automate this or even do it somewhat efficiently
other than to go one by one.
As far as I can tell: "Mozilla's trusted root list, kept in a
read-only shared library which is one of the files that gets updated
whenever your product's executable files get updated." So am I correct
in:
1) There is no way to permanently delete root certificates from
firefox/thunderbird/etc that are shipped by Mozilla unless I binary
patch the library file and patch it whenever I upgrade the application
(in other words no realistic way)
2) There is no way through the Firefox UI to do a mass unset of trust bits
3) There is again no easy way to manipulate the trust bits through a
third party add-on (I can't find one anyways) or via
scripting/programming (i.e. a login script).
-Kurt
David E. Ross
> This is definitely a problem then, the interface provides a delete
> function, it even asks for confirmation, and it then shows the
> certificate as removed.
>
> 1) if something can't be deleted when I select that certificate the
> delete button should be greyed out
> 2) it should definitely not ask for confirmation to delete something
> if it can't be deleted
> 3) it should definitely not shows the certificate as deleted (i.e.
> removed from list) when it fact it is not deleted.
If you have altered the trust bits in a root certificate that is in the
read-only NSS database, there is now a copy in your user's database.
That copy is the one that is altered. It also overrides the certificate
in the NSS database. If you then delete that certificate, it is indeed
deleted from your user's database. Then the certificate in the NSS
database -- with its preset trust bits -- is what is used.
If have not altered a root certificate in your configuration, it exists
only in the read-only NSS database. In that case, you are correct. An
action to delete it is very misleading.
The problem is that users cannot tell from the Certificate Manager what
it is they are attempting to delete. If they have forgotten which root
certificates they have altered, they don't know whether a particular
certificate can indeed be deleted.
Kurt Seifried
The root certificate store cannot be altered directly in any way by a
user (certificates can't be deleted, trust bits cannot be removed).
In order to "modify" a certificate a copy of it is made and installed
in the user's personal store, this certificate can be modified with
respect to trust bits.
If I delete a certificate within my user store (that has the trust
bits turned off) then Firefox will default back to using the root
store where the certificate would be trusted?
So if a user removes the trust bits on a certificate they will be
protected, but if they then later delete the certificate they will be
unprotected, is this correct?
-Kurt
Nelson Bolyard
> So I decided to try and remove some certificates from Firefox 3.6 (on
> Windows XP 32 bit). I went to Tools-Options-Advanced-Encryption and
> clicked on "View Certificates", I then highlighted the first one,
> TurkTrust and clicked on "Delete". It asked me to confirm if I wanted
> to delete the certificate, saying that it would no longer be
> available/etc. I clicked on Yes and the certificate was no longer in
> the list. So I restarted Firefox, went back to the certificate
> properties and it's back in there. It was not deleted. It's back in
> there.
>
> Is this a known bug or intended behavior? (i.e. anything that is a
> "Builtin Object Token" cannot be deleted?).
>
> If it's intended behavior then deleting shouldn't be allowed since
> deleting doesn't delete the certificate (i.e. gray out the button), if
> it's a big it's a pretty damn serious one.
> Why is there a delete option if it doesn't work?!?
Nelson Bolyard
> On 3/16/10 4:09 PM, Kurt Seifried wrote [in part]:
>> This is definitely a problem then, the interface provides a delete
>> function, it even asks for confirmation, and it then shows the
>> certificate as removed.
>>
>> 1) if something can't be deleted when I select that certificate the
>> delete button should be greyed out
>> 2) it should definitely not ask for confirmation to delete something
>> if it can't be deleted
>> 3) it should definitely not shows the certificate as deleted (i.e.
>> removed from list) when it fact it is not deleted.
See https://bugzilla.mozilla.org/show_bug.cgi?id=345934
You could add your comments there to show there is still interest in
that problem.
> The problem is that users cannot tell from the Certificate Manager what
> it is they are attempting to delete. If they have forgotten which root
> certificates they have altered, they don't know whether a particular
> certificate can indeed be deleted.
I don't find it necessary to remember any such thing. My certificate
manager plainly tells me which of the "security devices" holds each
certificate that it shows me. It says either "builtin object token" or
"software security device" for every certificate (except when I'm using
hardware devices, then it also lists them for some certs).
Does your cert manager not show you this info?
Nelson Bolyard
Please read the entire web page section
https://wiki.mozilla.org/CA:UserCertDB#How_Mozilla_Products_Respond_to_User_Changes_of_Root_Certificates
as David suggested.
David E. Ross
Yes, it shows those designations. However, I have no idea what those
designations mean. The Help information for Certificate Manager does
not even mention them.