Closed Bug 432802 Opened 16 years ago Closed 8 years ago

Recognize Windows trusted root certificates

Categories

(Core :: Security: PSM, enhancement)

Product:
Core
Component:
Security: PSM
Platform:
x86
Windows XP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1265113

People

(Reporter: schapel, Unassigned)

References

Details

Attachments

(1 file)

random glyphs in Certificates (MMC)
55.46 KB, image/png
Details 
Steps to reproduce:

1. Follow the instructions for importing the CAcert root certificate into Windows for multiple users at <http://wiki.cacert.org/wiki/BrowserClients#head-d4c1b1f6c75b7427d2957978e4537333888447bb>.

2. Go to <https://www.cacert.org/> using Firefox.

Expected Results: Firefox uses the newly imported root certificate.

Actual Results: Firefox says that cacert.org uses an invalid certificate.

The use case for this enhancement is that we currently use self-signed certificates on our internal network for connecting to our mail server and file server. We would like to use free-as-in-beer certificates, such as CAcert certificates, without getting warnings about invalid certificates, and without importing each certificate into each program on each computer. If we could import a root certificate once onto each computer and have all programs recognize our certificates, it would mean that it would take less work to maintain the certificates and also security would be increased because the number of false "invalid certificate" warnings would decrease (and therefore they would be less likely to be ignored).
use startssl.com certs. they're free as in beer. your use case is void :)

Frank, in bug 215243 comment 163, you wrote:
3. Some CAs consider their root CA certs to be copyrighted material subject to
limitations on redistribution.

Supposing someone were to implement the feature requested for this bug, would it violate this point?

(fwiw, current fennec and mozilla mobile plans include a system PKCS11 module for CA Roots.)
I applaud Steve Chapel's desire to get away from using self signed server 
certs.  I understand his desire to use free certs.  There are CAs that are
already known to and trusted in both Windows and Mozilla products and offer 
free certs. (Besides beer, what other kind of freedom is relevant to certs?)

So, the best result is obtained by using a cert from one of those CAs.  
Then you don't have to install ANY new server or CA certs in your client 
systems AT ALL, and you'll have the peace of mind from knowing that you're
relying on certs from a CA that actually PASSED an audit. :)

Work was once begun to develop a PKCS#11 module that interfaced to Windows'
cert stores.  A lot of that work is done, but that work is unfinished and 
is an orphan. There is no funding to work on it, and no-one has demonstrated 
the personal motivation to do so, either.  

