Offer to edit trust on roots imported with user certs

RESOLVED WONTFIX

Status

()

--
enhancement
RESOLVED WONTFIX
11 years ago
3 years ago

People

(Reporter: steve.roylance, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; MS-RTC LM 8)
Build Identifier: Firefox 3 Release Candidate 2

In some ways this is similar to Bug 185243.   GlobalSign has two root CA's with the same key material. One is currently embedded as a trusted root in FF3RC2, however the other, which is due to be embedded shortly currently issues Personal e-mail certificates.  Importing an e-mail cert, which is chained to the 2028 root, correctly installs the root into the store, however none of the properties are marked.  (i.e. use for identifying web sites)  Even when the root properties are edited the web site returns an error.   To highlight that there is no problem in directly importing the root, this was done and it works fine.  Both Root CAs can co-exist and it correctly chains to the 2028 root if a secure site is loaded.   It seems the Personal certificate import completely kills the root operations

Reproducible: Always

Steps to Reproduce:
1.Connect to https://www.globalsign.com and see that the site is chained to the root that expires in 2014.  Then obtain a GlobalSign e-mail demo certificate which is valid for 90 days. http://www.globalsign.net/secure_demo.cfm 
2. Apply using IE6/7 as we don't want to create directly in Firefox. Once you have the cert (e-mail challenge response), export to a PKCS#12
3. Import into FF3RC2 and then try to connect to https://www.globalsign.com
Actual Results:  
Even if you delete all the GlobalSign certificates from the store (They all reappear later as built in security objects), the browser always fails to connect to a globalsign secured site.

Expected Results:  
The performance of web sites should not be affected, but ideally as a new root cert is being added users should be asked if they trust for other purposes.  the current workflow is inconsistent.
(Reporter)

Comment 1

11 years ago
I want to add that the roots in question are available here:-

Current Root embedded in FF3RC2
http://secure.globalsign.net/cacert/Root.crt

Proposed Root to be embedded  (Same key material)
http://secure.globalsign.net/cacert/Root-R1.crt 

thanks.
(Reporter)

Comment 2

11 years ago
Additional testing and discussion with Nelson Bolyard shows that I need to rename the title of the bug to "inconsitency in certificate root import method."
and down grade severity. 

It still needs fixing to improve the user experience.

i.e. 

import a root by the front door (Directly) and the GUI presented to the user asked for trust bits to be set.

import a root by the back door and the trust bits are all set to off (even if it's an e-mail cert being imported).   Firefox should ask the user to set the trust bits for the new root.

Severity: major → enhancement
(Reporter)

Updated

11 years ago
Summary: Import PFX to Personal Store Kills Root Authority Capability → Inconsistency in Root import workflow method.
I confirm that this is an enhancement request. :)

I would summarize this RFE as follows:

When importing a "user" cert (a cert for which the private is locally held)
and its associated cert chain, if the chain includes a root CA certificate, 
that is not already known to the product, offer to let the user edit the 
trust on the imported root. (but that's too long for the bug summary field. :)
Assignee: nobody → kaie
Status: UNCONFIRMED → NEW
Component: Security → Security: PSM
Ever confirmed: true
OS: Windows Vista → All
Product: Firefox → Core
QA Contact: firefox → psm
Hardware: PC → All
Summary: Inconsistency in Root import workflow method. → Offer to edit trust on roots imported with user certs
Version: unspecified → Trunk

Comment 4

9 years ago
Yes, this absolutely ought to be implemented. See the now-resolved Bug 527029 for a good use case.
reassign bug owner.
mass-update-kaie-20120918
Assignee: kaie → nobody
This isn't a feature that is widely applicable to Firefox users. As such, I don't think working on it would be a good use of our engineering resources. This might be better as an add-on.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX

Comment 7

3 years ago
I agree.  This was a one-off requirement back in 2008.  Oh how the years flash by.  It's fine to close this down.   Thanks.  Regards   Steve
You need to log in before you can comment on or make changes to this bug.