1265113 - Windows platform support for trusting enterprise roots

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Dana Keeler (she/her) [:keeler]]

After some investigation, we've figured out how to detect and import root certificates that have been added to a user's environment on Windows. If we build functionality to allow this, many people will find Firefox much easier to use in enterprise environments.

Comment 1

[Dana Keeler (she/her) [:keeler]]

Attachment: MozReview Request: bug 1265113 - implement platform support for enterprise roots

Review commit: https://reviewboard.mozilla.org/r/46881/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/46881/

Comment 2

[Dana Keeler (she/her) [:keeler]]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/46881/diff/1-2/

Comment 3

[Masatoshi Kimura [:emk]]

Is this implementing bug 432802 comment #45?

Comment 4

[Dana Keeler (she/her) [:keeler]]

Essentially, yes. We figured out how to differentiate certificates that are part of Microsoft's root program and certificates that were added by the user/administrator.

Comment 5

[Dana Keeler (she/her) [:keeler]]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/46881/diff/2-3/

Comment 6

[Molly Howell (she/her) (mostly inactive)]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

https://reviewboard.mozilla.org/r/46881/#review44583

::: security/manager/ssl/nsNSSComponent.cpp:1026
(Diff revision 3)
> +  // The certificate store being opened should consist only of certificates
> +  // added by a user or administrator and not any certificates that are part
> +  // of Microsoft's root store program.
> +  ScopedCertStore enterpriseRootStore(CertOpenStore(
> +    CERT_STORE_PROV_SYSTEM_REGISTRY_W, X509_ASN_ENCODING, NULL, flags,
> +    WindowsDefaultRootStoreName));

This seems to draw in a few Microsoft certificates in addition to the ones that we're after. I don't think this can be helped, because all those things really are stored in the same registry key; I think this is the best that is possible to do. But we should be clear about the fact that false positives are expected, to keep from giving users the wrong impression about what we're doing.

Comment 7

[Richard Barnes [:rbarnes]]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

https://reviewboard.mozilla.org/r/46881/#review44967

::: security/manager/ssl/nsNSSComponent.cpp:1017
(Diff revision 3)
> +
> +static void
> +MaybeImportEnterpriseRoots()
> +{
> +#ifdef XP_WIN
> +  UnloadEnterpriseRoots();

Can't we avoid this by just storing the roots as session, not permanent?

Comment 8

[:Cykesiopka]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

https://reviewboard.mozilla.org/r/46881/#review45345

The changes here mostly look good, but I think it would be good for me to take another look.

It would also be nice if some scenarios could be given that this feature is meant to satisfy.
I can kind of guess, but having more concrete examples to consider makes evaluation of the feature easier since I don't have good knowledge of enterprise setups.

::: security/manager/ssl/nsNSSComponent.cpp:666
(Diff revision 3)
> +// since this code runs during that initialization), we can't use it. Instead,
> +// we can use NSS APIs directly (as long as we're called late enough in
> +// nsNSSComponent initialization such that those APIs are safe to use).
> +
> +// Helper function that takes a certificate, adds it to the permanent
> +// certificatae database (if it isn't already permanent), and trusts it to issue

Nit: Typo: certificatae.

::: security/manager/ssl/nsNSSComponent.cpp:670
(Diff revision 3)
> +// Helper function that takes a certificate, adds it to the permanent
> +// certificatae database (if it isn't already permanent), and trusts it to issue
> +// TLS web server certificates. Also stores a unique DB key in the given
> +// preference for easy access later.
>  static nsresult
> -MaybeImportFamilySafetyRoot(PCCERT_CONTEXT certificate,
> +AddAndTrustCertificate(CERTCertificate* certificate,

Nit: It looks like |CERTCertificate* certificate| can be changed to |const UniqueCERTCertificate& certificate|, which IMO better clarifies the ownership of |certificate|.

::: security/manager/ssl/nsNSSComponent.cpp:684
(Diff revision 3)
> -  // It would be convenient to just use nsIX509CertDB here. However, since
> -  // nsIX509CertDB depends on nsNSSComponent initialization, we can't use it.
> -  // Instead, we can use NSS APIs directly (as long as we're called late enough
> -  // in nsNSSComponent initialization such that those APIs are safe to use).
> +  CERTCertTrust trust = {
> +    CERTDB_TRUSTED_CA | CERTDB_VALID_CA | CERTDB_USER,
> +    0,
> +    0
> +  };
> +  UniquePORTString nickname(CERT_MakeCANickname(certificate));

Does it matter if |nickname| ends up being null? AFAICT no, but I just wanted to confirm.

::: security/manager/ssl/nsNSSComponent.cpp:694
(Diff revision 3)
> +  // persistent database. If so, we have to change it from a temporary to a
> +  // permanent certificate (and set its trust settings at the same time). It may
> +  // already have been permanently imported, however. In that case, we just have
> +  // to make sure it has the right trust settings.
> +  if (!certificate->isperm) {
> +    SECStatus srv = __CERT_AddTempCertToPerm(certificate, nickname.get(), &trust);

Nit: Can we do s/__CERT/CERT/ now that Bug 1263221 has landed?

::: security/manager/ssl/nsNSSComponent.cpp:714
(Diff revision 3)
> +  nsresult rv = nsNSSCertificate::GetDbKey(certificate, dbKey);
> +  if (NS_FAILED(rv)) {
> +    MOZ_LOG(gPIPNSSLog, LogLevel::Debug, ("GetDbKey failed"));
> +    return rv;
> +  }
> +  Preferences::SetCString(prefToStoreDBKeyIn, dbKey);

Shouldn't the result returned by SetCString() be checked?

::: security/manager/ssl/nsNSSComponent.cpp:917
(Diff revision 3)
>  #endif // XP_WIN
>  }
>  
> +#ifdef XP_WIN
> +// Helper function to determine if the OS considers the given certificate to be
> +// trusted to for the TLS server auth usage. This is to be used in the context

Nit: s/trusted to for/trusted for/.

::: security/manager/ssl/nsNSSComponent.cpp:920
(Diff revision 3)
> +// trusted to issue TLS server auth certificates. If it turns out that the
> +// certificate lacks an appropriate basic constraints extension or is otherwise
> +// unsuitable to issue certificates, no valid chains will be found that include
> +// the given certificate.

Nit: Hmm, this last sentence to me sounds more like it's describing implementation details, so maybe it would be less confusing to move it to just before the CertGetCertificateChain() call.

::: security/manager/ssl/nsNSSComponent.cpp:935
(Diff revision 3)
> +  LPSTR identifiers[] = {
> +    "1.3.6.1.5.5.7.3.1", // id-kp-serverAuth
> +    nullptr
> +  };

I could be missing something really obvious, but why nullptr here?

::: security/manager/ssl/nsNSSComponent.cpp:986
(Diff revision 3)
> +    importCount++;
> +    nsAdoptingCString dbKey = Preferences::GetCString(prefName.get());
> +    if (!dbKey || dbKey.IsEmpty()) {
> +      break;
> +    }
> +    Preferences::ClearUser(prefName.get());

I guess we don't care even if this fails?
If so, we should probably do |Unused << Preferences[...]| to make this clear.

::: security/manager/ssl/nsNSSComponent.cpp:1029
(Diff revision 3)
> +  ScopedCertStore enterpriseRootStore(CertOpenStore(
> +    CERT_STORE_PROV_SYSTEM_REGISTRY_W, X509_ASN_ENCODING, NULL, flags,

If I'm reading https://msdn.microsoft.com/en-us/library/windows/desktop/aa376559(v=vs.85).aspx right, the X509_ASN_ENCODING here should be 0 instead, since we pass CERT_STORE_PROV_SYSTEM_REGISTRY_W as the provider type.

::: security/manager/ssl/nsNSSComponent.cpp:1030
(Diff revision 3)
> +                CERT_STORE_READONLY_FLAG;
> +  // The certificate store being opened should consist only of certificates
> +  // added by a user or administrator and not any certificates that are part
> +  // of Microsoft's root store program.
> +  ScopedCertStore enterpriseRootStore(CertOpenStore(
> +    CERT_STORE_PROV_SYSTEM_REGISTRY_W, X509_ASN_ENCODING, NULL, flags,

Nit: s/NULL/nullptr/.

::: security/manager/ssl/nsNSSComponent.cpp:1031
(Diff revision 3)
> +  // The certificate store being opened should consist only of certificates
> +  // added by a user or administrator and not any certificates that are part
> +  // of Microsoft's root store program.
> +  ScopedCertStore enterpriseRootStore(CertOpenStore(
> +    CERT_STORE_PROV_SYSTEM_REGISTRY_W, X509_ASN_ENCODING, NULL, flags,
> +    WindowsDefaultRootStoreName));

Optional: Add a |k| prefix so it's clearer this is a constant?

::: security/manager/ssl/nsNSSComponent.cpp:1038
(Diff revision 3)
> +  while ((certificate = CertFindCertificateInStore(enterpriseRootStore.get(),
> +                                                   X509_ASN_ENCODING, 0,
> +                                                   CERT_FIND_ANY, nullptr,
> +                                                   certificate))) {

Would a check that only up to x roots are imported be a good idea?
I slightly worry that importing too many roots would make startup time and shutdown time too long, but maybe my worries are unfounded.

::: security/manager/ssl/tests/unit/test_enterprise_roots.js:8
(Diff revision 3)
> +// Tests enterprise root certificate support. When configured to do so, the
> +// platform will attempt to find and import enterprise root certificates. This

Is there a guarantee that certain roots will always be found on any Windows machine this test is run on?

::: security/manager/ssl/tests/unit/test_enterprise_roots.js:53
(Diff revision 3)
> +    numRootsImported++;
> +    if (!savedDBKey) {
> +      savedDBKey = dbKey;
> +    }
> +  }
> +  ok(numRootsImported > 0, "should have imported at least one root");

Nit: |greater(numRootsImported, 0, "should have imported at least one root")| probably works better here, since greater() prints out more relevant log messages.

Comment 9

[Dana Keeler (she/her) [:keeler]]

https://reviewboard.mozilla.org/r/46881/#review44583

> This seems to draw in a few Microsoft certificates in addition to the ones that we're after. I don't think this can be helped, because all those things really are stored in the same registry key; I think this is the best that is possible to do. But we should be clear about the fact that false positives are expected, to keep from giving users the wrong impression about what we're doing.

Agreed. The UX has yet to be designed, but we'll make sure it's clear what the guarantees are.

Comment 10

[Dana Keeler (she/her) [:keeler]]

https://reviewboard.mozilla.org/r/46881/#review44967

> Can't we avoid this by just storing the roots as session, not permanent?

Yes. It does mean that we have to hold a reference to each certificate we import until shutdown, but since these are all refcounted anyway (and it's expected that these roots will actually be used if they're being imported), it shouldn't be undue overhead (storing the db keys in preferences was a bit wasteful and an abuse of the api anyway).

Comment 11

[Dana Keeler (she/her) [:keeler]]

https://reviewboard.mozilla.org/r/46881/#review45345

Basically, it's for enterprise environments where it's common to push out trusted roots to employees' systems. My understanding is administrators know how to make this work for browsers that by default trust the operating system's root trust store (e.g. Edge and Chrome). The aim here is to make Firefox "just work" the same way (if the pref is enabled).

> Nit: It looks like |CERTCertificate* certificate| can be changed to |const UniqueCERTCertificate& certificate|, which IMO better clarifies the ownership of |certificate|.

Due to a restructuring, this went away anyway.

> Does it matter if |nickname| ends up being null? AFAICT no, but I just wanted to confirm.

This turned out to be unnecessary due to other changes.

> Nit: Can we do s/__CERT/CERT/ now that Bug 1263221 has landed?

Yes, but this turned out to be unnecessary as well.

> Shouldn't the result returned by SetCString() be checked?

Yes, but this also went away due to the change in approach.

> Nit: s/trusted to for/trusted for/.

Good catch.

> Nit: Hmm, this last sentence to me sounds more like it's describing implementation details, so maybe it would be less confusing to move it to just before the CertGetCertificateChain() call.

Ah, I guess I wasn't clear - I meant that once imported, mozilla::pkix would reject that certificate during verification, so it wasn't a security concern. I updated the comment.

> I could be missing something really obvious, but why nullptr here?

For some reason I thought the array had to be null-terminated, but that shouldn't be necessary since the data structure it's stored in knows the length of the array.

> I guess we don't care even if this fails?
> If so, we should probably do |Unused << Preferences[...]| to make this clear.

Yes, but again this went away.

> If I'm reading https://msdn.microsoft.com/en-us/library/windows/desktop/aa376559(v=vs.85).aspx right, the X509_ASN_ENCODING here should be 0 instead, since we pass CERT_STORE_PROV_SYSTEM_REGISTRY_W as the provider type.

Good catch.

> Nit: s/NULL/nullptr/.

For some reason the compiler doesn't like nullptr here (I think because the actual type is HCRYPTPROV_LEGACY, which is typedef ULONG_PTR which is typedef unsigned __int3264 which isn't actually a pointer type).

> Optional: Add a |k| prefix so it's clearer this is a constant?

Sounds good.

> Would a check that only up to x roots are imported be a good idea?
> I slightly worry that importing too many roots would make startup time and shutdown time too long, but maybe my worries are unfounded.

My concern with that is if a user does have 1000s of certificates to be imported, having a limit could lead to unexpected behavior (as in, if we don't import and trust everything, we may miss a root they're actually depending on). This does sound like a good candidate for telemetry, though.

> Is there a guarantee that certain roots will always be found on any Windows machine this test is run on?

Well, technically no, but I think there's a Mozilla certificate that gets imported as part of the setup process for the Windows test machines, so for our purposes this should work.

> Nit: |greater(numRootsImported, 0, "should have imported at least one root")| probably works better here, since greater() prints out more relevant log messages.

Thanks for the tip. This got restructured as well, though.

Comment 12

[Dana Keeler (she/her) [:keeler]]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/46881/diff/3-4/

Comment 13

[Andrew]

Fundamentally, Group Policy is used to deploy Certificates to domain joined workstations, there's a few different ways to accomplish this.

Firstly, Active Directory has Containers for Certificates, when creating a Windows Enterprise CA, the Root certificate of the CA is automatically imported into this container, there are sub containers for NTAuthCertificates, AIA Container, Certification Authorities Container, Enrollment Services Container, CDP Container and KRA Container.

Most Administrators may not even be aware of this existence, however it's how Active Directory automatically pushes out certificates to domain workstation clients.

I believe if you look to implement a card reader system for login, then you need to add the CA certificate for said system to the NTAuthCertificates container.

However, I make use of the Certificate Authorities Container to push out CA Root certificates for many of our additional domain forests (Business buys another business, merge, and we set up a trust between Active Directories, or we move to a new Active Directory domain and have trusts back to our old domains with some legacy SQL and file servers yet to move across).

In addition, I find it a good place to load essential certificates, such as that for our new cloud based web proxy (Zscaler). These end up in the domain joined workstation computer's Trusted Root Certificate Authorities Certificates store and are then used by Internet Explorer, Chrome and Opera as they either read from or import settings from the system into their own.

Deployment of this is through the background Group Policy refresh and can be forced with "gpupdate /force" at the command line with admin rights.



Alternatively, and perhaps more commonly, an actual Group Policy object can be created or an existing one used, though probably best practice to have a dedicated GP object for this, to push out certificates to domain joined workstations, in this method you have greater control on setting exactly what machines receive the certificates if you don't wish for all of the domain joined computers to receive it/them.


I imagine you'll be looking at many web proxy providers, like Zscaler being used by IT Administrators, or possibly internal web certificates, perhaps pushing out SSL certs for embedded management consoles using self-signed certificates, say vmware vsphere or similar, and avoiding users have to individually make exceptions for each one.

Comment 14

[:Cykesiopka]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

https://reviewboard.mozilla.org/r/46881/#review49053

Looks good.

> bug 1265113 - implement platform support for enterprise roots
It would probably be a good idea to mention that this patch replaces the Family Safety pref approach with an in memory approach as well.

::: security/manager/ssl/nsNSSCertificateDB.cpp:1489
(Diff revision 4)
>    nssCertList.forget(_retval);
>    return NS_OK;
>  }
>  
> +NS_IMETHODIMP
> +nsNSSCertificateDB::GetEnterpriseRoots(nsIX509CertList** _retval)

Nit: Maybe just |retval|. I don't really see the value of the underscore.

::: security/manager/ssl/nsNSSComponent.cpp:665
(Diff revision 4)
> +static CERTCertificate*
> +PCCERT_CONTEXTToCERTCertificate(PCCERT_CONTEXT pccert)

Let's return a UniqueCERTCertificate instead.

::: security/manager/ssl/nsNSSComponent.cpp:721
(Diff revision 4)
>        MOZ_LOG(gPIPNSSLog, LogLevel::Debug,
> -              ("couldn't permanently add certificate"));
> +              ("couldn't trust certificate for TLS server auth"));
>        return NS_ERROR_FAILURE;
>      }
> -    nsAutoCString dbKey;
> -    nsresult rv = nsNSSCertificate::GetDbKey(nssCertificate, dbKey);
> +    MOZ_ASSERT(!mFamilySafetyRoot);
> +    mFamilySafetyRoot = mozilla::Move(nssCertificate);

Nit: Looks like the |mozilla::| qualifier isn't necessary.

::: security/manager/ssl/nsNSSComponent.cpp:806
(Diff revision 4)
> +        != SECSuccess) {
>      MOZ_LOG(gPIPNSSLog, LogLevel::Debug,
> -            ("couldn't delete previously-imported Family Safety root"));
> +            ("couldn't untrust certificate for TLS server auth"));
> -    return;
>    }
> -  MOZ_LOG(gPIPNSSLog, LogLevel::Debug,
> +  mFamilySafetyRoot.reset(nullptr);

Nit: This can just be |mFamilySafetyRoot = nullptr|, which looks nicer.
Same everywhere else this pattern occurs.

::: security/manager/ssl/nsNSSComponent.cpp:889
(Diff revision 4)
> +  CERT_ENHKEY_USAGE enhkeyUsage;
> +  memset(&enhkeyUsage, 0, sizeof(CERT_ENHKEY_USAGE));
> +  LPSTR identifiers[] = {
> +    "1.3.6.1.5.5.7.3.1", // id-kp-serverAuth
> +  };
> +  enhkeyUsage.cUsageIdentifier = MOZ_ARRAY_LENGTH(identifiers);

ArrayLength() from "mozilla/ArrayUtils.h" is nicer and seems to work.

::: security/manager/ssl/nsNSSComponent.cpp:989
(Diff revision 4)
> +  enterpriseRootsCertList.forget(enterpriseRoots);
> +  return NS_OK;
> +}
> +#endif // XP_WIN
> +
> +const char* kEnterpriseRootModePref = "security.enterprise_roots.enabled";

static const char*

::: security/manager/ssl/nsNSSComponent.cpp:1008
(Diff revision 4)
> +  // The certificate store being opened should consist only of certificates
> +  // added by a user or administrator and not any certificates that are part
> +  // of Microsoft's root store program.

FWIW, on my machine, I see roots like "Microsoft Root Certificate Authority" being imported.
I assume this was what mhowell was talking about.
Apparently these certs are necessary for Windows to work, so I assume they don't really count as "part of Microsoft's root store program".

::: security/manager/ssl/nsNSSComponent.cpp:1054
(Diff revision 4)
> +    if (nsCRT::strcmp(subjectName.get(), kMicrosoftFamilySafetyCN) == 0) {
> +      MOZ_LOG(gPIPNSSLog, LogLevel::Debug, ("skipping Family Safety Root"));
> +      continue;
> +    }
> +    if (CERT_AddCertToListTail(mEnterpriseRoots.get(), nssCertificate.get())
> +        != SECSuccess) {

Nit: Indent this line two spaces more.

::: security/manager/ssl/nsNSSComponent.cpp:1066
(Diff revision 4)
> +              ("couldn't trust certificate for TLS server auth"));
> +    }
> +    MOZ_LOG(gPIPNSSLog, LogLevel::Debug, ("Imported '%s'", subjectName.get()));
> +    numImported++;
> +    // now owned by mEnterpriseRoots
> +    mozilla::Unused << nssCertificate.release();

Nit: Looks like the |mozilla::| qualifier isn't necessary.

::: security/manager/ssl/tests/unit/test_enterprise_roots.js:16
(Diff revision 4)
> +
> +do_get_profile(); // must be called before getting nsIX509CertDB
> +
> +function check_no_enterprise_roots_imported(certDB, dbKey = undefined) {
> +  let enterpriseRoots = certDB.getEnterpriseRoots();
> +  ok(!enterpriseRoots, "should not have imported any enterprise roots");

Nit: Maybe |equal(enterpriseRoots, null, ...)|?
I prefer reserving ok() for boolean types.
Similarly for everywhere else this pattern appears.

Comment 15

[:Cykesiopka]

(In reply to Andrew from comment #13)
Thanks! Useful knowledge.

Comment 16

[Richard Barnes [:rbarnes]]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

https://reviewboard.mozilla.org/r/46881/#review51502

Modulo one minor issue, lgtm.

::: security/manager/ssl/nsNSSCertificateDB.cpp:1511
(Diff revision 4)
> +    return NS_ERROR_FAILURE;
> +  }
> +  return psm->GetEnterpriseRoots(_retval);
> +#else
> +  *_retval = nullptr;
> +  return NS_OK;

Would it be better to return an error value (e.g., NS_ERROR_NOT_AVAILABLE) in the non-Windows case?  Concerned about NPE if this returns NS_OK and nullptr.

Comment 17

[Dana Keeler (she/her) [:keeler]]

https://reviewboard.mozilla.org/r/46881/#review49053

> Nit: Maybe just |retval|. I don't really see the value of the underscore.

It was for consistency with nsNSSCertificateDB::GetCerts, but I changed it to enterpriseRoots to be more clear (and consistent with nsNSSComponent::GetEnterpriseRoots).

> Let's return a UniqueCERTCertificate instead.

Sounds good.

> Nit: This can just be |mFamilySafetyRoot = nullptr|, which looks nicer.
> Same everywhere else this pattern occurs.

Ok - fixed.

> ArrayLength() from "mozilla/ArrayUtils.h" is nicer and seems to work.

Sounds good.

> FWIW, on my machine, I see roots like "Microsoft Root Certificate Authority" being imported.
> I assume this was what mhowell was talking about.
> Apparently these certs are necessary for Windows to work, so I assume they don't really count as "part of Microsoft's root store program".

Yeah :(

> Nit: Maybe |equal(enterpriseRoots, null, ...)|?
> I prefer reserving ok() for boolean types.
> Similarly for everywhere else this pattern appears.

Sounds good.

Comment 18

[Dana Keeler (she/her) [:keeler]]

https://reviewboard.mozilla.org/r/46881/#review51502

> Would it be better to return an error value (e.g., NS_ERROR_NOT_AVAILABLE) in the non-Windows case?  Concerned about NPE if this returns NS_OK and nullptr.

Good idea.

Comment 19

[Dana Keeler (she/her) [:keeler]]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/46881/diff/4-5/

Comment 20

[Dana Keeler (she/her) [:keeler]]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/46881/diff/5-6/

Comment 21

[Dana Keeler (she/her) [:keeler]]

Comment on attachment 8741978 [details]
MozReview Request: bug 1265113 - implement platform support for enterprise roots

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/46881/diff/6-7/

Comment 22

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d9659c22b3c5

Comment 23

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/d9659c22b3c5

Comment 26

[dhwillem]

Is this ticket also representing a fix on OSX ? I just tested Firefox 49.0a2 on OSX 10.11.6 ( El Capitan ) and the problem still exists there. Should I file a separate ticket to have this fixed on OSX ?

Comment 27

[Gervase Markham [:gerv]]

No; yes.

Gerv

Comment 28

[Charles]

What is the reason an options isn't provided that just allows one to use the Windows Cert Store, like all other Windows software does? Why does FF have to have it's own?

I'm seriously wondering... are there any (real, legitimate) security concerns?

Comment 29

[Gervase Markham [:gerv]]

Actually Charles, all our security concerns are bogus. We are simply doing this to frustrate you and every other Windows enterprise admin out there, because we love making your lives difficult.

...Or, you could perhaps make the effort to read this bug, related bugs and the many discussions which have been had over the years which clearly explain why this is not simple. As befits its low number, bug 432802, marked as a duplicate of this one, has a lot of the information. 

Gerv

Comment 30

[Norman Vadnais]

Gerv,

I think Charles point still exists and has never been truly answered. As I have tried to point out, having a separate store doesn't change the security for anyone. People who really, really scrutinize their stores want the FF store the same as the OS store (since the OS store is fully scrutinized). Those who don't track or don't care about their root certificates want the two stores to match so what works here also works there.

So, in the end, no one really wants their FF certificate store, no matter where it is held or how it is managed, to be different than their OS store. Those of us who have higher ups forcing adoption of FF wish the requestors understood the headaches caused by this single nuisance. Your bug fix is going to make it easier to keep the two stores in sync; I appreciate that. But I still have seen no valid explanation for having a separate store or for why an administrator would ever want that store different. Over time Java dropped its requirement for a separate store (many years ago now); we wish FF would do the same.

Norman

Comment 31

[Gervase Markham [:gerv]]

(In reply to Norman Vadnais from comment #30)
> I think Charles point still exists and has never been truly answered. As I
> have tried to point out, having a separate store doesn't change the security
> for anyone.

Mozilla makes trust decisions for our users, and we are not willing to delegate that to third parties. That's partly because we think we do a better job (running an open and transparent root program, whereas the other root programs are not) and partly because doing so would prevents us driving positive change in the CA industry (through having no leverage), something we have a good record of doing over the past ten years.

Also, the store on both Android and Linux OSes _is_ our store - if our root program doesn't exist, they would also have to copy a third party's decisions, which would be a big loss of autonomy.

These points have all been made before, but I hope this restatement of them will disabuse you of the notion that the point has not been answered. We have no plans to change this policy for the standard install of Firefox or ESR.

Gerv

Comment 32

[Norman Vadnais]

(In reply to Gervase Markham [:gerv] from comment #31)
> These points have all been made before, but I hope this restatement of them
> will disabuse you of the notion that the point has not been answered.

What I haven't seen addressed, and I don't think your comments address, is how the FF store is going to be different than the OS store? I'm not making any statement about having a sound root program, especially when none exists on the platform. But when the platform does provide a root program, I am not seeing anything stating how the two programs will be different, or better stated how the resultant stores will be different.

I and everyone else I have seen provide this sentiment on these pages are identifying the same thing. You are making us go to a lot of effort, and we make mistakes from time to time with that increased effort, just to have two things that end up being the same (when correct and not in error). In fact, to have them different is a source of issues, service desk calls, triage, rework, etc.

In the situation where the OS provides a store every other program utilizes, why must we create an exact duplicate of that store in your store? Or why would I make your store different?

Norman

Comment 33

[Gervase Markham [:gerv]]

(In reply to Norman Vadnais from comment #32)
> What I haven't seen addressed, and I don't think your comments address, is
> how the FF store is going to be different than the OS store? I'm not making
> any statement about having a sound root program, especially when none exists
> on the platform. But when the platform does provide a root program, I am not
> seeing anything stating how the two programs will be different, or better
> stated how the resultant stores will be different.

The Microsoft root store is run by Microsoft using Microsoft's rules and policies. The Apple root store is run by Apple using Apple's rules and policies. The Firefox root store is run by Mozilla using our rules and policies, written down here:
http://www.mozilla.org/projects/security/certs/policy/
and collaboratively developed here:
https://www.mozilla.org/en-GB/about/forums/#dev-security-policy

Different people and different rules inevitably leads to differences in who is included.

> I and everyone else I have seen provide this sentiment on these pages are
> identifying the same thing. You are making us go to a lot of effort, and we
> make mistakes from time to time with that increased effort, just to have two
> things that end up being the same (when correct and not in error). In fact,
> to have them different is a source of issues, service desk calls, triage,
> rework, etc.

Difference is not necessarily bad. Would you prefer that there was one worldwide "trust authority" which said "Here is the list of CAs everyone in the world must trust?". The ability for different platforms to make different decisions on that point is a strength, not a weakness.

Gerv

Comment 34

[Norman Vadnais]

(In reply to Gervase Markham [:gerv] from comment #33)
> Difference is not necessarily bad. Would you prefer that there was one
> worldwide "trust authority" which said "Here is the list of CAs everyone in
> the world must trust?". The ability for different platforms to make
> different decisions on that point is a strength, not a weakness.

Gerv, you and FF are missing the point. In the end, the network administrator designates who they trust and who they don't trust. I don't care if the store derives from Microsoft or Apple or Mozilla, in the end the administrator determines which roots should be in his store and trusted. Why would any of those administrators purposefully want stores from two vendors to be different? Does it help them at all if accessing a website via Edge is trusted but via FF is not (or vice versa)?

I live in a highly secure world. On our network, only specific roots are allowed no matter whose store. Once on our network Microsoft doesn't own the store and Mozilla doesn't own the store, the admins do. Because Mozilla thinks they do, they make double effort for everything (this change will make less of that for sure, but it may lead to new ways to make mistakes too). But errors happen because two different stores require two sets of controls to generate the same exact roots in each store.

If I was on a less demanding network in terms of security, I would still never want Edge and FF to respond differently to a root cert request. The headaches from "I can get to it on FF but not on Edge, why is that?" would be more than I would care to handle. So even if I don't want to scrutinize each and every root certificate I choose to load in my stores, I still wouldn't want the stores to be different.

In the end, the administrator owns ALL of the stores. If they implement FF, they just get to do double the effort to keep them the same (no matter what security level they desire).

Norman

Comment 35

[Gervase Markham [:gerv]]

(In reply to Norman Vadnais from comment #34)
> If I was on a less demanding network in terms of security, I would still
> never want Edge and FF to respond differently to a root cert request. 

Then you can petition Microsoft to abandon their root program and adopt all the decisions we make :-)

Gerv

Comment 36

[Norman Vadnais]

(In reply to Gervase Markham [:gerv] from comment #35)
> Then you can petition Microsoft to abandon their root program and adopt all
> the decisions we make :-)

So when a valid point is made counter to the party line on this board, the conversation is abandoned and we get the standard, "Then have them all adopt the great stuff we do!" And the struggles with using the Mozilla product continue and organizations continue to abandon it and the "Mozilla's way or the highway!" attitude.

And those of us stuck supporting FF still have no reason why the Mozilla store would ever be different than the store used by EVERY OTHER PROGRAM on the computer. But Mozilla still requires we create a second store.

Norman

Comment 37

[Gervase Markham [:gerv]]

(In reply to Norman Vadnais from comment #36)
> (In reply to Gervase Markham [:gerv] from comment #35)
> > Then you can petition Microsoft to abandon their root program and adopt all
> > the decisions we make :-)
> 
> So when a valid point is made counter to the party line on this board

Mozilla has made a decision to do things the way we currently do them. It's an intentional decision, we have no plans to change it, and we have what we think are good reasons. You may disagree with those reasons, but you now know what they are. Given that, there's not much more to say. It is not the purpose of Bugzilla that an argument must continue until you get what you want.

Gerv

Comment 38

[Andrew]

Gerv, I feel we are going round in circles, after I thought we made progress with Mozilla.

You should bear in mind there are two separate environments here, for the home user you can continue your crusade for change in the CA industry and be the White knight protecting users from the evil Microsoft and Apple and their compromised root programs.

For the corporate environments you must accept it is the Network Administrator that is your user, the network and security is their responsibility, users agree to these conditions with their employment.

By refusing to add the ability to trust the OS store (Microsoft or Apple) you are alienating corporate environments, something Apple used to do but is slowly getting better, accepting that business IT require control not them. You need to realise the same thing, the customer is always right, if they want the option to trust the OS store add it, have it default off, hide the option in the about:config so home users don't turn it on by mistake, but give network admins the ability to turn it on via Group Policy.

You will find you have pushed your browser out of the corporate space, you can try and whinge its Microsoft and Apple's fault, but really it's your own by refusing to give users the choice, you're as bad as Apple insisting YOU know best and suggesting we petition Microsoft to change their program and adopt yours because you refuse corporate network admins the ability to use the inbuilt OS store, listen to yourself, I hope that was said in jest otherwise you truly are delusional in your crusade.

On your operating system, you can make the rules, if you want your product to be popular on Windows or Mac then you need to at least have the option of using their security, even if it's not the default. You are only hurting yourselves and users, by forcing network admins to not support and ban your software on their network, removing it from users at work and not allowing users to use it at home to connect to work systems, less exposure for your browser, less adoption even perhaps at home, less leverage.

For every genuinely concerned network admin here posting on this thread, who WANT to give our users the choice of web browser including Firefox, there's plenty more who have just banned it on their network citing its unmanageability, uncooperative support and incompatibility.

I for one cannot take your crusade for better security seriously if you do so by forcing your rules on others and not listening to users and what they want, I see you as no better than Apple, and you don't have their marketing power house to fall back on.

While Microsoft have their failings, they've always given control and choice to the administrator/user, well until Windows 10 anyway... falling into the Apple/Mozilla crowd there. That's what I respect foremost, sure stick a fisher price cover over it, have a wizard for the IT illiterate, "suggested settings", but don't think you can dictate to the IT literate, we will go elsewhere.

Please rethink your attitude, don't give up on a lofty goal for better, it is not compromising that ideal, you are empowering the user to enable it if they wish, win, win for everyone.

Comment 39

[Charles]

Gerv, no one is or has ever suggested that Mozilla shouldn't have its own store.

All I was asking is why you can not provide the ability to just use the MS store AS AN OPTION.

Not one, single response from you or anyone else has ever answered that question satisfactorily.

Suggesting that *I'm* some kind of **** for daring to ask a simple question by answering it in such a smartass and insulting manner, well, try  this on as a response.

**** YOU, Gerv.

(In reply to Gervase Markham [:gerv] from comment #29)
> Actually Charles, all our security concerns are bogus. We are simply doing
> this to frustrate you and every other Windows enterprise admin out there,
> because we love making your lives difficult.
> 
> ...Or, you could perhaps make the effort to read this bug, related bugs and
> the many discussions which have been had over the years which clearly
> explain why this is not simple. As befits its low number, bug 432802, marked
> as a duplicate of this one, has a lot of the information. 
> 
> Gerv

Comment 40

[Charles]

(In reply to Gervase Markham [:gerv] from comment #31)
> Mozilla makes trust decisions for our users,

I thought Mozilla was all about 'Power to the User'.

Seems there are some power mongers now running Mozilla.

Comment 41

[Gervase Markham [:gerv]]

(In reply to Charles from comment #39)
> All I was asking is why you can not provide the ability to just use the MS
> store AS AN OPTION.

That's what this bug, fixed in Firefox 49, does.

And if you throw swear words around again in Bugzilla, your account will be suspended.

Gerv

Comment 42

[Bruno Marsal (Bullja)]

In addition to CERT_SYSTEM_STORE_LOCAL_MACHINE, I suggest to also read the CAs from CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY. Root CAs distributed using AD Group Policies are located within this system store.

Without FF reading from CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY also, admins would need to locally move Root CAs from CERT_SYSTEM_STORE_LOCAL_MACHINE to CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY to take advantage of security.enterprise_roots.enabled.

Comment 44

[Dana Keeler (she/her) [:keeler]]

Thanks, Bruno - we'll look into that.

Comment 45

[Charles]

(In reply to Gervase Markham [:gerv] from comment #41)
> (In reply to Charles from comment #39)
>> All I was asking is why you can not provide the ability to just use the MS
>> store AS AN OPTION.

> That's what this bug, fixed in Firefox 49, does.

Ok, giving you the benefit of the doubt, I did spend a few minutes reading the history of this request and read dozens of your responses over the last couple of years explaining why *you* (and apparently some others in Mozilla) are against giving Firefox users the simple *option* to trust the MS Cert store, just because... well, just because you don't want to give us the option.

From that light reading, as far as I can tell, what this bug does is provide a method for *importing* user certs from the MS cert store. It certainly does *not* - unless you completely mis-spoke above - provide a simple option that I can check to 'Trust the MS Cert Store'.

Is this incorrect? If it incorrect, then please point out to me how I mis-read your comments above.

If it is correct, then your response to me was just ... plain wrong (I would say it is something else, but that might get my account suspended).

> And if you throw swear words around again in Bugzilla, your account will be
> suspended.

I do apologize for the swearing earlier, I regreted that right after posting it, but I'm now wondering if are you going to suspend my account for simply stating the truth?

Comment 46

[Gervase Markham [:gerv]]

(In reply to Charles from comment #45)
> Ok, giving you the benefit of the doubt, I did spend a few minutes reading
> the history of this request and read dozens of your responses over the last
> couple of years explaining why *you* (and apparently some others in Mozilla)
> are against giving Firefox users the simple *option* to trust the MS Cert
> store, just because... well, just because you don't want to give us the
> option.

Well, clearly it's not technically impossible because Chrome does it. After all, it's all just ones and zeroes, right? So you are right in that we are making an explicit choice not to do this, because we don't feel it's in the best interests of the web to offer that option. And Mozilla's mission is about preserving and protecting the open web. We've explained why we think it's bad for the web to do this by default. And if we offer an option to switch stores entirely, we find some public sites work in one copy of Firefox and not in another, which is also a really bad thing. The patch implemented here augments the root set with those added by the user or admin, which is a good compromise which avoids most of the bad possibilities.

But to be honest, if you don't agree with me after re-explaining it for the Nth time, you aren't going to agree with me. And that's OK. It is not required that you agree with every decision Mozilla makes or position it takes. But we should probably stop going round in circles on the topic.

> From that light reading, as far as I can tell, what this bug does is provide
> a method for *importing* user certs from the MS cert store.

I think, from reading the code, keeler is using the word "import" in a different sense to you. The code adds any certs discovered at runtime (which were added by the user or the admin, but not by Microsoft) to the list of certs NSS trusts, and it does it every time NSS starts. But perhaps he can clarify, if he wishes to.

Gerv

Comment 47

[Charles]

So what it boils down to is you, personally, and apparently a few others at Mozilla, have taken it upon yourselves to assume the power to dictate to the Users what they can or cannot Trust, cert wise. Got it. Most likely this is directly related to the very vocal and evident disdain Mozilla has for Enterprise Users (the ones most impacted by this).

Also I take note that even after I apologized for my choice of words, you didn't apologize for being a condescending jerk in your initial response to my simple and honest question.

Comment 48

[Gervase Markham [:gerv]]

(In reply to Charles from comment #47)
> So what it boils down to is you, personally, and apparently a few others at Mozilla, have taken it upon yourselves to assume > the power to dictate to the Users what they can or cannot Trust, cert wise.

This twisted "summary" is a great example of why I have no interest in discussing this further with you.

> Also I take note that even after I apologized for my choice of words, you
> didn't apologize for being a condescending jerk in your initial response to
> my simple and honest question.

A "simple and honest question" which revealed that you had made no attempt to do research to answer it yourself, but would rather take up my time than your own. One which took the entitled stance that the world owes you an explanation for everything anyone does, and you have been personally unfairly slighted if one is not provided.

Instead of waiting for me to apologise, you could use the time to ponder how you might approach interactions such as this one in future in the frame of mind that everyone else's time is at least as precious as your own. Meantime, I'm done here.

Gerv

Comment 49

[Kevin G]

Gerv,

Just a quick question about version 49, which seems to address the resolution I'm looking for: when is it expected to be released to the public?

I'm asking because I'm working on a project to implement SSO and because I cannot add the internal root CA to Firefox (to authenticate on an IWA server) in a way that is easy (like IE/Edge and Chrome, there's no way we are manually adding it to 500+ workstations or having the end users follow a procedure), I need to make a decision by the end-of-day tomorrow to pull Firefox out of our environment or keep it if it falls within our timeline.  Also, would downloading and trying the Developer Edition on a test machine allow me to confirm this functionality?

Thanks!

Comment 50

[Gervase Markham [:gerv]]

Kevin: according to https://wiki.mozilla.org/RapidRelease/Calendar, Firefox 49 is due for release on 2016-09-13. Developer Edition is indeed currently Firefox 49, so this feature can be tested using that.

I don't believe this is the only way to deploy a root to 500 workstations; consulting with our Enterprise group https://wiki.mozilla.org/Enterprise might well reveal others which do not require a manual update to every workstation, even if they are not quite as simple as the one this bug enables.

Gerv

Comment 51

[Kevin G]

Thanks for the response, Gerv.  Much appreciated and will look into the Enterprise group for more options.

Comment 52

[Charles]

(In reply to Gervase Markham [:gerv] from comment #48)
> This twisted "summary" is a great example of why I have no interest in
> discussing this further with you.

Twisted? In what way is it 'twisted'? Was this not a decision made by you and/or others at Mozilla? I found lots of references to you answering similar questions as mine going back at least 2 years, and you certainly did seem to be - as you do now - in favor of limiting the users power in this case - ie, defending this decision.

>> Also I take note that even after I apologized for my choice of words, you
>> didn't apologize for being a condescending jerk in your initial response to
>> my simple and honest question.

> A "simple and honest question" which revealed that you had made no attempt
> to do research to answer it yourself,

You are very wrong Gerv, and this ass-u-me-ption is the problem. I did try to answer it myself. I found nothing definitive - which is why I asked.

I didn't find an answer, probably because it is hidden behind lots of obfuscation dancing around the fact that there really isn't a legitimate reason\ other than you (Mozilla) just decided to do it your way, and to heck with user choice.

> but would rather take up my time than your own.

What you should have done seeing how you feel this way is simply ignore my question, but you, sir, are the one who decided to answer in a totally condescending and derogatory manner.

> One which took the entitled stance that the world owes you an
> explanation for everything anyone does, and you have been personally
> unfairly slighted if one is not provided.

Oh please... if you seriously read my question in that light then you have a much more serious personal problem than I initially thought.

> Instead of waiting for me to apologise,

Who said I was waiting?

> you could use the time to ponder how you might approach interactions 
> such as this one in future in the frame of mind that everyone else's
> time is at least as precious as your own.

Sorry, but I do believe that many hours or even days of my time (this is what it would probably take to read all of the history of this issue over the years) is much more valuable than the one minute of your time it would take to answer the question. If that makes me a lazy entitled ass, so be it.

> Meantime, I'm done here.

And again, you should have simply ignored my question rather than insult me.

Comment 53

[Gervase Markham [:gerv]]

Keeler: can you document how to use this for deploying roots somewhere, perhaps on a wiki page under https://wiki.mozilla.org/Enterprise , so we have somewhere to point people who want to know how to do it?

Gerv

Comment 54

[Norman Vadnais]

(In reply to Gervase Markham [:gerv] from comment #53)
> Keeler: can you document how to use this for deploying roots somewhere,
> perhaps on a wiki page under https://wiki.mozilla.org/Enterprise , so we
> have somewhere to point people who want to know how to do it?
> 
> Gerv

In documenting this functionality, please help the network administrators among us understand the easiest and most direct way to make sure the two stores are equivalent (I say that because this update seems to happen at runtime and therefore the Firefox physical store is unchanged). Network administrators just want to make sure all certificates on their network are treated the same in all applications.

Norman

Comment 55

[Dana Keeler (she/her) [:keeler]]

Hi Gerv, I added a section in https://wiki.mozilla.org/CA:AddRootToFirefox describing how to enable this and what it does.

Norman - is that sufficient? Are there any more details I should include? Thanks.

Comment 56

[Norman Vadnais]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #55)
> Hi Gerv, I added a section in https://wiki.mozilla.org/CA:AddRootToFirefox
> describing how to enable this and what it does.
> 
> Norman - is that sufficient? Are there any more details I should include?
> Thanks.

David,

I'm not sure about the information in Bug 1289865, as I think it is miswritten. In the first paragraph it speaks to the LOCAL_MACHINE_GROUP_POLICY store NOT being included in enterprise_roots but the second speaks to extra handling for the LOCAL_MACHINE store to make sure enterprise_roots reads it. You may want to correct that (I could post a note if you wish). Otherwise what you have written, with the inclusion of that reference (once fixed), seems to cover things.

Unfortunately, this further emphasizes a Domain Admin's issues with the approach, as using the certificate API won't load a certificate to multiple stores (Bruno says "move"). To actually make the LOCAL_MACHINE_GROUP_POLICY (LMGP) certificates visible in the LOCAL_MACHINE (LM) store, you need to (1) export them from LMGP; (2) delete them from LMGP; and (3) import them into LM. Domain Admins live off of the LMGP store; it's the easiest prebuilt way to distribute certificates broadly. That's a whole lot of distributed scripting to make those certificates visible to enterprise_roots.

Comment 57

[Dana Keeler (she/her) [:keeler]]

Yeah, that looks like a typo (I think LM and LMGP were just switched in the second paragraph - I'll go ahead and comment in the bug). In any case, it sounds like bug 1289865 will have to be fixed before this is really a useful feature. I appreciate the feedback, Norman - that's exactly the kind of thing we need to know here.

Comment 58

[Norman Vadnais]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #57)
> In any case, it sounds like bug 1289865 will have to be fixed before this is really a useful
> feature.

I should mention that I also find it kind of funny the option loading things stored in LM (its LOCAL) is called enterprise_roots. Most orgs place their enterprise roots in LMGP.

> I appreciate the feedback, Norman - that's exactly the kind of thing we need to know here.

Anything I can do to help you better support Network/Domain Admins!

Norman

Comment 59

[Michael Haase]

I found this topic a few days ago searching for any news on this topic, and I am happy to see this new feature coming as we use Firefox as 2nd browser in our enterprise environment and having more and more intranet sites using https and self-signed certs.

On a test machine, I switched to Firefox Beta channel, FF 49 beta got installed.
And I can acknowledge that it perfectly works with our certificates that we deploy via GPO to all machines. Our intranet sites open without the warning notice, and Firefox 49 shows a green lock symbol indicating that everything is fine/trusted. Just as with Internet Explorer!

Michael

Comment 60

[Chris Hills]

As an operator of a certificate trust list, what liability does Mozilla assume if an end-user is defrauded by a certificate issued from one of the built-in CA certificates? I get the impression from the comments on this issue that although Firefox will trust additional certificates from the computer's trust list, it will also continue trusting Firefox's built in certificates.

Comment 61

[Gervase Markham [:gerv]]

It's not possible to be "defrauded by a certificate", one can only be defrauded by another person. As manager of a certificate trust list, you will know that certificates are evidence of the identity of a site (or person), not its trustworthiness. And responsibility for that assertion of identity remains with the organization who made it - the CA.

Gerv

Comment 62

[Shane]

(In reply to Gervase Markham [:gerv] from comment #50)
> Kevin: according to https://wiki.mozilla.org/RapidRelease/Calendar, Firefox
> 49 is due for release on 2016-09-13. Developer Edition is indeed currently
> Firefox 49, so this feature can be tested using that.
> 
> I don't believe this is the only way to deploy a root to 500 workstations;
> consulting with our Enterprise group https://wiki.mozilla.org/Enterprise
> might well reveal others which do not require a manual update to every
> workstation, even if they are not quite as simple as the one this bug
> enables.
> 
> Gerv

The information is not readily available to get this done.  Mostly, "Use this tool" with no REAL information.  I had to cobble together 3 different sources to get a working solution, and the problem with that is that it NEVER works on the first loging because the profile isn't created.  After that, I have to run certutil on every subsequent login and make sure Firefox is close while doing so.  Not elegant at all.  And then we have to toggle this on and off with no "real", updated ADMX files to manage the settings.  Or use a plugin, which requires even more steps and learning how to use.  Why do this when we can just use a GPO for IE and Chrome.  I work at a school and Firefox use has dropped to almost nothing because it requires too much work.  Mainly with certs and needing to filter SSL traffic.  I have a documented way to do this using CERTUTIL, but it's a cumbersome way to tackle this and most don't bother and just recommend Chrome first and IE second.

Comment 63

[YUKI "Piro" Hiroshi]

At the comment 27 Grev told that another bug for Mac OS X (macOS) must be filed as a separate bug, but I couldn't find out it, this I've filed it as the bug 1300420. (Sorry if there is already filed bug for the purpose...)

Comment 64

[Alex]

Sorry guys, maybe I'm missing something obvious but I can't seem to find the security.enterprise_roots.enabled setting in about:config of both my FF49 and FF49b10 installations.

Comment 65

[Gervase Markham [:gerv]]

Right-click and choose "New" -> "Boolean", enter the pref name and select "true".

Gerv

Comment 66

[Alex]

Thanks Gerv, got it working- I expected it to be an existing setting.
Only found a limitation. 
I did tests with a proxy server which does intercept thhe SSL stream and resigns the server's cert
with its own CA. So I installed this CA cert into the local machine certificate store and after setting the enterprise roots in FF to true, it seemed to work - but it's not for websites as facebook or google which use HSTS (HTTP Strict Transport Security)
Would you consider this a known/expected limitation or a new bug? 
Thanks
Alex

Comment 67

[Dana Keeler (she/her) [:keeler]]

That is unexpected. Please file a new bug with as much detail as you can include - thanks.

Comment 68

[Johan Corveleyn]

I'm not sure if what I'm seeing is the same problem as mentioned in comment #42 (about not reading CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY) which lead to issue 1289865, but: if our Root CA is installed in HKLM\SOFTWARE\Microsoft\SystemCertificates\Root, it works with FF 49, but if it's installed in HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root, it doesn't. Is that intended?

Our sysadmins tell me EnterpriseCerificates is the location where you get the CA cert automatically installed by AD, when you're part of the domain. So from where I'm sitting EnterpriseCertificates seems to be one of the places that FF should trust (when the option is enabled).

Additional peculiarity: with ProcMon we see that firefox.exe actually reads the certs under EnterpriseCertificates from the registry (in addition to reading SystemCertificates), so why isn't it using them?

Comment 69

[Michael Haase]

Is there any difference between Windows 7 and Windows 10 related to this new feature?
Because in our enterprise environment on a Win 10 x64 machine, FF 49 works with our own certificates for intranet sites, but on Win 7 x86 it does not work. I use Firefox Portable, so it is the same Firefox profile.

I have tested only on 3 machines, yet and have not analyzed it further.
Does someone have Win 7 with working Windows certificates in FF49?

Comment 70

[Dana Keeler (she/her) [:keeler]]

Hi folks,

It's great to see the interest in this feature. However, this bug is not the best place to discuss issues with and questions about it. If you have discovered behavior that seems like a bug, please file a new bug here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security%3A%20PSM (also do a quick search to see if someone has already filed a similar bug).
If there are more general questions about the feature and how it is intended to work, please use the Enterprise mailing list: https://mail.mozilla.org/listinfo/enterprise

Thanks!

Comment 71

[Judah Richardson]

(In reply to Alex from comment #66)
> Thanks Gerv, got it working- I expected it to be an existing setting.
> Only found a limitation. 
> I did tests with a proxy server which does intercept thhe SSL stream and
> resigns the server's cert
> with its own CA. So I installed this CA cert into the local machine
> certificate store and after setting the enterprise roots in FF to true, it
> seemed to work - but it's not for websites as facebook or google which use
> HSTS (HTTP Strict Transport Security)
> Would you consider this a known/expected limitation or a new bug? 
> Thanks
> Alex

Hi Alex, I'm having the same problem too. Actually, even after setting config flag to true I still can't get any non-Google HTTPS sites to load in Nightly x64 on a domain Win 7 machine. Do you have a link to the bug you filed, if any? Thanks

Comment 74

[josh.schofield]

FYI, I filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1333118 per Comment #68 from Johan Corveleyn

Comment 75

[Cailin]

Hi,

This might be the wrong place to bring this up, if so, please direct me to the right place, but it doesn't seem possible at all to import client certificates. It doesn't happen automatically, even when setting the security.enterprise_root.enabled to true (though this might be desired behavior, given the setting name?). It's not possible to do this manually either, as it's not possible to export the private key from the windows certificate manager. This makes it impossible to use smart card authentication and Windows Hello certificates in Firefox. This works fine in Edge and Chrome, so it's definitely possible, but I don't know how to do that. It seems to me that client certificates should be imported automatically if you're also importing root certificates, though the setting name might be a bit misleading in that case.

I'd even be ok with a manual import step, but that doesn't seem possible either, given the restrictions on exporting the certs private keys.

Comment 76

[Judah Richardson]

(In reply to Cailin from comment #75)
> Windows Hello certificates in Firefox. This works fine in
> Edge and Chrome, so it's definitely possible

AFAIK Windows Hello support requires FIDO support (I could be really wrong here, but I think they're related on Windows.) IIRC Firefox hasn't implemented support for the latter just yet, though I do recall reading it's on the roadmap.

Comment 77

[Dana Keeler (she/her) [:keeler]]

Hi Cailin, this feature imports root certificate authority certificates, not client certificates. Unfortunately Firefox doesn't have the ability to use client certificates that are in the Windows certificate store. See bug 1120350.

Judah - FIDO shipped as WebAuthn in Firefox 60 (although Microsoft is apparently making a change to how it works on Windows this Spring, so there'll need to be an update).

Comment 78

[Ben Bucksch (:BenB)]

This is highly dangerous.

It makes our management of root CAs much more difficult. See e.g. Symantec case, the ongoing DarkMatter discussion of the inclusion criteria, etc. The entire discussion is about whether or not to include certain CAs. If you wholesale include all CAs from Windows, you defer the discussion to Microsoft and make the entire Root CA policy that we have completely moot.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
The way I see it, this effort is in direct contradiction to our established root CA policy and rules.

Comment 79

[Judah Richardson]

(In reply to Ben Bucksch (:BenB) from comment #78)

If you scroll up and read the rest of the thread you'll see those concerns are already addressed. This is a feature that can be optionally enabled for users (like myself) who need it. Without it, it's far more difficult to use Firefox in the enterprise.

Comment 80

[Norman Vadnais]

(In reply to Ben Bucksch (:BenB) from comment #78)

Ben,

I don't see how this changes the root CA policy. This allows those who MUST manage these things manage a single list instead of multiple lists. It is almost a requirement for Enterprise use of Firefox.

I have to know what root CAs are trusted no matter what tool a user is using. So I have to manage the MS Certificate Store very carefully. I want my Mozilla tools to use this same very carefully managed list, without having to manage it all over again. This feature allows me to do that without altering the configuration of those users who choose to have separate certificate stores.