Closed Bug 138818 Opened 23 years ago Closed 22 years ago

Cannot delete authority certificates

Categories

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

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
psm2.4

People

(Reporter: stupiddog, Assigned: KaiE)

References

Details

Tested with Moz 1.0RC1, the following thing does not work: Open the certificate management. Go to the "Authorites" tab. Select Thawte (not a special certificate!) Hit "delete". The first problem is that this dialog box is too small (you have to enlarge it to see the buttons). Confirm the deletion with ok. Result: The ceritifcate is NOT removed. This problem also happens if you specify a concrete certificate. This is a big problem if you have to update a authority certificate.
to psm
Assignee: mstoltz → ssaux
Status: UNCONFIRMED → NEW
Component: Security: General → Client Library
Ever confirmed: true
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: other → 2.0
*** Bug 138875 has been marked as a duplicate of this bug. ***
kai Isn't this a dupe of 129067
Assignee: ssaux → kaie
Priority: -- → P2
Target Milestone: --- → 2.3
Keywords: nsbeta1+
Whiteboard: [adt2]
Not sure. My understanding is that CA cert handling is still somewhat special since we've been using NSS 3.4. It is no longer possible to delete the CA cert, but instead it will be flagged internally having no longer trust anymore. Effectively marking the CA cert to have no trust anymore is the same as deleting the cert. You can't delete the cert, because it is contained in a read only storage. Andreas, you say it is a problem when you have to update a CA. Well, you can't update any of the CA cert that came delivered with the browser. You shouldn't ever be required to do so. Removing the trust from them should be fine. Importing your new CA certs should work, too. You can, however, delete any certs that were imported, and are not contained in the builtin read-only cert storage. If you agree, I think this should be marked invalid, and nsbeta1+, adt removed.
You can call PK11_IsReadOnly on a cert's slot and disallow the delete operation. This is how I took care of the problem in the web server cert admin UI. However, there are tricks to perform in order to check the right cert. For root certs that have modified trust, there will be two identical certs - one in softoken and one in the root-cert module. One of them is deletable, while the other is not. What the web server does is rather complex : - call PK11_ListCerts with PK11ListRootUnique to get a list of all root certs - Some certs will include a nickname in the appData field of the CERTCertListNode returned . Those are certs that exist in multiple tokens, in particular the root certs that have modified trust. In that case, the cert->slot will point to softoken, which will be marked deletable - for those certs, you can get back to the real root cert by finding the slot based on the nickname in appData (it will contain Builtin Object Token: and you can use PK11_FindSlotByName) . Then you can check if that slot is read-only
(To Kai): That would be ok if I received a correct error message, which I do not. (Actually, I receive NO error message).
Whiteboard: [adt2] → [adt2 rtm]
The patch in bug 129067 will land soon. It will fix the problem that you can currently hit delete, while you only have a category selected (but not a certificate), and the dialog seen looks small and ugly. It will also cause that CA certs will be removed from the CA tab while you work with the dialog. However, when the deleted cert was from the list of built in certs: when you open cert manager next time, you will again see that CA cert listed, but it will have all trust removed. While this bug is not exactly a dupe of 129067, I think the behaviour will be acceptable when bug 129067 is fixed. I'm making this bug dependent on it, and we should retest and decide, after it got marked fixed.
Depends on: 129067
Please test whether the behaviour on the trunk is now acceptable. Thanks.
Marking fixed on 5/16 Win2000 trunk. The behavior is acceptable, and acts as described in comment #7.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Because this bug was fixed by a patch in another bug (129067), removing this bug from the branch radar.
Keywords: nsbeta1+
Whiteboard: [adt2 rtm]
Reopening this bug. Actually the behavior is not quite what is expected in comment 7. I found a case where the fact that a deleted root cert is persistent. This does not happen with all root certs, only some. Specifically, delete the "GTE CyberTrust Root" from the built-in token. Close mozilla. Restart it. This certificate is no longer listed. Doing a strings on cert7.db indicates that this certificate is referenced. Somehow, some deletion information about this certificate has been stored into cert7.db . If I remove cert7.db and restart mozilla, the cert comes back. This is not expected to happen and is an NSS bug, which I will file separately. This bug exists both in Mozilla 1.0RC3 with NSS 3.4 and the trunk with NSS 3.5 .
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Depends on: 148270
Kai, The proper fix for this would be to disallow deletion rather than resetting trust to 0 for root certs, as I proposed in comment #5 .
*** Bug 154637 has been marked as a duplicate of this bug. ***
No longer depends on: 148270
*** Bug 148270 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Keywords: nsbeta1 → nsbeta1+
*** Bug 165017 has been marked as a duplicate of this bug. ***
Target Milestone: 2.3 → 2.4
When a (private) root ca certificate is imported it can not be deleted. I think this is the same bug so I didn't create a new report, just added a comment here. 1) Import a root certificate 2) Go to the certificate manager and attempt to delete that certificate. Results: A dialog appears (properly sized) asking for conformation, after conformation (ok button pressed) the certificate is still there and still has all original trust settings. Version: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020918
Works for me with the 10/7 trunk commericial Linux build and 10/7 Linux Mozilla. Imported root CA's are deleted, even after restart, and Builtin CA's reappear after restart, but are untrusted.
Robert I Peterson: Like John, I'm unable to reproduce your problem. I was able to go to http://www.kuix.de/ca/ns.php and install the cert, and delete it. After an application restart the cert was gone. Can you confirm that after a restart the cert is gone? Maybe even closing Certificate manager and reopening is enough? (I know, we might have a bug that a cert won't get purged from memory immediately.)
Julien: I can no longer reproduce what you said in comment 7, which was your motivation to reopen this bug. Although I agree the optimal solution would be to prevent deleting the certificate. But let's do that in a separate bug. I'm closing this bug again. I have filed bug 173729 for implementing the new behaviour.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
Kai, I really don't like the current behavior, but I agree with everything in the new bug you opened.
Product: PSM → Core
Version: psm2.0 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.