Closed
Bug 558222
Opened 15 years ago
Closed 9 years ago
Provide a Capability to Restore a Root Certificate to Its As-Installed NSS State
Categories
(Core :: Security: PSM, enhancement)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: david, Unassigned)
Details
(Whiteboard: [psm-cert-manager])
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4
Build Identifier:
Reference: How To Override Default Root Certificate Settings at <https://wiki.mozilla.org/CA:UserCertDB>.
If a user deletes a root certificate per the section "Deleting a Root Certificate" under the Reference, then the situation described in the section "How Mozilla Products Respond to User Changes of Root Certificates" under the Reference applies. See in particular the last paragraph of the Reference.
A user has no way to restore the as-installed state of a root certificate without having a copy of that certificate in the user's own database. Thus, when such a certificate is updated in NSS and the update is installed in the user's configuration with an update of a Mozilla or Mozilla-based product, the certificate update will be ignored.
This RFE requests a capability to restore a root certificate to its as-installed NSS read-only database state while eliminating any copy in the user's own database. The result of this capability would then mean that an updated certificate in the NSS read-only database -- installed with an update of a Mozilla product -- would not be ignored.
Reproducible: Always
See bug 557717.
This might best be implemented in conjunction with bug 545498 since the capability requested here would be a useful option when resolving certificate inconsistencies in that other RFE.
I consider the lack of this capability in Certificate Manager to be a "hole" in the set of its capabilities.
Updated•15 years ago
|
Assignee: kaie → nobody
Whiteboard: [psm-cert-manager]
Reporter | ||
Comment 1•14 years ago
|
||
Removing file cert8.db would, of course, remove ALL user tailoring of the root certificate set. This RFE, however, requests the ability to remove the tailoring of one certificate without perturbing the tailoring of others. That is, it would require removing a root certificate from cert8.db without removing the entire file.
Comment 2•14 years ago
|
||
I'll note that one can remove individual certificates with certutil (best to do it while the application is not running):
certutil -d $PROFILE_DIR -L
# Note the name of the certificate to be removed.
certutil -d $PROFILE_DIR -D $CERT_NAME
See also bug 173729 and bug 345934 for possible changes to PSM behavior for "deleting" built-in certs.
Reporter | ||
Comment 3•14 years ago
|
||
Is certutil a UNIX/Linux utility? Or is it available for Windows?
Comment 4•14 years ago
|
||
If cert manager lists a root cert as "builtin object token",
then the action to revert the root to the builtin state is:
=> remove the trust object that is stored in the NSS database
This is exactly what happens when a user attempts to use the "delete cert" feature.
If cert manager lists a root cert as "software security device",
then the action to revert the root to the builtin state is:
=> delete the root cert
In other words,
you already have the feature you're looking for.
Delete the cert, and you're done (despite the fact that it will still be shown in cert manager for certificates that are builtin).
I believe this should be resolved as "notabug".
Comment 5•14 years ago
|
||
(In reply to comment #4)
> If cert manager lists a root cert as "builtin object token",
> then the action to revert the root to the builtin state is:
> => remove the trust object that is stored in the NSS database
>
> This is exactly what happens when a user attempts to use the "delete cert"
> feature.
Nope. I just "deleted" a built-in cert through PSM and a copy of the cert with all trust bits off was added to my cert8.db.
Comment 6•14 years ago
|
||
Ok, I apologize, I was obviously wrong.
So, in order to restore a builtin root to its original state, one would have to really delete the trust object...
Comment 7•14 years ago
|
||
The third command in comment #2 is wrong: I missed the -n option.
I have added the procedure to the wiki (https://wiki.mozilla.org/CA:UserCertDB#Restoring_the_Default_Trust_Bits_for_a_Single_Built-In_Root_Certificate), so any further corrections can be made there.
This feature would be more appropriate as an add-on.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Comment 9•9 years ago
|
||
Added a feature request about this for the Cert Manager Addon project:
https://github.com/sidstamm/FirefoxCertificateManager/issues/45
Reporter | ||
Comment 10•9 years ago
|
||
(In reply to Kathleen Wilson from comment #9)
> Added a feature request about this for the Cert Manager Addon project:
> https://github.com/sidstamm/FirefoxCertificateManager/issues/45
Although this bug report is marked WontFix, please update with any significant progress on the Cert Manager Addon so that I can track this issue.
You need to log in
before you can comment on or make changes to this bug.
Description
•