Closed Bug 557717 Opened 10 years ago Closed 10 years ago

AOL Root Certificates Inconsistent with NSS

Categories

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

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: david, Assigned: KaiE)

References

()

Details

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: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4

At the cited URI, select the link to "List of all included root certificates".  According to that list, the root certificates AOL Time Warner Root Certification Authority 1 and AOL Time Warner Root Certification Authority 2 should have all trust bits "on".  As installed in SeaMonkey 2, it appears that all trust bits are "off".  This adversely impacts anyone accessing a secure Web page whose site certificate chains up to one of those two AOL roots.  

Reproducible: Always

Steps to Reproduce:
1.  Print the Web page at <https://wiki.mozilla.org/CA:UserCertDB> for reference in the following steps.  

2.  To ensure that you are looking at the NSS read-only database and not at a user-specified alteration, follow the steps for SeaMOnkey indicated in the section "Deleting a Root Certificate" to delete the two cited AOL roots.  

3.  Terminate and then launch SeaMonkey.  According to the section "How Mozilla Products Respond to User Changes of Root Certificates", that should restore the two roots to their state as contained in the NSS read-only database.  

4.  For each of the two AOL roots, follow the steps for SeaMonkey under the section "Changing Root Certificate Trust Bit Settings" through step 7 but not further.  

Actual Results:  
The checkboxes for the trust bits are blank.  

Expected Results:  
The checkboxes for the trust bits show show check marks.  

Kathleen Wilson confirms that the proper settings for these trust bits is "on".  They are indeed "on" in the NSS read-only database for Thunderbird 3.0.4, which I have installed; and Wilson asserts they are "on" for the current version of Firefox, which I do not have installed.  

I inquired about this in the mozilla.dev.apps.seamonkey newsgroup but saw no reply.
Same applies for Minefield (Mozilla/5.0 (Windows; U; Windows NT 6.0; nl; rv:1.9.3a4pre) Gecko/20100405 Minefield/3.7a4pre - Build ID: 20100405051240)
After removing the certificates and restarting Minefield they are no longer trusted.
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: SeaMonkey → Core
QA Contact: seamonkey → psm
Version: unspecified → 1.9.2 Branch
Version: 1.9.2 Branch → Trunk
I believe there is a misunderstanding.

If you use certificate manager to delete one of the root CA certs that are embedded in software, you will not delete it, but, you will remove all trust.

I assume you attempted to delete a root.
That had the effect to remove all trust bits.

> 3.  Terminate and then launch SeaMonkey.  According to the section "How Mozilla
> Products Respond to User Changes of Root Certificates", that should restore the
> two roots to their state as contained in the NSS read-only database.  


Not sure where you found this.
It's not true.

If you delete a certificate, the software will effectively remove all trust bits, and remember it! It will be remembered in your "profile".

So, if you delete, restart, use "edit", and all three boxes are "not checked", that's absolutely expected!


If you see what I describe, the behaviour is expected, and this bug report invalid.

I apologize for this confusing application  behaviour, it's been there since I've started the project 9 years ago :-/

We have several bugs on file for this misleading behaviour, that "delete" doesn't really delete, but remove trust. Search bugzilla for "delete cert" and you'll see several open bugs where this is being tracked.
Kai, that's amazing. The above mentioned is correct and we all have been giving out wrong information at the mailing list, probably for a long time.
This is what I now understand:   

If I delete a root certificate that has an instance in the NSS read-only database, all trust bits for that certificate are turned "off".  During that session, the certificate disappears from the Certificate Manager display.  If I then terminate SeaMonkey and then relaunch SeaMonkey, the certificate reappears in the Certificate Manager display.  However, without editing and thus copying the certificate to the user's certificate database, there is no way to restore the trust bits.  

If this is true, there is a hole in the capabilities of the Certificate Manager.  Having tweaked a root certificate by either changing its trust bit settings or deleting it, there should be a way to restore that certificate to its state in the as-delivered NSS read-only database.  

