Closed Bug 383988 Opened 17 years ago Closed 15 years ago

Unable to Set Trust Settings on New Certificate Authority (CA)

Categories

(Camino Graveyard :: Preferences, defect)

Product:
Camino Graveyard
Component:
Preferences
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino2.0

People

(Reporter: khalsah, Assigned: stuart.morgan+bugzilla)

References

Details

(Keywords: fixed1.8.1.24, regression, Whiteboard: [camino-2.0])

Attachments

(1 file)

Fix
3.21 KB, patch
alqahira
: review+
mikepinkerton
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4) Gecko/20070509 Camino/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4) Gecko/20070509 Camino/1.5

When I try to install a new CA it tells me that the certificate could not be verified for some unknown reason. It lets me check the box to trust it for SSL but that setting does not get saved. When I go into preferences and view the certificates and look under authorities and open the one I installed it shows all the trust checkboxes unchecked. I can check the boxes but when I close and reopen the trust settings are gone. It continues to say that the certificate could not be verified.

If I add the CA in firefox and copy over the cert8.dat & key3.dat files (I just guessed that these were where the data was) the settings copy over and the certificate is now installed and trusted.

Reproducible: Always

Steps to Reproduce:
1. Download a new CA... the one I was trying to load is http://ca.mit.edu/mitca.crt
2. Check the box to trust for SSL.
Actual Results:  
The CA is loaded but gets stored as untrusted.

Expected Results:  
The Trusts settings selected should have been stored.
This was mentioned in bug 315044; it's unclear whether this is the same bug as that or not (certificates vs. CAs)....
In bug 315044 Adam says that this worked in 1.0.x and broke sometime before December 2006.

Can we get some help testing old nightlies from the time the 1.8.0 branch split from the 1.8 branch (2005-12-09) until Adam's bug 315044 comment 12 (2006-12-29) to find when this broke?

You want builds from http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ in folders that end with "-1.1-M1.8".

Thanks!
Hi Smokey,

The earliest "-1.1-M1.8" build I see is 

http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2006-04-16-00-1.1-M1.8/

This builds exhibits the "inability to trust CAs" problem.  Let me know if there are builds between 2005-12-09 and 2006-04-16 that you would like me to test.  Regards,

Adam


You can get a few more builds here: http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/experimental/

Does the problem also exist on the trunk?  If so, you can use the "-trunk/" builds (after late April 2006), and builds *without* a "-1.0/" or "-0.8/" prior to that, to track back beyond March 2006.
I am able to reproduce this with every certificate installation I attempt - from a variety of sources other than just MIT (using 1.5, that is).

Some quick observations:

Camino was unable to obtain a display name for any of the certificates I tried.  Instead, it refers to the authority as "(no nickname)."  This means nothing is returned for either -[CertificateItem commonName] or -[CertificateItem nickname].  While this seems like another bug, perhaps it is indicative of a larger problem altogether.  I guess it's possible that if Camino is downloading and setting up the CA information incorrectly it might prevent trust settings from applying/persisting.

Unsurprisingly, "IsCertTrusted failed for <CertificateItem: 0x3534c7c0>" is NSLogged each time.

