Closed Bug 1300420 Opened 8 years ago Closed 6 years ago

macOS (Mac OS X) platform support for trusting enterprise roots

Categories

(Core :: Security: PSM, defect, P1)

Product:
Core
Component:
Security: PSM
Platform:
All
macOS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla63
Tracking Flags:
Tracking Status
firefox63 --- verified
firefox67 --- verified

People

(Reporter: yuki, Assigned: keeler)

References

(Blocks 1 open bug)

Details

(Whiteboard: [psm-assigned])

Attachments

(1 file)

bug 1300420 - add enterprise root support for OS X r?franziskus
46 bytes, text/x-phabricator-request
spohl
: review+
franziskus
: review+
Details | Review
The bug 1265113 treats only Windows platform. Grev told that another bug for Mac OS X (macOS) must be filed as a separate bug (at https://bugzilla.mozilla.org/show_bug.cgi?id=1265113#c27 ) but I couldn't find out it, thus I've filed this.
Priority: -- → P3
Whiteboard: [psm-backlog]
+1 I was just about to file this same bug. Please incorporate similar functionality provided by the security.enterprise_roots.enabled setting on the Windows platform of Firefox. On the Mac OS platform this should allow for honoring certificates present in the System section of the Keychain.
+1. I'm surprised this is setting wouldn't be enabled by default either. What's the idea? Aren't system certs and trusts meant to be respected by all applications? Why maintain a duplicate set of certs in every application. Doesn't make a lot of sense. Chrome seems to do the right thing.
Because Firefox 57 (public release) doesn't support any legacy addons, we need this feature on macOS to use custom certs. And this is also need to be fixed before Firefox 59, because it will be the next ESR and after Firefox 52ESR becomes outdated we lose the way to import custom certs automatically.
Hi Yuki, Unfortunately, due to engineering and time constraints, this will not be implemented in time for 57. It's also unlikely to make it into 59. Here are some options to address automatically installing new trust anchors: * Write a program to modify the user's NSS certificate database directly. This would be just like the add-on you had before, except it would operate on a lower level: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS * Use the certificate manager to import the necessary root certificates once, and then use the resulting cert8.db file as a basis for all future installs of Firefox (if you put that file in the user's profile and then run Firefox, the new trust anchors will be available for them). * Propose a new WebExtension API that allows for specifying additional trust anchors: https://webextensions-experiments.readthedocs.io/en/latest/ * Host the additional trust anchor(s) on a server protected with a publicly-trusted certificate. Users can request the URL for the certificates and Firefox should offer to import and trust them. Hope this helps.
it is actually quite simple to programmatically import a root CA into Firefox. Although it would make an admins life much easier if Firefox could just use Certificates in the System.keychain. Here is a quick guide on how to implement the Certificates into Firefox. (Tested on 10.12-10.13 with Firefox 57-58.0.2) https://github.com/soberhofer/Firefox-RootCA
There was already a bug for this. https://bugzilla.mozilla.org/show_bug.cgi?id=963354 Should we dupe there?
From my reading that's for client certs, not root certs.
I agree with keeler. I consider this slightly different behavior. It's our request that something similar to the security.enterprise_roots.enabled be implemented on the MacOS version of Firefox. This specifically allows for instructing Firefox to trust root certs trusted by the OS. This functionality on Windows machines has allowed for much smoother implementation of Firefox in an Enterprise environment. I understand there are a few ways that you could script or automate importing certificates into Firefox but none of those are clean enough, in my opinion, for automating a large scale environment. Particularly not if you have any concerns about overwriting settings that the end-user has previously configured.
If the preference security.enterprise_roots.enabled is set to true, the platform will import trusted TLS certificates from the OS X keystore.
Assignee: nobody → dkeeler
Priority: P3 → P1
Whiteboard: [psm-backlog] → [psm-assigned]
:spohl, could you also have a look at this from the point of view of API correctness? Thanks! (It doesn't look like you're in the phabricator system yet, otherwise I would have marked you for review there...)
Flags: needinfo?(spohl.mozilla.bugs)
Comment on attachment 8992447 [details] bug 1300420 - add enterprise root support for OS X r?franziskus Stephen A Pohl [:spohl] has approved the revision. https://phabricator.services.mozilla.com/D2169
Attachment #8992447 - Flags: review+
Comment on attachment 8992447 [details] bug 1300420 - add enterprise root support for OS X r?franziskus Franziskus Kiefer [:fkiefer or :franziskus] has approved the revision. https://phabricator.services.mozilla.com/D2169
Attachment #8992447 - Flags: review+
Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7635ef4a997d add enterprise root support for OS X r=spohl,franziskus
Thanks for the reviews!
https://hg.mozilla.org/mozilla-central/rev/7635ef4a997d
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox63: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Flags: needinfo?(spohl.mozilla.bugs)
Once we've got some testing on this, can we request uplift? Also, how risky do you think this is for ESR?
Steps for verifying: 1. Install some sort of TLS-intercepting software that puts its root in the OS X keystore. I used avast, but NB avast actually also adds its root to your Firefox profile directory (maybe only on installation? I'm not quite sure), so to verify this bug you have to manually remove it in the certificate manager (about:preferences -> search for "certificates" -> "View Certificates" -> Authorities -> scroll down to "Avast", select it and "delete/distrust", and then restart Firefox) 2. Confirm that if the about:config preference "security.enterprise_roots.enabled" is set to false, https pages don't load ("Your connection is not secure") 3. Confirm that if the preference is set to true, https pages do load (both if the preference is set during a session and if the preference is set and the browser is restarted) Let me know if I can provide further detail. If testing goes well, I'll make the case for ESR uplift (although unfortunately I think this would depend on one or two other uplifts...)
Flags: qe-verify?
Flags: qe-verify? → qe-verify+
Case 1 Macbook Pro: 1) Installed Avast antivirus on a Mac OS X and activated the Web Shield. 2) After installing, the websites were not loading. (In my case also, this is available only on installation) 3) I deleted Avast from Certificates, security.enterprise_roots.enabled was still false and websites still not loading. 4) Set security.enterprise_roots.enabled to true and the web pages were loading. Case 2 Mac: 1) Installed Avast antivirus on a Mac OS X and activated the Web Shield. 2) After installing, the websites were not loading. (In my case also, this is available only on installation) 3) I deleted Avast from Certificates, but after restarting the browser the Avast was not deleted and the sites were not loading neather 4) I set security.enterprise_roots.enabled to true, the web pages were loading and Avast was deleted from Certificates also. Case 1, from what I understood from Comment 18 is the expected behaviour after the fix. Case 2, is not the expected behaviour. Keeler, can you please take a look over this and tell me you opinion? Thanks
Flags: needinfo?(dkeeler)
Hmmm - would you mind re-trying with the case 2 mac with the environment variable MOZ_LOG set to "pipnss:4" and MOZ_LOG_FILE set to some output file? (and then uploading that output file) Also, are there OS version differences between the two machines? Thanks!
Flags: needinfo?(dkeeler)
keeler: Can you provide some info on whether or not this could be uplifted to ESR? (not for this upcoming release, but for the next).
Mike - unfortunately we'd have to either uplift a number of patches (~9, depending) or basically re-write the feature for esr60, neither of which I'm that confident about (particularly since we don't even have an automated test for this on OS X). So I think it would be best if this just rode the trains.
Is there a way to fix this as this bug is making Firefox the least desired browser to use on MacOS for those on corporate environmnets. Safari and Chrome are able to succesfully use the operating system Keychain, why Firefox cannot use it?
Just to make things even worse, when I tried to manually upload the certificate on last MacOS release (Mojave), Firefox 62.0.2 got stuck... I had the impression that the file upload bug was supposed to be fixed before official MacOS release day... which is today Sep 24.
(In reply to Sorin Sbarnea from comment #24) > Is there a way to fix this as this bug is making Firefox the least desired > browser to use on MacOS for those on corporate environmnets. Safari and > Chrome are able to succesfully use the operating system Keychain, why > Firefox cannot use it? Sorin, This is fixed in Firefox 63 (currently in Beta), scheduled for release on 2018-10-23. We'd appreciate it if you'd try it out in Beta and let us know if you run into any problems.
(In reply to Sorin Sbarnea from comment #25) > Just to make things even worse, when I tried to manually upload the > certificate on last MacOS release (Mojave), Firefox 62.0.2 got stuck... > > I had the impression that the file upload bug was supposed to be fixed > before official MacOS release day... which is today Sep 24. We're trying to get syslogs for this probem. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1489785
Hi, I'm facing similar issue with Mozilla latest versions 63 and 64 in Mac OS 10.10 to 10.14 versions. I've a trusted certificate in local keychains, but still mozilla is not detecting that as a trusted one, even after setting security.enterprise_roots.enabled to true (Same is working as trusted site in Safari and Chrome). Is this fix available for Mac firefox release. Your help is very much appreciated. Thanks, Shashi
Shashi: Please open a new bug for this issue.

I am marking this bug as verified, tested it using the steps from comment 18 on Nightly 67.0a1 (2019-02-06) and Firefox/63.0 Build ID: 20181114214635.

Status: RESOLVED → VERIFIED
status-firefox63: fixed → verified
status-firefox67: --- → verified
Flags: qe-verify+

There is one problem with Firefox 65.0 at least: you need to restart the browser in order to validate the certificate after import. Unless you do this, it will not recognize it.

That shouldn't be the case - can you open a new bug with as much detail as you can include? https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security%3A%20PSM

Flags: needinfo?(sorin.sbarnea)
Flags: needinfo?(sorin.sbarnea)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: