Would it be possible to try the Firefox 102 binary from Mozilla (you can get it from https://www.mozilla.org/en-US/firefox/all/#product-desktop-esr) and see whether it's fixed there or not (we are currently working on bringing the Firefox 102 to RHEL so would be good if 102 fixes your problem).

Thanks for looking into this.

This happens also with 102.1.0esr.

The minimal steps to observe the issue are:

1) rm -rf /tmp/test ; mkdir /tmp/test ; firefox --profile /tmp/test --new-instance ;
2) Visit a site using self-signed certificate, accept the certificate
3) Close the tab, delete the just accepted certificate Certificates -> View Certificates -> Servers
4) Close Firefox, notice how the certificate name is still seen with "certutil -d sql:/tmp/tmp -L"

Thanks.

The certutil command should obviously read "certutil -d sql:/tmp/test -L" in the above step 4).

this is reproducible with the latest nightly (739265:51f435ff98d3). the root cause here is that self-signed cert has

X509v3 Basic Constraints: critical
                CA:TRUE

so it gets added as "server" certificate as well as "CA" certificate which makes sense bc it is self-signed. so in order to get rid of it one has to remove it from "Servers" AND "Authorities" in FF then the new self-signed cert with the same serial can be used.

my take on it is that technically it is not a bug (bc self-signed) but usability wise i can see how it can be confusing and thus needs addressing somehow tho it is hard to imagine regular users experiencing this (self-signed certs with same serial numbers).

i will have a look at the code and if it can be addressed in a straightforward kinda way i might try to fix it there.

this has been fixed upstream. the way it works now, when creating an override exception, is that certificates are not added to certdb at all, see https://hg.mozilla.org/mozilla-central/rev/0795946482ee

Status: ASSIGNED → RESOLVED
Closed: 2 days ago
status-firefox115: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 115 Branch