Further, the Wiki at <https://wiki.mozilla.org/CA:UserCertDB> is misleading and requires revision beyond my competency.
(In reply to comment #4)
> This is what I now understand:   
> 
> If I delete a root certificate that has an instance in the NSS read-only
> database, all trust bits for that certificate are turned "off".


That's correct.
We really effectively deleted it.
While we still "know" about the cert, we have disabled it.


> During that
> session, the certificate disappears from the Certificate Manager display. If I
> then terminate SeaMonkey and then relaunch SeaMonkey, the certificate reappears
> in the Certificate Manager display.  


Yes.
It will even reappear immediately if you close cert manager and reopen it.
It's a display bug, and a usability bug.


> However, without editing and thus copying
> the certificate to the user's certificate database, there is no way to restore
> the trust bits.  

Wrong.
The certificate is still there, just have trust removed.

You don't need to restore the certificate.
If you want to trust it again, all you need is restore the trust.

You click "edit", you enable the trust bits you want to grant, you click ok, and the root cert is effective again.


> If this is true, there is a hole in the capabilities of the Certificate
> Manager.  Having tweaked a root certificate by either changing its trust bit
> settings or deleting it, there should be a way to restore that certificate to
> its state in the as-delivered NSS read-only database.

Wrong, it's possible to restore as I explained in the previous paragraph.


> Further, the Wiki at <https://wiki.mozilla.org/CA:UserCertDB> is misleading and
> requires revision beyond my competency.

Yes, we must correct that.
> Important: This change may be overridden when you restart the program. If the
> root certificate that you deleted is still in Mozilla's default root store,
> then the root certificate will be included again the next time you restart the
> program. 

This paragraph is misleading.

And our UI is misleading as well :-( See also bug 173729

I hope to land the UI change proposed over there soon, see bug 173729 comment 8.

Regarding the above text, what about the following new text:

"Important: The behaviour of the user interface may be misleading. If you delete one of the certificates contained in the root store, you will effectively disable it. All trust will be removed from the root certificate. However, because of a technical limitation, the certificate will still be present. So, don't be confused if you see it again, when you come back to certificate manager at a later time. You can verify that it's "disabled" by using the "edit" button. It will tell you that all trust flags are still removed."
I must not have been clear in my comment #4.  

If I delete a root certificate using Certificate Manager, the certificate is not deleted but all trust bits are set "off".  If I then use Certificate Manager to edit that certificate to turn all trust bits "on", that will be done in a copy of the certificate that is placed in the user's certificate database, not in the read-only NSS database.  

The need to restore the root certificate to its as-delivered state in the NSS read-only database arises if the NSS database itself is later updated in a new delivery of a Mozilla or Mozilla-based product.  The deletion or modification of a certificate in the NSS database or the changes in a certificate's trust bits of a certificate are overridden (but not overwritten) by what is in the user's own certificate database.  Having "restored" the trust bits by editing them in the Certificate Manager thus causes a user to fail to obtain any later NSS updates to that certificate.  

Perhaps explaining what led to this bug report might help.  I experienced a failure to enter a secure Web page.  I traced it to the fact that one of the AOL root certificates had all trust bits "off".  I thought that perhaps I might have turned them off quite some time ago, but I could not remember doing that.  Not knowing which of the trust bits should be "on", I deleted the certificate with the expectation that I would thereby restore its as-delivered state.  That did not happen.  

Thus, I believe the lack of being able to restore a root certificate to its as-delivered state in the NSS read-only database -- eliminating any copy of that certificate in the user's own database -- is a hole in Certificate Manager capabilities.
(In reply to comment #7)
> I must not have been clear in my comment #4.  
> 
> If I delete a root certificate using Certificate Manager, the certificate is
> not deleted but all trust bits are set "off".  If I then use Certificate
> Manager to edit that certificate to turn all trust bits "on", that will be done
> in a copy of the certificate that is placed in the user's certificate database,
> not in the read-only NSS database.  

I believe both, the setting off and on, happens in the user DB. Perhaps until the trust bits match those of the read-only DB, but most likely forever. Meaning, once a built-in root was "touched" by the user, there remains a copy in the user DB.
Note: I have updated https://wiki.mozilla.org/CA:UserCertDB to correct the descriptions as per this bug.
Okay.  This bug does not really describe a problem, so I'm closing it as Invalid.  

To address the capability that I described in the last paragraph of my comment #7, I have submitted RFE bug 558222.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.