I'll keep looking to find out more and to determine if these issues are related.
Certificate, or CA?  Simon explained the issue with being unable to set settings on certificates it couldn't verify in bug 315044 comment 11 (which has apparently always been broken; trusting a new CA used to work in 1.0.x).
(In reply to comment #6)
> Certificate, or CA?
I was referring to trusting a new Certificate Authority.  Firefox does parse the CA exactly like we do in that it cannot obtain a display name and is unable to verify for unknown reasons.

The segment of code where the failure to save trust settings occurs is:
http://mxr.mozilla.org/mozilla/source/camino/src/security/CertificateView.mm#239

For the test case MIT cert, isValid and isUntrustedRootCACert return NO and control skips over the normal trust bit mask setting.  All this really does is concretely explain Simon's comment which you referred me to, though.  If canGetTrust is YES for this test case, the settings are properly saved.

The builds which do exhibit correct behavior are able to do so because the certificate is verified for them.  It might help to determine why this certificate cannot be verified anymore.  Firefox seems willing to remember trust settings even for unverified certificates.
The problem does exist on the trunk.  I find it's introduced between the 2006-01-09 and 2006-01-10 trunk builds.  Regards,

Adam


(In reply to comment #4)
> You can get a few more builds here:
> http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/experimental/
> 
> Does the problem also exist on the trunk?  If so, you can use the "-trunk/"
> builds (after late April 2006), and builds *without* a "-1.0/" or "-0.8/" prior
> to that, to track back beyond March 2006.
> 


Thanks, Adam.

That range produces nothing interesting when using the normal Camino module; when we switch to "all files in the tree" http://tinyurl.com/yu92lj there are some NSS candidates (except clients always pull an NSS client tag, and presumably checkins to mozilla/security on the trunk are checkins to "NSS trunk", not to the NSS_CLIENT_TAG that was in use then?).

Anyway, mozilla/security checkins are bug 137506, bug 149834, bug 316710, and bug 101996.  Looking at the CVS graphs for files in there to see when a checkin (or bug) landed, the ones that landed on trunk and 1.8 but not 1.8.0 seem to be bug 149834 and bug 101996, and bug 137506.

Assuming CmTrunk actually pulled those new files that day, which one seems most likely to have caused this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Kai, do you have any idea which of the bugs in comment 9 might have caused this?
The the bugs mentioned in comment 9 are related to check ins to the trunk of NSS, then these are probably unrelated. Yes, you would have to compare the NSS_CLIENT_TAG before and after the regression time.

Does the error console display anything when you attempt to edit the trust?

If this is an error that appears only in Camino, but neither in Firefox nor in SeaMonkey, then it seems unlikely a change in NSS could have caused this Camino specific regression.

Hi Kai,

Not sure exactly what you mean be error console.  I see no messages in console.log, and no error message pops up in the browser.

I also note that once I have unchecked "Identifying websites (for SSL)" on a valid CA, no further changes can be made to any of the trust settings.  For example, I try to uncheck the "Identifying e-mail users (in an e-mail program)" box, but this is not saved when I hit OK.

Finally, any of you should be able to reproduce this bug yourself by unchecking the "Identifying websites (for SSL)" box for most any certificate listed in Authorities.  I have found only two exceptions during spot-testing where I can uncheck and then recheck that box:  these are Digital Signature Trust Co. / DST RootCA X1 and X2.  Regards,

Adam
I don't know about Camino, but in Firefox, one of the menus has an entry "error console" that reports problems that occur at runtime.
I had something between a hunch and a wild guess today, so I whipped up this build which includes some stuff we heretofore were not including:

http://www.ardisson.org/smokey/moz/Camino-Branch-20071128-CertifTest.dmg  (this is roughly today's Camino 1.6a1pre build with my changes)

Adam, Hargobind, can you guys check and see if this build fixes this bug (unable to set trust settings on a new CA) for you?
I'm afraid it doesn't work for me.

I didn't do much testing but the original case that caused me to submit the bug is  still there. 
Doesn't work for me, either.

Adam
(In reply to comment #11)
> The the bugs mentioned in comment 9 are related to check ins to the trunk of
> NSS, then these are probably unrelated. Yes, you would have to compare the
> NSS_CLIENT_TAG before and after the regression time.

Kai, how can one find the content of the NSS_CLIENT_TAG (files/revisions) on a given day?  Or is (was) mozilla/security/manager not versioned by that tag, and we could just take checkins to the Mozilla trunk at face value for that directory tree, e.g., if a patch landed that day, it would be in the following nightly build?  (I ask that because "All files in the repository" and "CoreTinderboxAll" Bonsai modules show those bugs from comment 9 as landing, but neither the "NSS" nor "SecurityServices" Bonsai modules show those bugs landing.)
I've verified by local backout on the MOZILLA_1_8_BRANCH that bug 149834 is "responsible" for this.  Presumably some piece of our certificate implementation needs to be updated for the changes in bug 149834?

Nominating this for 1.6.2 so this stays on the branch radar, even though it won't make 1.6.2 unless we get a patch very soon.
Blocks: 149834
Flags: camino1.6.2?
> Kai, how can one find the content of the NSS_CLIENT_TAG (files/revisions) on a
> given day?

You can't easily.
However, I have an archive of day-by-day changes produced by a daily script at http://kuix.de/misc/nssctdiffs/


> Or is (was) mozilla/security/manager not versioned by that tag

Correct.
This directory this part of Mozilla, not NSS.
It's Mozilla's own glue code on top of NSS.


NSS consists of the directories:
mozilla/security/nss mozilla/security/coreconf mozilla/security/dbm mozilla/dbm

John, could you help us out here? You wrote the patch that "broke" this, so I assume you know the code well enough to offer some suggestions as to what we need to do on our end to fix it. The relevant Camino code lives in

http://mxr.mozilla.org/mozilla/source/camino/src/security/CertificateItem.mm

I'll have some time to debug this next week, I think, but any pointers you can give before then would be greatly appreciated.

Assigning to myself for now so it stays on my radar.
Assignee: nobody → cl-bugs-new
Hardware: Macintosh → All
Here's what I get in Console with a debug build when following the STR in comment 0:

2008-06-13 00:17:13.218 Camino[90686:10b] IsCertTrusted failed for <CertificateItem: 0xd0355f0>
2008-06-13 00:17:13.249 Camino[90686:10b] IsCertTrusted failed for <CertificateItem: 0xd0355f0>
2008-06-13 00:17:13.255 Camino[90686:10b] IsCertTrusted failed for <CertificateItem: 0xd0355f0>
2008-06-13 00:17:13.276 Camino[90686:10b] GetUsagesString returned 128 ()
2008-06-13 00:17:13.277 Camino[90686:10b] <CertificateItem: 0xd0355f0> GetUsagesString verified for SSL client: 128
2008-06-13 00:17:13.286 Camino[90686:10b] <CertificateItem: 0xd0355f0> GetUsagesString verified for SSL server: 128
2008-06-13 00:17:13.289 Camino[90686:10b] <CertificateItem: 0xd0355f0> GetUsagesString verified for SSL CA; 16
2008-06-13 00:17:13.290 Camino[90686:10b] <CertificateItem: 0xd0355f0> GetUsagesString verified for email signer; 128
2008-06-13 00:17:13.293 Camino[90686:10b] <CertificateItem: 0xd0355f0> GetUsagesString verified for email recipient; 128
2008-06-13 00:17:13.303 Camino[90686:10b] <CertificateItem: 0xd0355f0> GetUsagesString verified for object signing; 128
2008-06-13 00:17:13.304 Camino[90686:10b] <CertificateItem: 0xd0355f0> GetUsagesString verified for verify CA; 0

My, that patch was created over 4 years ago.  Basically, it was a mechanical change from an older API that only allowed one to verify a cert's trust for one purpose at a time to a newer, supposedly equivalent API that allowed one to check multiple purposes at once.  If reverting that change causes things to work, then the two APIs perhaps aren't as equivalent as they should be.

I'm afraid I don't even know what language a .mm file is written in, but it seems odd that the code would be trying to verify a cert's trust when trying to install a CA or modify a CAs trust bits.  Perhaps this is getting into the issues of bug 193960--the code is confusing the set of purposes for which a cert is currently trusted with the set of purposes for which a cert is capable of performing should it be trusted.  An interface for editing trust bits needs to know the latter, but unfortunately the code sometimes relies on the former to infer the latter.  Per bug 238146 and bug 236887, the NSS team has not yet provided APIs necessary for determining the possible purposes of a cert.



This is way over my head. Sorry.
Assignee: cl-bugs-new → nobody
Flags: camino1.6.3?
Flags: camino1.6.2?
Flags: camino1.6.2-
If we find out what's happening here (perhaps in investigation of bug 453075) and have a sufficiently branch-safe patch, we'll take it in 1.6.x.
Flags: camino2.0?
Flags: camino1.6.5?
Flags: camino1.6.4?
Flags: camino1.6.4-
Flags: camino1.6.5? → camino1.6.5-
Attached patch Fix — — Splinter Review 
So this is based on guesswork, but I'm pretty confident that this is what was actually intended by the code--and it does in fact fix the bug. I'd be more confident if the blame trail for the changes were helpful, but of course it isn't :P

At the point where we save settings, we either read the state of the checkboxes, or we read from the cert directly, depending on the return of "[mCertItem isValid] || [mCertItem isUntrustedRootCACert]" (which, as murph found earlier, is false here). In trying to figure out why that check might have been desirable, I found that same logic in exactly one other place:
  BOOL enableCheckboxes = YES;  // [mCertItem isValid] || [mCertItem isUntrustedRootCACert];

So it appears that intent of the check when saving was "if the checkboxes are enabled, read them, if not, read from the cert", which makes sense. But then the checkbox check was changed, and this one wasn't, and sadness ensued.

I'm leaving the old check, since I'm reluctant to remove it without knowing if there's a reason it was left commented out, but I'm factoring it out into a method that both places use so this never happens again. Now if the user is given the ability to change the settings, we actually use what they tell us, which obviously makes more sense than giving them the illusion of control.
Assignee: nobody → stuart.morgan+bugzilla
Status: NEW → ASSIGNED
Attachment #406574 - Flags: superreview?(mikepinkerton)
No reason not to put this into 1.6.11 now that we have a fix.
Flags: camino2.0?
Flags: camino2.0+
Flags: camino1.6.11+
Target Milestone: --- → Camino2.0
(In reply to comment #27)
> No reason not to put this into 1.6.11 now that we have a fix.

This should probably fix bug 315044 there, right (I believe the cert error stuff on 1.9.0 "fixed" it in 2.0)?
I'm not entirely clear what that bug is about, but it sounds like it's about different UI, so I'm not sure it will.
Comment on attachment 406574 [details] [diff] [review]
Fix

sr=pink
Attachment #406574 - Flags: superreview?(mikepinkerton) → superreview+
Landed on CVS trunk and CAMINO_2_0_BRANCH. I'll test and land on the 1.8 branch shortly.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [camino-2.0]
Comment on attachment 406574 [details] [diff] [review]
Fix

I forgot I don't have a 10.3.9 SDK any more. Over to Smokey for the building and testing.
Attachment #406574 - Flags: review?(alqahira)
Comment on attachment 406574 [details] [diff] [review]
Fix

Fun error message-changing, but we can leave that part of the snake pit for someone else ;) r=ardissone
Attachment #406574 - Flags: review?(alqahira) → review+
Landed on the MOZILLA_1_8_BRANCH for Stuart in advance of Camino 1.6.11.
Keywords: fixed1.8.1.24
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: