Closed Bug 1596401 Opened 5 years ago Closed 4 years ago

Deleting a certificate in the Certificate Manager does not work.

Categories

(Core :: Security: PSM, defect, P1)

Product:
Core
Component:
Security: PSM
Platform:
All
Unspecified
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
81 Branch
Tracking Flags:
Tracking Status
firefox-esr68 --- wontfix
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox81 --- verified

People

(Reporter: gcp, Assigned: keeler)

References

Details

(Whiteboard: [psm-assigned])

Attachments

(1 file)

Bug 1596401 - rework certificate deletion so it happens immediately r?rmf
47 bytes, text/x-phabricator-request
Details | Review

+++ This bug was initially created as a clone of Bug #1583067 +++

In current Nightly:

  1. Open Preferences
  2. Select Privacy & Security
  3. Click "Manage Certificates..." near the bottom
  4. Select a certificate
  5. Click "View..."
  6. Click "Delete..."
  7. Restart the browser
  8. Observe that the certificate is back

Are 70 and 71 affected?

Flags: needinfo?(gpascutto)

arif, who did QA testing on the original bug, told me in DM that he's observing this as far as 2016-era builds. So yes, likely.

Flags: needinfo?(gpascutto)

Ok, since this is an old regression, we don't need to rush an uplift in our current release or the December release then, thanks.

status-firefox70: --- → wontfix
status-firefox71: --- → wontfix
status-firefox-esr68: --- → affected

Also when deleting a custom certificate, the process must be repeated three times.
STR to reproduce:

  1. Open about:preferences#privacy and "View Certificates"
  2. Import the downloaded certificate (Root CA -> CA Cert Signing Authority)
  3. Select "Delete or Distrust" on the installed certificate
    ER: The certificate is successfully deleted.
    AR: After reopening "Certificate Manager" the certificate is still there. It needs to be deleted three times to disappear.

Also reproduced this on 70.0.1 (20191030021342) and 71.0b9 (20191111170815). Also reproducible with Firefox 52.0a1 (20161026030210).

There are countries like Spain where citizens receive those certificates to identify themselves to authorities. Looks quite bad if you can't get rid an expired personal certificate :-(

Hi J.C., please take a look at this. thanks!

Flags: needinfo?(jjones)
Flags: needinfo?(jhofmann)

We could still potentially take a patch for 72 but time is running short for beta uplift.

status-firefox72: affected → fix-optional
status-firefox73: --- → affected
Component: Security → Security: PSM

I took a look at this and the problem and as far as I can see we're looking at two (mostly independent) issues:

  • Built-in (root) certificates can not be deleted, they will be distrusted instead. However, this is not clear at all from the management UI, which will simply always remove elements, no matter if they were actually distrusted. The easiest solution is probably to guard that line on certType == nsIX509Cert::USER_CERT.

  • For user certificates, those can be deleted, but it takes some time to happen, because on user action they are only "marked for deletion" and will be finally deleted in their destructor. Unfortunately we seem to be holding it a little longer than we should, which delays CC by a while, AFAICT. Ideally we could avoid cleaning up the cert in the destructor only instead of trying to hack our way towards getting it collected earlier. Dana, do you have any thoughts on that?

I'm happy to take the bug, assuming we find a reasonable solution for the latter issue.

Flags: needinfo?(jjones)
Flags: needinfo?(jhofmann)
Flags: needinfo?(dkeeler)

(In reply to Johann Hofmann [:johannh] from comment #9)

I took a look at this and the problem and as far as I can see we're looking at two (mostly independent) issues:

What about disabling the button for certificates that can't actually be deleted? (the user can still use the "edit trust" button to remove its trust bits) (we'll have to remove the "or distrust" part of the button text)

  • For user certificates, those can be deleted, but it takes some time to happen, because on user action they are only "marked for deletion" and will be finally deleted in their destructor. Unfortunately we seem to be holding it a little longer than we should, which delays CC by a while, AFAICT. Ideally we could avoid cleaning up the cert in the destructor only instead of trying to hack our way towards getting it collected earlier. Dana, do you have any thoughts on that?

For user certs, we may have a path forward by removing the corresponding private key when the button gets pressed and ensuring that we don't show certificates in the client certificate tab if they don't have a corresponding private key.

For intermediates, we probably can also delete them immediately. The only issue is if any other part of Firefox has a copy of a certificate we're trying to delete, then it won't go away. In this case, we could maybe solve this by not showing temporary certificates in the certificate manager (which we may already do? not sure) (I suppose this should work with user certs as well)

Flags: needinfo?(dkeeler)

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #10)

(In reply to Johann Hofmann [:johannh] from comment #9)

I took a look at this and the problem and as far as I can see we're looking at two (mostly independent) issues:

What about disabling the button for certificates that can't actually be deleted? (the user can still use the "edit trust" button to remove its trust bits) (we'll have to remove the "or distrust" part of the button text)

Right, I agree that sounds like a better user experience.

  • For user certificates, those can be deleted, but it takes some time to happen, because on user action they are only "marked for deletion" and will be finally deleted in their destructor. Unfortunately we seem to be holding it a little longer than we should, which delays CC by a while, AFAICT. Ideally we could avoid cleaning up the cert in the destructor only instead of trying to hack our way towards getting it collected earlier. Dana, do you have any thoughts on that?

For user certs, we may have a path forward by removing the corresponding private key when the button gets pressed and ensuring that we don't show certificates in the client certificate tab if they don't have a corresponding private key.

For intermediates, we probably can also delete them immediately. The only issue is if any other part of Firefox has a copy of a certificate we're trying to delete, then it won't go away. In this case, we could maybe solve this by not showing temporary certificates in the certificate manager (which we may already do? not sure) (I suppose this should work with user certs as well)

Sorry, I don't fully understand the mechanics behind this. Are you saying we should just delete all certs (including user certs) right away and if they can't be deleted they'll somehow end up marked as temporary?

Updating flag for affected latest Nightly

status-firefox74: --- → affected

Dana, given that we have shipped multiple releases with this bug and that it is unassigned, should the prioritu be downgraded or a person assigned? Thanks

Flags: needinfo?(dkeeler)
Flags: needinfo?(dkeeler)
Priority: P1 → P2
Whiteboard: [psm-backlog]

It sounds like this wasn't actually a regression from bug 1553804 but has been the case for years. Is that right?

Yeah.

Keywords: regression
No longer regressed by: 1553804
Severity: normal → S4
Assignee: nobody → dkeeler
Status: NEW → ASSIGNED
Priority: P2 → P1
Whiteboard: [psm-backlog] → [psm-assigned]
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5190e209a5ba
rework certificate deletion so it happens immediately r=rmf

https://hg.mozilla.org/mozilla-central/rev/5190e209a5ba

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox81: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Flags: qe-verify+

Reproduced the initial issue with Firefox 81.0a1 (20200807213618) on Windows 10x64.
The issue is verified fixed with Firefox 81.0b8 (20200908191057) on Windows 10x64, macOS 10.12 and Ubuntu 18.04. The certificate is no longer shown after deletion.

Status: RESOLVED → VERIFIED
status-firefox81: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: