Closed Bug 271585 Opened 15 years ago Closed 15 years ago
Add UTN root CA certs to NSS
171.08 KB, patch
|Details | Diff | Splinter Review|
171.91 KB, patch
|Details | Diff | Splinter Review|
12.84 KB, application/x-zip-compressed
48.41 KB, image/jpeg
43.33 KB, image/jpeg
Per my comments in bug 242610 I'm approving addition of the UTN root CA certificates to Mozilla. For more information, including the certs themselves and their SHA-1 fingerprints, see bug 242610.
Added "CA" to bug summary so that it will show up in searches for "Add CA"
Priority: -- → P2
Summary: Add UTN root certs to NSS → Add UTN root CA certs to NSS
Target Milestone: --- → 3.10
I am about to attach two patches to this bug, one for NSS 3.9 branch, one for the trunk. Each of the patches will add all the root CA certs that are presently approved by Frank.
Status: NEW → ASSIGNED
This patch should also be directly applicable to any othet mozilla branches that contain copies of NSS derived from NSS 3.9.
This patch adds the same certs as the previous patch, but this patch is for the NSS trunk.
Comment on attachment 167308 [details] [diff] [review] Add all remaining approved root CA certs to NSS 3.9 branch Wan-Teh, please review
Attachment #167308 - Flags: review?(wchang0222)
Comment on attachment 167309 [details] [diff] [review] Add all remaining approved root CA certs to NSS trunk Wan-Teh please review
Attachment #167309 - Flags: review?(wchang0222)
Nelson, I had a recent email from the Comodo/UTN folks. All is unchanged from before *except* that they would like the trust bits on *all* the certs set to 'all'. IIRC I previously had indicated that one of them was to be marked trusted for S/MIME only. (My apologies for forgetting about this previously.)
Now, frank, why should a CA whose explicit purpose is to issue email certs be trusted to issue code signing certs? Do we want all email certs to also be code signing certs? Do we want to erase any ability to distinguish among certs for different purposes? If we wish to continue to have separate certs for separate purposes, and if this CA already has separate roots for separate purposes, then the justification for giving code signing trust to an email CA cert is what, exactly?
There are several ways that a CA organization can segregate purposeful trust among the certs that they issue. Here are some of the ways they can do it: 1. have separate root CA certs, one for each purpose, each one of which is trusted for a single purpose. Those root CAs then issue certs that have no extensions that further limit their purpose. The leaf certs appear to be good for everything, but when you go look at their issuer you find that the issuer is only trusted for one thing, ergo the leaf cert is also only good for one thing. 2. Have one root CA that is trusted for all purposes, that issues intermediate CA certs, each of which has exntensions that limit the purposes for which it is trusted. The intermediate CAs may then issue certs that appear to have no restriction on purpose, but (as with case 1 above), when validating the chain, the relying party finds that the issuer (intermediate) is only trusted for limited purposes, and so the leaf cert is only good for those limited purposes also. 3. Have one (or more) issuing CAs that are trusted for all purposes, but those issuers all put extensions in every leaf cert they issue stating exactly what purpose the leaf is for. Now, suppose, under case 1 above, that a CA has a cert that says it is only good for email, and it issues certs that have no extensions that further restrict their abilities. But the root CA cert's trust flags get set to trust that cert for ALL capabilities, not just for email. The consequence of this is that the certs issued by that CA are all useable as code signing certs. The moral of this story is this: we should not mark root CA certs as trusted for code signing UNLESS we know that the CA's audited CPS says that the CA will take adequate steps, through extensions in intermediate and/or leaf certs, to distinguish code signing certs from non-code-signing certs. In other words, we should give code signing ability to CAs in cases 2 and 3 above, not in case 1. And I interpret the content of the UTN email root cert as suggesting that it is case 1. OK, I realize that this comment probably really belongs in bug 233453. I think that our policy should state that, before we will give a single root CA cert more than one kind of trust (SSL, email, code signing), we will require the CA to demonstrate that they are properly segregating capabilities through the use of extensions in intermediate and/or leaf certs, and/or that their audited CPS states that they will do so, and how they will do it. Otherwise, someday we're going to find that some CA's email certs are also all code signing certs, and our code signing story will be dead.
The comments above appear to concern only code signing, but they are also applicable to SSL service trust and email trust. Generally, however, the amount of verification of identity done by CAs is the greatest for code signing, and the least for email. So, IMO, we should take special care to ensure that we do not allow certs that were intended to be email certs only to also work as SSL server or code signing certs. One way we could fail to take that care is to give SSL server trust or code signing trust to a root CA cert whose own extensions clearly identify it as not being intended for those purposes.
Per comments above, and in private email, I have revised the above patch to correct the spelling and capitalization of the nicknames, and to alter the trust flags for some of the CAs. Except for the trust flags and nicknames, the rest of the large patch is computer generated, so rather than repeat the entire large patch to show these changes, I will instead show below the output of certutil -L with my latest patch in place. This shows the nicknames and trust flags. Builtin Object Token:QuoVadis Root CA C,C,C Builtin Object Token:Security Communication Root CA C,C,C Builtin Object Token:Sonera Class 1 Root CA C,C,C Builtin Object Token:Sonera Class 2 Root CA C,C,C Builtin Object Token:Staat der Nederlanden Root CA C,C,C Builtin Object Token:TDC Internet Root CA C,C,C Builtin Object Token:TDC OCES Root CA C,C,C Builtin Object Token:UTN DATACorp SGC Root CA C,p,p Builtin Object Token:UTN USERFirst Email Root CA p,C,p Builtin Object Token:UTN USERFirst Hardware Root CA C,p,p Builtin Object Token:UTN USERFirst Object Root CA p,p,C Frank, since the AOL folks are out for a few days, I'm going to let you approve (or not) the changes based on the above certutil output. If you approve, then I will checkin tonight when I get home.
I'm sorry, I won't be able to review this in time for you to check it in tonight. I'll look at it tomorrow morning. One question: could you please explain the representation of the trust bits (e.g., "C,p,C")? (I guess I could look at the certuil docs -- please feel free to provide a URL and tell me to RTFM.)
Nelson, thanks for the explanation via email re the "C" and "p". For the rest of the world, here's what's going on: The 'p's are somewhat spurious; in this context they simply mean that the trust bit for a particular purpose is not set. The 'C' is the important bit (pardon the pun). A setting of 'C,C,C' means the root CA certificate is "trusted" (in a NSS/Mozilla/etc. context) for all purposes. 'C,p,p' means trusted for SSL server purposes only, 'p,C,p' means trusted for S/MIME email purposes only, and 'p,p,C' means trusted for object signing only. Now on to the certs themselves. All names look OK, the only remaining question is the trust bits on the UTN certs. This is a balance between the technical considerations of limiting trust to the types of certificate that the CA has traditionally issued and is likely to issue in the furure, and the more marketing consideration of giving CAs the latitude to expand the types of certs they issue without having to go back to us to have trust bits changed. We've been relatively liberal in the past in marking trust bits as requested by CAs, often setting trust bits to 'all' as requested even in cases where it was apparent that the CA never had issued a particular type of cert and never was likely to. I believe we need to tighten this up, but I also think it's unfair to Comodo/UTN to make them the test case on this, in large part I've never been that explicit in what our policy actually was, nor have I been rigorous in enforcing a policy. Also, Comodo/UTN has been more helpful than most CAs in providing the detailed information about their CAs' uses needed to set trust bits, and thus somewhat perversely they're being held to a tighter standard than CAs who are not so forthcoming. So, Nelson, in the short-term I'm approving this patch, with the exception that I'd like you to set the trust bits for the UTN CAs to 'all' ('C,C,C') as is being done for the other CAs. In the longer-term I want us to tighten up our policy on trust bits, and make our policy more explicit. I think this entails at least two things: First, I will make a concerted effort up-front to determine the purposes for which a CA is being used, and then recommend setting trust bits to the minimum necessary to match those purposes. If a CA isn't providing enough information to make this determination then I will hold up approval until it does. Second, we need to plan how we're going to quickly change trust bits as needed in order to reflect new circumstances. This might include turning trust bits off to address potential security issues, or turning them on to reflect expansion in the types of certs issued by a CA. For the foreseeable future we'll need to do this via new releases of NSS and update releases of Mozilla, et.al., but maybe we can do better than that at some point, e.g., through some sort of dynamic update mechanism. (I've already mentioned this in relation to speeding the addition of new CA certs.) One point brought up by the Comodo/UTN folks was that for an organization running multiple root CAs, it might be necessary for one of the CAs to take over functions for another of the CAs, e.g., in the event that one of the root CA certs had to be revoked; thus it would be better it set trust bits to 'all' for all the organization's CAs. Notwithstanding my recommendation above re the UTN root certs, I don't really accept this argument: If a CA has problems sufficient to revoke its root cert, then we'd presumably treat this like other potential security vulnerabilities and release an updated version of NSS and then Mozilla, etc., to correct the problem, and we could update trust bits for an organization's other CAs at the same time. The major counter-argument I can see is that it might take some time to do the update, and in the meantime the other CAs wouldn't be able to fully take over the revoked CA's functions as far as Mozilla users were concerned. This reinforces the idea of planning for quick updating of CA-related information.
Frank, UTN certs all have extensions in them that say precisely what they're valid for. MOST PKI software in the world will honor those self-imposed limitations. That's a safety feature of X.509 PKI hierarchies. It means that if the CA ever issued a cert and forgot to limit the uses of that cert with an EKU, the abilities of that cert will nonetheless be limited according to the STATED PURPOSE of the issuing CA. Our trust flags are capable of being overrides. They can give a cert abilities that are not listed on its face. In this case, you're asking me to override the limitations that are built into all the UTN root CA certs themselves. As I explained in comment 9 above, if UTN has published ANY EE (leaf, end-user) certs that do NOT have EKU extensions that explicitly prohibit their use as code signing certs, and we apply the requested trust flags to their roots, then we will have just turnd all those (say) email certs (that lack EKUs) into code signing certs. That would be a disaster. It would make code signing meaningless for every user of a browser that trusts that email root CA. (I'm picking on the email CA, but the issue is also valid for other CAs that are not code signing CAs.) At this point, we haven't even established that UTN routinely puts EKUs into those email certs. Maybe they do, maybe they don't. Given that the roots have EKUs, they wouldn't need to (with normal PKI software that honors a CA cert's own EKUs). Maybe they never have. IMO, it would be irresponsible of us to override the EKUs in these apparently carefully crafted root CA certs, until we know that (a) the already issued certs have EKUs and (b) the audited CPS says that the EE certs will continue to have EKUs. AFAIK, we have never before had a case where a CA sent us a root cert that said, on its face, that it was limited to a certain purpose, or set of purposes, and then asked us to override those purposes, enabling all purposes -- especially not for a root CA cert that had already been used (was not a brand new CA). I do not that that what we've done in the past is equivalent to such overrides, and I think it sets a bad precedent to start doing such overrides now without any better reason than has been given to me to date.
I have one modification to the cert processing that nelson describes above: For historical reasons, code signing privellege does not automatically flow to subordinates. When code signing was added, there wasn't a well defined way to limit trust on subordinate CA certificates. At that time there were netscape specific ways of specifying a particular cert was a subordinate CA, and some CA's that wanted to issue Signing certs had already issued such subordinate. Because of this Jeff Weinstein required the code signing extension on each and every subordinate. Unless we have changed that semantic, Code Signing still follows that semantic. Another bit of history to explain why trust is an override: In the early days some very popular CA's had very old root certs which had not extensions labelling them as CA certs. Because of this we needed to override the processing of those certs when determining trust. (this also allows us to override trust at from a subordinate rather than a whole chain). bob
Bob what you say is true for Netcape's old "object signing", but IINM, not for "code signing" (different OID). Please double check.
Comment on attachment 167308 [details] [diff] [review] Add all remaining approved root CA certs to NSS 3.9 branch Both approvals are assuming it's OK to distinguish the trust on the UNC certs. It seems to me that getting this patch in at this point is preferable to waiting on the final disposition of setting all the trust bits on the UNC tokens.
Attachment #167308 - Flags: review?(wtchang) → review+
Thanks, I expect to checkin tonight, unless I hear "stop" before then.
Nelson, I don't claim to be an expert on the EKU issue, so I will defer to your technical judgement on this point. Let's go ahead and do the patch with CA names and trust bits as you outlined originally; if this proves to be a problem we can update things later. (In any case these certs won't show up in a client release immediately; given release schedules and the closed window for TB 1.0 changes my current plan is to file bugs to get the CA cert patch into Mozilla 1.8 and post-1.0 releases of Firefox and Thunderbird.)
Thanks, Frank. We can certainly come back and add more trust flags in a later release. I think it's best to add the certs with conservative trust flags that match the capabilities stated in the certs themselves. Then if we later decide that we really do want to override and extend those capabilities with trust flags, we can do that.
Trunk checkin: mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 1.30; previous revision: 1.29 mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 1.31; previous revision: 1.30 mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v <-- nssckbi.h new revision: 1.12; previous revision: 1.11 NSS 3.9 branch checkin: mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 188.8.131.52; previous revision: 184.108.40.206 mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 220.127.116.11; previous revision: 18.104.22.168 mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v <-- nssckbi.h new revision: 22.214.171.124; previous revision: 126.96.36.199 For testing purposes, for a short time (weeks), a copy of a debug build of nssckbi.dll with these certs added, built from the NSS 3.9 branch, may be obtained for testing at http://nelson.bolyard.com/mozilla/nssckbi.dll I invite the representatives of the various CAs to download it and test it. Please add any comments (reflecting success or failure) to this bug. It passes my tests. I will add another attachment to this bug, which is a zip file containing the CA certs and the shell script that I used to add them to nssckbi.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: 3.10 → 3.9.5
This zip file contains all the DER certs that I added to the trunk and to the 3.9 branch. It also contains the shell script that I ran to add them. The same files and same script were used on both trunk and branch. The only difference was the addbuiltin program used by the script, which was the 3.9 version for the branch, and the trunk version for the trunk.
We (ICTU) tested the "Staat der Nederlanden Root CA" in Firefox 1.0 and Thunderbird 1.0 (original bug https://bugzilla.mozilla.org/show_bug.cgi?id=243424). In Firefox we tried to make a SSL connection with a website that uses the "Staat der Nederlanden Root CA". In Thunderbird we tried to verify a signed e-mail. The results are as follows: I. Firefox: There where no problems while establishing an SSL connection with Firefox. II. Thunderbird: An error message in the Thunderbird client showed up saying "Could not verify this certificate because the issuer is not trusted." We had to import the "Staat der Nederlanden Root CA" manually (and other intermediate certificates) in Thunderbird. The certificate viewer in Firefox says: "This certificate has been verified for the following uses: SSL Certificate Authority." We want ALL the certificate uses to be present (i.e. websites, e-mail users and software developers). III. With regard to the Extensions fields in the certificate viewer: 1. Basic constrains: shows a hexadecimal value, i.e. not human readable 2. Certificate Policies: shows a hexadecimal value, i.e. not human readable 3. Certificate key usage: shows only "Certificate Signing". Key usage "CRL Signing" should also be present. 4. Subject key identifier: should only show A8:7D:EB:BC:63:A4:74:13:74:00:EC:96:E0:D3:34:C1:2C:BF:6C:F8, but Firefox shows: 04:14:A8:7D:EB:BC:63:A4:74:13:74:00:EC:96:E0:D3:34:C1:2C:BF:6C:F8 These extension fields should show something like this (results with OpenSSL): 1. Basic Constraints: CA:TRUE 2. Certificate Policies: Policy: Any Policy CPS: http://www.pkioverheid.nl/policies/root-policy 3. Certificate Key Usage: critical Certificate Sign, CRL Sign 4. Subject Key Identifier: A8:7D:EB:BC:63:A4:74:13:74:00:EC:96:E0:D3:34:C1:2C:BF:6C:F8 IV. Some more general questions: a. Why don't Thunderbird and Firefox use the same (shared) certificate store? Now both applications have their own nssckbi.dll file. b. It was not possible to verify a signature in Thunderbird after importing the "Staat der Nederlanden Root CA", because no intermediate certificate authorities where in the certificate store. After manually importing them, the signature could be succesfully verified. Is there a possibility to automatically add these intermediate authorities when you sign an e-mail in Thunderbird? I hope the above is clear to you. Thanks for your actions. In case you have any questions, please let us know.
> I. Firefox: There where no problems while establishing an SSL connection > with Firefox. Thanks for testing and confirming that. > II. Thunderbird: An error message in the Thunderbird client showed up > saying "Could not verify this certificate because the issuer is not > trusted." Perhaps you replaced the nssckbi.dll file in your Firefox installation, but not in your TBird installation? That would be my guess. Perhaps TBird was still running when the DLL was replaced, so it was still using the old one? That's another possibility. If both FF and TB have their nssckbi.dll file updated, and are both restarted, they should both see the new roots in them. > III. With regard to the Extensions fields in the certificate viewer: There are lots of issues with the mozilla/TB/FF cert viewer. They are generic issues that apply to all certs with the relevant cert extensions, and are not specific to the Nederlands cert. They would be the subject of another bug report. In any case, the code in Moz/TB/FF that decides on cert validity does not depend on the cert viewer, so even if the cert viewer cannot satisfactorily display all the parts of the cert, that does not mean that mozilla will not properly use those parts. > IV. Some more general questions: > > a. Why don't Thunderbird and Firefox use the same (shared) certificate store? > Now both applications have their own nssckbi.dll file. > > b. It was not possible to verify a signature in Thunderbird after > importing the "Staat der Nederlanden Root CA", because no intermediate > certificate authorities where in the certificate store. After manually > importing them, the signature could be successfully verified. Those intermediate CA certs should be part of the messages whose signatures are being verified. The sender of a signed message needs those certs in his cert store, so that he can send them along with the signed message. The sender should get those certs when he gets his own cert from the CA. The CA that issues his own cert should also download the intermediate CAs to him when he gets his own cert. The recipient of a signed message does not need the intermediate CA certs in his cert store, because they should be in the signed message. If they are not in the signed message, the sender has erred. Perhaps the sender's CA did not download the intermediate CA certs when it downloaded the user's own email cert.
Thanks for your quick reply. > > II. Thunderbird: An error message in the Thunderbird client > showed up > > saying "Could not verify this certificate because the issuer is not > > trusted." > > Perhaps you replaced the nssckbi.dll file in your Firefox > installation, > but not in your TBird installation? A. No, the problem is that TBird does not validate the certificate chain. We have a certificate hierarchy that consists of four CA certificates. When I import the CA certificate that issued the end-user certificate TBird validates the signature, even without a Root CA in the certificate store! Maybe you could reproduce this and after you have confirmed, we will make a seperate bug report for this. > > III. With regard to the Extensions fields in the certificate viewer: > > There are lots of issues with the mozilla/TB/FF cert viewer. > They are generic issues that apply to all certs with the relevant > cert extensions, and are not specific to the Nederlands cert. > They would be the subject of another bug report. B. OK, we will make a new bug report with the certificate viewer issues on the extension fields. Or are you aware of an existing bug report on this? Can we consider the message on verification in the cert viewer as a bug too? Because, although the Dutch root cert is verified for all uses, the cert viewer only shows: "This certificate has been verified for the following uses: SSL Certificate Authority." (see attachment "Staat der Nederlanden.jpg"). Strangely enough, for other certs, like Thawte, the cert viewer shows verification for all uses (see attachment "Thawte.jpg"). C. Besides the above issues we experienced problems with importing a pkcs#7 file. Firefox and Tbird seem to randomly import just one cert instead of the whole chain. Would you recommend to file a seperate bug for this too? D. Finally, we are wondering why the Mozilla apps don't use the same (shared) certificate store? Is there any particular reason? We believe it would be a good idea to have one cert store that is used by all Mozilla apps and that can be used by other applications too. Please, let us know if we are wrong. Thanks again for your reply and actions.
Just as a comparison with the information the cert viewer shows for the Dutch Root cert.
The issues with TBird's UI reported above are WAY outside the scope of this completed NSS bug (enhancement) report/request. They are probably important issues, but this bug report isn't the place to discuss them. I suggest you raise your concerns in news://news.mozilla.org:119/netscape.public.mozilla.crypto
Comment on attachment 167308 [details] [diff] [review] Add all remaining approved root CA certs to NSS 3.9 branch 1.7.5 has shipped. Moving request to 1.7.6.
Attachment #167308 - Flags: approval1.7.5? → approval1.7.6?
Mass re-assign of 3.9.5 fixed bugs to 3.9.6 , since we built 3.9.5 with the same source tree as 3.9.4 .
Target Milestone: 3.9.5 → 3.9.6
Comment on attachment 167308 [details] [diff] [review] Add all remaining approved root CA certs to NSS 3.9 branch Too late for 1.7.6, and removing obsoleted approval-aviary request (aviary approvals now need to use aviary1.0.x flags)
Chris, the patch was checked in, and this bug marked resolved in December 2004. There have been two NSS releases made since then that included it. So, just how, exactly, was it too late?
Comment on attachment 167308 [details] [diff] [review] Add all remaining approved root CA certs to NSS 3.9 branch Chris, Frank, You two need to discuss these new root CA certs before the Mozilla Foundation releases Mozilla 1.7.6 and Firefox 1.0.1. These root CA certs missed the Firefox 1.0 deadline. I remember that we told the CAs that we will add their certs to the next Firefox update. These root CA certs have been tested on the Mozilla trunk for a while as Nelson pointed out.
Attachment #167308 - Flags: approval-aviary1.0.1?
Comment on attachment 167308 [details] [diff] [review] Add all remaining approved root CA certs to NSS 3.9 branch Firefox 1.0.1 shipped last week. Minusing.
Attachment #167308 - Flags: approval-aviary1.0.1? → approval-aviary1.0.1-
The certs in question (for this particular bug report) have been in the NSS 3.9 branch and on the trunk since December. I believe NSS_CLIENT_TAG includes them. (not sure though.) It's completely unclear to me in what way they were "too late". If firefox shipped without them, then someone in firefox land apparently didn't take them. IIRC, Frank filed a bug about this against firefox months ago, and someone from firefox closed it saying that no work needed to be done for it. WTF?
Comment on attachment 167308 [details] [diff] [review] Add all remaining approved root CA certs to NSS 3.9 branch > It's completely unclear to me in what way they were "too late". Basically, Firefox 1.0.1 is already out, Mozilla 1.7.6 is about to go out. We can get this into 1.7.7 and firefox 1.0.2. I will approve this for aviary 1.0.2. Please hold off on checking into the 1.7 branch for now though until 1.7.6 is done.
Attachment #167308 - Flags: approval-aviary1.0.2? → approval-aviary1.0.2+
Ah HA! Your answer reveals the problem, I think. You wrote: > Please hold off on checking into the 1.7 branch The NSS team supports the NSS trunk and the NSS branches, only. For other branches, it is the responsibility of those branch owners maintainers to keep their branches in sync with NSS. NSS folks do not, as a rule, checkin on those other branches. If the NSS changes were "too late" because you were waiting for an NSS developer to checkin on some non-NSS branch, they will always be too late. (haven't we had this discussion before?)
The problem was the failure to use the appropriate tools in Bugzilla to get this on mozilla.org drivers' radar. Chris, please advise how to get this patch into "aviary 1.0.2" and "aviary 1.1". (which cvs branches, etc.) You can consider me a Mozilla developer.
Wan-Teh, I believe this is the wrong bug to be marked blocking aviary*. Bug 272901 appears to me to be the right one.
Comment on attachment 167308 [details] [diff] [review] Add all remaining approved root CA certs to NSS 3.9 branch Approval flags shouldn't have been migrated with the blocking flags.
Attachment #167308 - Flags: approval-aviary1.0.3+ → approval-aviary1.0.2+
Comment on attachment 167308 [details] [diff] [review] Add all remaining approved root CA certs to NSS 3.9 branch a=dveditz for 1.7.6, released delayed and will now match 1.0.2
Attachment #167308 - Flags: approval1.7.6- → approval1.7.6+
*** Bug 272901 has been marked as a duplicate of this bug. ***
Comment on attachment 167308 [details] [diff] [review] Add all remaining approved root CA certs to NSS 3.9 branch I checked in the new root CA certs (nssckbi module version 1.42) on the AVIARY_1_0_1_20050124_BRANCH (Aviary 1.0.2) and the MOZILLA_1_7_BRANCH (Mozilla 1.7.6).
Verified with Firefox 1.0.2 that the UTN root CA certs are in the "Builtin Object Token" with the following trust settings: The UTN root CA certs have been added with the following trust settings. UTN-USERFirst-Client Authentication and Email: This certificate can identify mail users. UTN-USERFirst-Hardware: This certificate can identify web sites. UTN - DATACorp SGC: This certificate can identify web sites. UTN-USERFirst-Object: This certificate can identify software makers.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.