So, my recommendation is: get a free SSL server cert from StartSSL.
(In reply to comment #1)
> use startssl.com certs. they're free as in beer. your use case is void :)
> 
> Frank, in bug 215243 comment 163, you wrote:
> 3. Some CAs consider their root CA certs to be copyrighted material subject to
> limitations on redistribution.
> 
> Supposing someone were to implement the feature requested for this bug, would
> it violate this point?

Exactly what feature are you referring to? What Steve Chapel was doing was to simply import a root into the Windows system root store, which we don't use.

In any case, IIRC the only reason some CAs claim copyright wrt to roots is to justify implementing a "click wrap" agreement whereby end users downloading and importing the root agree to be bound by the CA's relying party agreement.


One problem with StartSSL certs is it seems that Outlook does not trust them by default <http://forum.startcom.org/viewtopic.php?f=15&t=1404>. Is there another CA that offers free certs that are trusted by Firefox, Internet Explorer, and Outlook by default?
It is somewhat premature, but the problem with the StartCom CA and Microsoft software should be solved by the end of this year. This is not an official statement, just a small hint...

There are various CAs which offer client (S/MIME) certificates for free, see http://kb.mozillazine.org/Getting_an_SMIME_certificate
For server certificates StartCom (StartSSL) is apparently still the only CA providing them for free.
frank: i meant that if we were to start "using" (or "automatically importing") certificates from the windows store...
it should not only deal with the trusted certificates, but also intermediary (issuing) certificates from the windows OSes cert stores that not necessarily are directly trusted themselves
a good approach how this could be done is in adobe acrobat reader v8+
摁牤獥䉳潯k
奍
䅃
for people curious.... that comes from the MMC Certificates hierarchy.

If you don't understand what it is, then do you expect our users or our software to be able to understand if it's trustworthy? (fwiw, neither Mook nor myself know what those mean or from whence they came)

<mk:@MSITStore:%windir%\help\CMconcepts.chm::/sag_CM_PKIRef.htm>

the help for "certificates" starts by referencing 8 books. - This isn't a bad practice, I suppose. OTOH, I don't expect most users to go out and buy all 8 books just to figure out what those random glyphs mean.

Note that the strings you get in the Certificates hierarchy can be localized (although presumably for the basic stores there's a magic key name). Some stores are for things that are trusted, and some are for things that are *NOT* trusted. 

The docs mention a "Disallowed Certificates" <http://technet.microsoft.com/en-us/library/cc757138.aspx> (seems to be a public equivalent of the online help), but that doesn't exist (it's "Untrusted Certificates" in wXP)

As such, we can't simply assume all stores mean "trust this".

Similarly, wrt Intermediate Certification Authorities,

My list has this gem:
CN = Root Agency
Valid From: May 29, 1996 12:02:59 AM
Valid To: January 1, 2040 1:59:59 AM
Serial Number: ‎06 37 6c 00 aa 00 64 8a 11 cf b8 d4 aa 5c 35 f4
For Testing Purposes Only Sample Software Publishing Credentials Agency
Public key (RSA 512 bits)
30 47 02 40 81 55 22 b9 8a a4 6f ed d6 e7 d9 66 0f 55 bc d7 cd d5 bc 4e 40 02 21 a2 b1 f7 87 30 85 5e d2 f2 44 b9 dc 9b 75 b6 fb 46 5f 42 b6 9d 23 36 0b de 54 0f cd bd 1f 99 2a 10 58 11 cb 40 cb b5 a7 41 02 03 01 00 01

That certificate is explicitly available for testing but is not intended to be trusted.

This last bit is precisely why comment 8's request should be WONTFIX.
Assignee: kaie → nobody
Note that there is an NSS-based PKCS#11 module that is a gateway to Windows'
cert stores, including the trusted cert stores.  I believe it is considered
unfinished and not officially supported, but someone could pick it up and 
finish it, I think.  See it at 
http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/
I'm surprised that this issue is still not fixed. This seems to me like a very important feature for FF on Windows (especially in an enterprise context). We too would like to roll out a self-produced root CA for our internal services, but because of this we can only do this for IE and Chrome users. FF is my favourite browser, but it seems we have to drop FF support in our organization because of this, and force everyone to either IE or Chrome.

IE, Chrome, Safari and others happily trust the OS to manage trusted certificates for them. I can't begin to estimate the amount of users that FF has lost to Chrome only because of this ... it must be millions.

At this point it's not clear to me whether this is not implemented because of some principle or strategic consideration (i.e. "won't fix" -- but then I don't understand why), or simply because nobody has done the necessary work.

Can someone please take another look?
(In reply to Johan Corveleyn from comment #13)
> At this point it's not clear to me whether this is not implemented because
> of some principle or strategic consideration (i.e. "won't fix" -- but then I
> don't understand why), or simply because nobody has done the necessary work.

Windows does not provide a mechanism for us to differentiate a root that is trusted by Windows because it is in Microsoft's root program vs. a root that is trusted by Windows because the user or sysadmin added it. Mozilla does not want to automatically trust certificates just because they are in Microsoft's root program; it is important for us that we maintain our own root CA program. So far that has meant avoiding any system root store integration on Windows. Also, on all platforms, this just never becomes a high priority. Now the priority is on improving the trustworthiness of TLS for sites that are using CAs from our root CA program.
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #14)
> Windows does not provide a mechanism for us to differentiate a root that is
> trusted by Windows because it is in Microsoft's root program vs. a root that
> is trusted by Windows because the user or sysadmin added it. Mozilla does
> not want to automatically trust certificates just because they are in
> Microsoft's root program; it is important for us that we maintain our own
> root CA program. So far that has meant avoiding any system root store
> integration on Windows. Also, on all platforms, this just never becomes a
> high priority. Now the priority is on improving the trustworthiness of TLS
> for sites that are using CAs from our root CA program.

Most users won't care much for Mozilla's root CA program, or for being able to discern builtin roots from sysadmin-added roots. Why not trust the OS to properly maintain root CA's, like so many other services and other browsers? Perhaps offer it only as an option? Users just want to get things done, and if another (good) browser does it for them, they will happily switch browsers (and there goes your leverage at the negotiation table).

The important thing here is that right now it's easy for Windows sysadmins to distribute their own CA cert accross their organization, as long as they limit their browsers to IE and Chrome. Trying to support FF in this scenario is very difficult, if not impossible, so the result is usually that they drop internal support for FF, and only want to deal with IE and Chrome.

For lots of organizations setting up their own small PKI infrastructure for some internal services is a perfectly normal and valid use case.
Another late arrival to this discussion, but it just became relevant to me.  I am performing HTTPS inspection at the gateway, which requires an internal certificate to be trusted.  This is easy enough to accomplish by distributing the certificate via Windows Group Policy to all my workstations; however, since FF doesn't trust the Windows Certificate Store, anyone using FF in the domain now has a broken browser.  We are now kicking around the idea of no longer "officially" supporting FF in the domain for this reason and one other:  we have been unsuccessful at finding a complete ADMX for FF in order to deploy and manage it consistently across the domain.  I know that sounds like a separate issue/bug/ticket, but has anyone found a way to manage the certificates for FF via GPO (ADMX file)?

I just want to echo the sentiment that for windows sysadmins, it is very easy to distribute CAs & certs to workstations in their organizations, and that doing so in FF is complicated at best.  I can't speak for everyone, but I know that I just don't have the resources (time or personnel) to dedicate to it.  It is much easier to drop FF altogether and use IE and Chrome.  Chrome was comparatively simple to deploy and manage across the board (including extensions & apps).  They offer a separate MSI, an enterprise/business guide with examples/case studies - there's even an NSA whitepaper on securing it.  Is some compromise worth the greater adoption?
Jesse: the folks at https://wiki.mozilla.org/Enterprise might be able to help you with some of these issues.

As this bug notes, due to the way the Windows APIs work, recognizing the Windows trust store is equivalent to abandoning our own root program and adopting whatever Microsoft decides (because we can't tell which certs are user-imported and which are MS-provided). That would not be a good thing for the web.

Gerv
Gerv,

As a security professional and former sysadmin; I can empathize with the sentiment, and definitely understand the viewpoint.  On the other hand, as part of a managed services provider company; there just isn't a straightforward mechanism for an enterprise deployment that gives system administrators familiar territory to work in (Group Policy), and to deploy their internal certificates without generating help desk calls.  It's a little concerning that so few people have commented on this thread being that it has been open since 2008, and that nobody is actively working on it, and that there is only one 'interested organization' listed in the Wish-list on the Enterprise Working Group page.  A lack of ADMX files and now the inability to easily manage local certificates (in my case to inspect HTTPS traffic) is probably going to cause us to not user Firefox as an enterprise browser, and instead use native browsers (IE/Safari) and Chrome since there are resources for doing enterprise deployments.  Really not a FF basher - I use it as my preferred browser, but, in my opinion, you are not succeeding in the enterprise.
The EWG has a mailing list which, I believe, is fairly active. That's the place to ask questions.

Gerv
I can agree with Jesse in that as a sysadmin cert updates and policy updates are incredibly cumbersome. If we release a new cert internally, we shouldn't have to repackage the browser to deploy said cert, or if we need to lock down a setting, we shouldn't have to release a new package for that. It's really cumbersome and immature practise from an enterprise perspective, and much more prone to error and failure. Internally we are looking at removing FF due to the management overheads it causes especially when these issues don't exist in IE or Chrome. If FF wants to break through the 25% - 30% usage barrier it needs to do a much better job at supporting fundamental enterprise practises.
I strongly agree with Jimi. If Firefox wants a place in the enterprise it needs to abandon its "NIH" stance on certificates. Administrators do not want software arbitrarily deciding for itself what certificates are trusted. Can you imagine if every application did that? What a horrible mess it would be.
This is not an NIH attitude. As far as we can see, Microsoft does not provide the necessary APIs to allow us to identify administrator-added root certificates so we can accept only them. And accepting all root certs in the Windows store without distinction would be effectively delegating our root program management on Windows to Microsoft, which we do not wish to do. Mozilla running an open and transparently-managed root program is a good thing for the Internet as a whole.

Gerv
Gerv, you are saying "Microsoft this" and "Microsoft that", but it's not clear to me that this is a Microsoft-only issue. I thought the same thing is relevant to users of OS X, or Linux, or ... is it not? Or does FF provide an option to depend on the OS trust store for OS X, Linux, ...?

I thought we were discussing an OS-vendor-neutral question: can FF please provide an option for trusting the OS (whatever OS that is) to manage the trusted certs? There are certain things for which we trust the OS to do whatever it needs to do, and for a lot of enterprises / users, managing trusted certificates is one of those things. Just like I don't want FF to manage my list of available printers, or ... just for the sake of one application.

I fail to see what is so Microsoft-specific about all this. And I fail to see the value of this Mozilla position (its root program) if people can simply pick another browser if they need better integration with the OS. It's really hurting your market position as a browser.
(In reply to Johan Corveleyn from comment #23)
> Gerv, you are saying "Microsoft this" and "Microsoft that", but it's not
> clear to me that this is a Microsoft-only issue. 

The title of this bug says "Windows". Given that the engineering work would be different in each case (because it's platform integration), I would expect different bugs for Mac OS X or Linux. I know Red Hat were once working on making Firefox use the OS store on RHEL; I don't know the status of that work.

We don't have a principled position against accepting admin-defined certs, or against accepting admin-defined certs which are provisioned using OS APIs and stores. However, we do not want to trust a root certificate on an entire platform by default just because the OS vendor trusts it. Even providing the option of switching to the OS store from our store means that some public sites would work in some Firefox installs and not others, which is not good for web compatibility. A mechanism to merge in admin-defined certs from the OS would have far fewer problems but, as I said, we haven't found a supported way to do that on Windows.

Gerv
Does the high ground really buy Mozilla anything here?

1. The user already has the cert installed in their OS, so they trust it (in theory).

2. Any malware that wanted to put a bad certificate into Firefox could simply use the NSS APIs (certutil).

What exactly is this accomplishing?
mkaply: I'm not sure which of the two you are proposing, but several comments in this bug explain why "trust everything in the OS store" is not a good idea, and "additionally trust only the things the user has explicitly added to the OS store" is not technically feasible (on Windows).

Gerv
Is it possible to have FF read the windows cert store, but have an option to explicitly trust certs or CA's specifically listed - ie something like "Trust-Windows-Store-Certs"="CN=Your CA"?

FF would then import/trust that cert from the Win store automatically and check the cert against the one in the Windows store.
(In reply to Jimi_X from comment #27)
> Is it possible to have FF read the windows cert store, but have an option to
> explicitly trust certs or CA's specifically listed - ie something like
> "Trust-Windows-Store-Certs"="CN=Your CA"?

No, for two reasons. Firstly, the Windows cert store is dynamic - it downloads roots on demand. So if you ask whether a root is present, the true answer may well be "well, it wasn't before, but it is now".

Secondly, as has been said several times, it's not possible to determine which certs in the Windows root store were added by a user and which were added by Microsoft.

Gerv
(In reply to Gervase Markham [:gerv] from comment #28)
<snip>
> No, for two reasons.

Hi Gerv.  I agree that the local Windows cert store and associated Microsoft CryptoAPI functions don't provide the necessary functionality.  But there is another way...

The Automatic Root Update feature in Windows XP (and newer Windowses) regularly downloads the latest list of roots in the Microsoft Root Certificate Program from here:
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

authrootstl.cab contains various metadata about each root, including certificate thumbprints, trust purposes enabled, friendly names, EV OIDs.  Each root certificate can be downloaded from:
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/<SHA1Thumbprint>.crt

Each Firefox installation could download and parse these files in order to establish whether or not a particular root is in the MS Root Program.  Or, Mozilla HQ could regularly download and process these files and embed the latest list in each new version of Firefox.

(Note: I personally don't have an opinion on whether or not Mozilla/Firefox should do this.  I just wanted to point out that it is possible to implement).
Rob: that might be the beginnings of a solution, although it would be significant engineering work. We'd need to be very careful about comparing that list with the local configuration and making appropriate updates. Also, we may need MS's agreement to send 300+ million extra clients to their endpoint.

Gerv
I just found this projefct.

https://www.openhub.net/p/kcacred

Does this do what everyone is asking for?
Sadly, the module doesn't install and all the instructions are for Firefox 2...
As a side note, not recognizing Windows trusted root certificates made Firefox immune to spoofing by Superish's fake CA in the recent Lenovo/Superfish controversy [1].

[1] http://www.forbes.com/sites/thomasbrewster/2015/02/19/superfish-need-to-know/
AIUI, not so, as the Superfish installer also updates the Firefox root store. (Under what circumstances it does this are unknown, given that Firefox is not AFAIAA preloaded onto those PCs.)

https://mobile.twitter.com/ETFovac/status/568425380513771520

Gerv
I need to throw my hat into the ring here. I work for a UTM company that does content filtering and HTTPS inspection. Our product, which is in thousands of schools ( we're not the biggest fish in the pond mind you ) requires a self-signed CA to actually decrypt SSL traffic to allow for actual content analysis. If Firefox were to allow some type of option here to trust the Windows cert store instead of using it's own, that would go a long way towards enterprise feasibility. As it sits, I cannot recommend Firefox to our customers without a significant investment in time and effort on their part. And when you start adding in multiple user scenarios that don't have assigned seating, it gets real ugly real fast.
While I can appreciate the desire to have integration with the OS certificate store, to claim that the alternative is "a significant investment in time and effort," "incredibly cumbersome," or "complicated at best" is a bit of a stretch.

We recently rolled out a company-signed root CA, and all it took for Firefox and OS X users was a link on our intranet to the certificate file. Click the link, Firefox says "You are being asked to trust a new certificate" and you check the box that lets it identify websites. Done. Obviously this requires you trust your users to be able to click a link, but if the alternative is SSL warnings all over the place, it shouldn't be too much to ask.

That said, if Microsoft ever gives the proper visibility, this would be a nice addition to Firefox.
Hi Michael
I'd disagree with your last comment - if Microsoft ever gives the proper visibility - they do give visability.
There are published API's for this - just did a quick google search on "windows cert api", top link: https://msdn.microsoft.com/en-us/library/windows/desktop/aa386971(v=vs.85).aspx

Second link https://msdn.microsoft.com/en-us/library/windows/desktop/aa382037(v=vs.85).aspx (Example C Program: Certificate Store Operations). This is not secret squirrel stuff, MS has published how to access the cert store and provided examples and api calls.
(In reply to Jimi_X from comment #37)
> Hi Michael
> I'd disagree with your last comment - if Microsoft ever gives the proper
> visibility - they do give visability.
> There are published API's for this - just did a quick google search on
> "windows cert api", top link:
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa386971(v=vs.85).
> aspx

Jimi: please read the rest of this bug. The question is not whether we can do any certificate store operations, but whether we can distinguish between root certs in Microsoft's root program and root certs added by the user. If we can't do that, then supporting the Windows root store effectively means contracting out our root program to Microsoft, and other comments in this bug explain why we think that's not a great plan.

Gerv
Dumb question, but has anyone contacted Microsoft to ask them about this?
Yes.

Gerv
Hello, another Enterprise sysadmin here... same old story again.

I have to say though, this reminds me of a previous challenge with Firefox... the fact it did not have a "Use System Proxy Settings" option like other browsers, and stubbornly insisted on it's own settings, which I presumed was not wanting to dirty itself with Windows, now I'd be curious if Firefox on Mac managed to get around this as I thought Apple forced apps through the system network layer and to use whatever proxy settings were, at least Microsoft just have the IE/System settings there for other programs to use.

Finally though, Firefox included the "Use system proxy settings", one small step... however locking this down to only this setting requires a bit more work... Chrome by comparison just simply went with using IE settings period, no choice, which makes sysadmins lives in the Enterprise much easier.

We get it, Firefox is separate, Firefox open, transparent, it's great, yadda yadda, well if that is truly the case, why on earth can't you adapt for the Enterprise?

"We can't tell which cert has been admin installed from the Microsoft ones", we're from enterprises, we don't want to hear that, they're in there, there are trusted by the business we want them to work in IE/Chrome/Firefox. Despite my best efforts to get everyone on Chrome, some still cling to Firefox, and some awful legacy systems we have yet to get rid of only work in Firefox. Soon Firefox won't work for those users, we're deploying a new web proxy and it does SSL inspection, unfortunately this means HTTPS sites give an invalid certificate warning without the RootCA for the proxy, which we've deployed, works fine in IE and Chrome of course, but not Firefox.

Seriously, a bit of work on Group Policy support, and options for "Use OS Certificate Store", obviously they can be off by default and Home users wouldn't be affected, but in the enterprise we can push out a Group Policy, lock down Firefox to our requirements and use a single Cert store, everyone wins.

If you really must protect the integrity of YOUR SSL program, fine, add a way for us to deploy RootCAs to Firefox clients in the Enterprise, leveraging Group Policy, still annoying having to enter one RootCA cert into both the Windows Store and the Firefox store, but I'm sure it's a compromise most sysadmins will make if you won't budge on trusting the Microsoft OS Cert store, even as a user/enterprise option that must be enabled specifically and default is off.

Either way, 7 years later now, please make some ground on this, considering the rate at which you fire out new versions it's mad this is still the case.

I like to think I'm pretty level headed when it comes to being a sysadmin, don't mind if you use IE, Chrome, or Firefox as your browser, just as long as it's locked to our company web proxy, we managed the security (trusted sites, certificates), so I know that every PC in the enterprise has the exact same settings and just works, our users vary from almost completely computer illiterate to enough knowledge to be dangerous, one or two with maybe enough sense to know what to do and what not to do in a corporate enterprise environment.

I just want it to be centrally configured, working with the users not to have to worry, and no calls to the Service Desk about it. My biggest obstacle in the way of easy sysadmin life? Software Vendors like yourself, not being enterprise friendly, messing up msi installers (incorrect version info, not updating the previous installed version), and such headaches.

Spare a thought for the sysadmin with thousands of users he must support, it's not all about the home user and their isolated, protected from the scourge of the evil corporations of the world Firefox "safespace".
Andrew,

I had pretty much stopped following this thread, but am certainly glad I read your post.  It really made me smile.  I post the following in good-natured jest out of frustration over this issue.  Most of us like firefox because even though Google & chrome are easier - there's something I just don't wholeheartedly trust about those guys, and let's face it IE and now Edge are non-competitors!

So, it has been a year since I put anything on here, but being that it was originally posted 7 years ago, I figured I'd jump back in to celebrate such a remarkable filibuster from Mozilla, and to congratulate Gerv for really digging in his heels on this.  I'm going to try and stay away from the technical speak as much as I can because it seems that they are standing on principle.

Let me start by saying that since this case was opened I have been deployed to Iraq, twice. Retired from the military.  Moved to a new city, and started over in IT.  I worked my way up to sysadmin and am now work solely in security.  So, I've gotten a couple of things accomplished over the last few years.  In the meantime, through 30 some-odd new versions, Mozilla has yet to remedy this issue.

To the Mozilla folks I would say - good for you for holding your ground!  It takes courage and real commitment, but here's what it got you in our organization:  ZERO deployments of your application... ZERO!  It isn't for lack of trying - we've googled (or Duck Ducked) our little hearts out.  We even found a pretty neat tool for deploying FF to all our workstations and keeping them updated, and it works, but...  I still can't seem to poke those pesky certificates into your store without more effort than I want to expend or have time to.  True enough, as one comment suggested, I could post those certificates internally and have users install them individually/on demand, but that generates calls to the service desk - even if I publish instructions.  I mean, everyone on here supports users, and even the simplest of tasks turns out to be rocket surgery for them, and the last thing my help desk folks want is for me to create a scenario that generates more calls where they have to refer them to the instrcutions that have already been posted.

At this point, I don't want you to compromise your Certificate Store and merge it with the Evil Microsoft one.  I mean, who can trust them!?  It isn't like they've been around for very long or are very widely adopted.  I don't think they have any security element within their organization, and they NEVER provide patches for their corrupt software.  So really, why should Mozilla make compromises with them!?  

Look - all any of us want is to be able to easily poke a certificate into your browser from a central management point.  An added bonus would be the ability to restrict and manage add-ons.  If only there was a modern browser that would let me do that...  hmmm... (https://www.google.com/intl/en_Us/chrome/business/browser/)

To the sysadmins out there who may just be catching up to this issue or maybe long time followers, I would say that there are no solutions to be found here - terribly sorry about that.  Save yourself some time:  Do some searching for Chrome for Work/Chrome in the enterprise.  Take your time, spend a few hours reading and testing to get it tweaked for your environment, deploy it, use it and be happy.  We have - It has the certificates I want it to have, it has the extensions we've decided to apply, and it stays updated regularly.

To Andrew:  Thanks for your post - we ran up against this challenge for the same reason.  HTTPS Inspection at the perimeter - it is necessary for security these days.  I'd also like to echo your comments regarding software vendors.  The biggest security issue we have is that vendors don't know anything about their application - how it communicates, the background processes it kicks off or the services it runs or is dependant on.  Poorly written applications and applications developed without security in mind are the bane of our existence, and hardware manufacturers aren't exempt either - why do I have to exempt all my apple devices for detection for weak security ciphers when connecting to the apple store (another story for another forum, but you get the idea).

Lastly, and with all seriousness - Come on Mozilla - REALLY!?  It's been 7 years, you can't find a place to meet in the middle on this one? 

Hope everyone has a great day, and thanks for stopping by (but stay classy).
Please support a toggle to trust OS certificate store..

Simple as that. Chrome trusts the OS certificate store automatically. cURL does. That's how most applications work.

I should be able to push a Group Policy to all domain members to trust a specific CA and not have to worry about the browser that they are using.
I agree with the previous few comments. We currently have 4000 installs of Firefox with no real way of centrally managing them that's supported out of the box.
We are ready to block Firefox and pull the pin completely and transition those users over to IE and Chrome. Some of our current issues:
- No way to centrally push certificates out. We can push out certs seamlessly for Chrome and IE using Active Directory via the widows cert store. An end user shouldn't have to click on anything, it should just work for them out the box. This is our number 1 issue and would save FF from the scrap heap.
- Poor support for BlueCoat proxy and other enterprise level proxies. User are always getting annoyed with moz-proxy errors if a website contains a third party link to a site with SSL. This bug has existed since 2004 with no resolution and minimal input from Mozilla. This is very close behind the previous issue and is quite disappointing that this bug has existed for over 11 years with minimal action.
- No GPO support. This makes centrally managing Firefox a huge issue. If we want to change a setting within Firefox (such as disable TLS, update the intranet address, proxy update for various business units) we have to roll a new package. I know there are third party solutions for this, but this adds another layer of complexity and potential vulnerabilities and should be something we can configure out of the box. We currently do this with both IE and Chrome.
- Firefox enterprise is supplied as an EXE and not a MSI. This means we have to repackage FireFox for deployment. Again this isn't something we do with Chrome or IE.

All of these issues are well documented right across the net. Things like certs, MSI and GPO all have whitepapers and open API's to access and hook into (for at least 15 years...). FireFox is very quickly becoming irrelevant and from an enterprise level is becoming the big bad browser, something which saddens me having been an advocate for FF since the Mozilla branded days.
+1 on the request for Firefox to trust certificates from the Windows Cert Store.

As I understand, Gerv's position is that Firefox should be able to inherit certificates from the Windows store that were added by the user/admin, but never inherit certificates from Microsoft Trusted Root Certificate Program.  The problem is that the "Trusted Root Certification Authorities" store in Windows contains an indistinguishable mixture of certificates from Microsoft's root program and from the admin/user of the machine.


But the Windows certificate store is comprised of an entire collection of stores.  It stands to reason that Windows should only import certificates from the MS root program to a specific set of stores - if this is correct, what about at least allowing Firefox to inherit certificates from another store that doesn't automatically get those?  Or even have Firefox add it's own custom store during install?  This way, Admins could still use GPO to deploy certs and Firefox would be able to utilize them without picking up certs from MS root program?
(In reply to Dan from comment #45)
> But the Windows certificate store is comprised of an entire collection of
> stores.  It stands to reason that Windows should only import certificates
> from the MS root program to a specific set of stores - if this is correct,
> what about at least allowing Firefox to inherit certificates from another
> store that doesn't automatically get those?  Or even have Firefox add it's
> own custom store during install?  This way, Admins could still use GPO to
> deploy certs and Firefox would be able to utilize them without picking up
> certs from MS root program?

That sounds like a good idea. We're looking into this.
I have to add to this thread as I concur that an OPTION to trust the OS root store is needed. As an enterprise, you choose to trust the OS store on your platform and have full control over how you control that store. If you trust the OS vendor, then you give them access to update your root store. If you don't, you block their access and only allow roots you specifically add. Either way, you are in control. As an enterprise, you want and demand this control.

What you don't want is to DUPLICATE this effort at the whim of another application. Luckily, only FF seems to have their head in the sand on this. Even if you look into the 4 physical stores inside the Windows certificate store, you should still give sysadmins the option to include some or all of those stores. Any other option (including the current functionality) implies you understand the enterprise better than the sysadmins responsible for managing it.

Guess what, you don't.
I'll add my two cents.  As a windows system administrator, there MUST be an option to use and trust the Windows certificate store.  Shame on Mozilla for pushing your philosophy down the throats of users.  What are you Apple?

I have a very simple fix for this problem, blacklist the firefox.exe executable and any associated websites, or download links for the product followed by a scripted uninstall on all workstations.  Period.  It's easy to convince users they shouldn't be using Firefox when their web browser blocks all their websites just because we, as an organization, want to monitor and filter web traffic. 

You don't have the type of product or market share to dictate to people what they can and cannot do with their browser.  Alternatives abound. Have a nice day.
How much money do you want in order to make the full recognition of Windows trusted root certificates as an option?
Developers email me if you are interested.
I would also love the toggle to trust the Microsoft stores. We write secure applications and the fact that you can't do this programatically is absolutely stupid.

Whomever is the decision maker at Mozilla on this has decided on the wrong side of history. This is a huge oversight and has huge implications as companies/IA folks start to look for more secure browsers. 

What a joke.
(In reply to Gervase Markham [:gerv] from comment #24)
> I know Red Hat were once 
> working on making Firefox use the OS store on RHEL; I don't know the status
> of that work.

We make extensive use of this on our Linux desktops and it works really well. Unfortunately, the Windows Sysadmins aren't anywhere near as lucky and work round it by simple blatting everyone's certificate store every time we need to update certificates.
They're not going to change this.  They are too proud to take care of it.  I quit using Firefox years ago because it was as unstable as Internet Explorer in my day to day use and I switched to Chrome.  Faster, infinitely more stable, and now, far more popular.  Chrome doesn't have this problem. Sometimes I have to use Internet Explorer for a particular website, however I NEVER have to use Firefox, for anything. Mozilla, nobody gives two shakes about your certificate store. Have a nice day.
(In reply to ken from comment #53)
> They're not going to change this.  They are too proud to take care of it.  I
> quit using Firefox years ago because it was as unstable as Internet Explorer
> in my day to day use and I switched to Chrome.  Faster, infinitely more
> stable, and now, far more popular.  Chrome doesn't have this problem.
> Sometimes I have to use Internet Explorer for a particular website, however
> I NEVER have to use Firefox, for anything. Mozilla, nobody gives two shakes
> about your certificate store. Have a nice day.

Yeah, seriously doubt that they are going to do anything. It's hilarious to see the developers defending this. It's pretty silly to have your potential customers and champions in the market place asking you for a feature and to repeatedly deny them, especially with some of the proposed solutions. It is sad that I would rather install and manage Internet Explorer over Firefox. As a former web dev, I never really envisioned uttering those words. No enterprise Firefox, not now or ever. BYE FELICIA!
(In reply to Anthony Patrizi from comment #54)
> Yeah, seriously doubt that they are going to do anything.

Bug 1265113. Please don't spam that bug with advocacy like you have this one.

Gerv
over the next month or so we will be removing FF from all our machines, and moving those users over to Chrome. It's not just this bug, but a couple of others (such as mozproxy errors when operating behind a corporate proxy) that make Firefox an insecure browser for us compared to IE and Chrome. These have been long standing issues that we can no longer put resources into working around (resources translates to admins who can be doing better and more productive work) and frustrating our user base.
If anything changes on these fronts we may review the decision and make it available again to our users. Until these issues are resolved we won't be using Firefox.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: