Closed
Bug 1294580
Opened 8 years ago
Closed 7 years ago
NSSCertDBTrustDomain allows end-entities to be their own trust anchors
Categories
(Core :: Security: PSM, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla54
Tracking | Status | |
---|---|---|
firefox54 | --- | fixed |
People
(Reporter: kjozwiak, Assigned: keeler)
References
Details
(Whiteboard: [psm-assigned])
Attachments
(3 files)
When importing certificates from the Windows root store via the enterprise roots feature from bug#1265113, fx will import/accept certificates that are non-CA's. We should investigate and make sure there's nothing going wrong here. Attached a screenshot as an example as well. Test Case Used: * open certlm.msc and import self-signed.badssl.com.crt (attached) into the "Trusted Root Certification Authorities" bucket * once imported, refresh the bucket and ensure that "*.badssl.com" appears under the "Trusted Root Certification Authorities" bucket * install the latest version of m-c and visit https://self-signed.badssl.com/, you'll recieve the "Your connection is not secure" page * add security.enterprise_roots.enabled;true into about:config * refresh https://self-signed.badssl.com/ and you'll notice that it's working now (still works after restarting fx) * change security.enterprise_roots.enabled;false and refresh https://self-signed.badssl.com/, you'll get the "Your connection is not secure" page
Reporter | ||
Comment 1•8 years ago
|
||
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → dkeeler
Priority: -- → P1
Whiteboard: [psm-backlog] → [psm-assigned]
Comment 2•8 years ago
|
||
I believe network administrators who have a need to place a self-signed certificate in their Microsoft Certificate Store will want to use this tool to quickly duplicate that storage into their FF store. A network administrator wants the easiest method to make the two stores equivalent (no matter what their security point-of-view); they want the seat security (Microsoft's store) to be duplicated in the Firefox store. Norman
Assignee | ||
Comment 3•8 years ago
|
||
As far as I can tell, putting a self-signed (or even a non-CA) certificate into the Windows root store doesn't result in Internet Explorer or Chrome trusting that certificate when visiting a site that uses it (this is on Windows 8.1). I imagine we should match that behavior with the enterprise roots feature in Firefox.
Reporter | ||
Comment 4•8 years ago
|
||
(In reply to David Keeler [:keeler] (use needinfo?) from comment #3) > As far as I can tell, putting a self-signed (or even a non-CA) certificate > into the Windows root store doesn't result in Internet Explorer or Chrome > trusting that certificate when visiting a site that uses it (this is on > Windows 8.1). I imagine we should match that behavior with the enterprise > roots feature in Firefox. I quickly went through several other platforms using a non-CA certificate and can confirm that that's the case with both IE and Chrome. Platforms Used: * Win 10 x64 - doesn't accept the non-CA certificate in the Windows root store * Win 8 Pro x64 - doesn't accept the non-CA certificate in the Windows root store * Win 7 Pro SP1 x64 - doesn't accept the non-CA certificate in the Windows root store * Win Vista Ultimate SP2 x64 - doesn't accept the non-CA certificate in the Windows root store
Comment 5•7 years ago
|
||
Based on that last comment, we shouldn't do this, right?
Assignee | ||
Comment 6•7 years ago
|
||
Right. We should probably also not allow end-entities to be their own trust anchors in general, so I'm updating the summary.
Summary: fx accepting/using non-CA certificates when importing from Windows root store → NSSCertDBTrustDomain allows end-entities to be their own trust anchors
Comment hidden (mozreview-request) |
Comment 8•7 years ago
|
||
mozreview-review |
Comment on attachment 8841058 [details] bug 1294580 - prevent end-entity certificates from being their own trust anchors https://reviewboard.mozilla.org/r/115404/#review116986 Makes sense, thanks.
Attachment #8841058 -
Flags: review?(cykesiopka.bmo) → review+
Assignee | ||
Comment 9•7 years ago
|
||
Thanks! https://treeherder.mozilla.org/#/jobs?repo=try&revision=adcb1e8e7747
Comment 10•7 years ago
|
||
Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/df65d15b648d prevent end-entity certificates from being their own trust anchors r=Cykesiopka
Comment 11•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/df65d15b648d
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox54:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Comment 12•7 years ago
|
||
Is this something we would want in the ESR?
Assignee | ||
Comment 14•7 years ago
|
||
I don't think this is essential for ESR.
Comment 15•7 years ago
|
||
If I'm reading this correctly, Firefox is treating certlm.msc as the standard for what is acceptable for import, however certmgr.msc on Windows Desktop as well as Apple Keyring on MacOS (up to current) don't prohibit the non-CA certificates and for small, self-signed implementations, this design works quite well. > + // If an end-entity certificate is manually trusted, it may not be the root of > + // its own verified chain. In general this will cause "unknown issuer" errors > + // unless a CA trust anchor can be found. I guess this is where I'm confused. Although I understand why a CA shouldn't be it's own anchor, I'm not sure why it needs to be a CA to begin with. This makes developers that wish to import a certificate go through an unnecessarily complex trust chain, no? What is the benefit of not allowing non-CA certificates? Reference: https://stackoverflow.com/questions/44550970
You need to log in
before you can comment on or make changes to this bug.
Description
•