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)

51 Branch
x86_64
Windows
defect

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
Attached image selfSigned.png
Assignee: nobody → dkeeler
Priority: -- → P1
Whiteboard: [psm-backlog] → [psm-assigned]
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
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.
(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
Based on that last comment, we shouldn't do this, right?
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 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+
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
https://hg.mozilla.org/mozilla-central/rev/df65d15b648d
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Is this something we would want in the ESR?
This is too late for ESR...
I don't think this is essential for ESR.
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
Depends on: 1373791
No longer depends on: 1373791
You need to log in before you can comment on or make changes to this bug.