Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
The new functionality is a result of bug 1289865 [0] being fixed. Barring the unexpected, these changes will ship in Firefox 52. Thank you to everyone who has tested out and given feedback on this feature, and thank you in particular to Bruno for investigating which trust store identifiers to use. As always, please let us know if this feature does not work as expected. Cheers, David [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1289865 On 10/13/2016 04:32 AM, Michael Haase wrote: > Hi Bruno, > > I can confirm the same for my environment. > FF 50b6 seems not to have the new routine, but with FF52a1 nightly it > works on all tested machines now. > > Michael > > From: Bruno Marsal > > Just installed the nightly from few hours ago, set > security.enterprise_roots.enabled and verified FF trusts certificates > created by those stored in CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE > and CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY. It works! > > Very happy this was implemented finally. > > Bruno > > > ___ > Enterprise mailing list > Enterprise@mozilla.org > https://mail.mozilla.org/listinfo/enterprise > > To unsubscribe from this list, please visit > https://mail.mozilla.org/listinfo/enterprise or send an email to > enterprise-requ...@mozilla.org with a subject of "unsubscribe" > signature.asc Description: OpenPGP digital signature ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
Hi Bruno, I can confirm the same for my environment. FF 50b6 seems not to have the new routine, but with FF52a1 nightly it works on all tested machines now. Michael From: Bruno Marsal Just installed the nightly from few hours ago, set security.enterprise_roots.enabled and verified FF trusts certificates created by those stored in CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE and CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY. It works! Very happy this was implemented finally. Bruno ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
rvices" role on it and created a initial root CA - Rebooted the client and then looked for the location of the new Initial root CA certificate After the client rebooted, the new initial root CA could be found at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates and can be listed on the client using "certutil -viewstore -enterprise root". Also using CertOpenStore using PowerShell [1] with flag CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE (0x9) this initial root CA from Certificate Services was revealed. Bruno PS: I just set up a test env within my free Azure trial (200$). Contact me in case you want to do some further tests within this test env. Will power it up again for few hours if somebody wants access to look at this group policy management / certificate services stuff. [1] http://pastebin.com/xW2s4Guf - PowerShell snippet for calling CertOpenStore without need for compiling anything. I copied and edited the snippet from this thread: https://social.technet.microsoft.com/Forums/office/en-US/eb3f8f93-07ff-4d30-8b0a-7a5bfbb9420e/how-to-retrieve-certificate-information-from-a-remote-server-with-powershell?forum=winserverManagement -----Original Message----- From: Enterprise [mailto:enterprise-boun...@mozilla.org] On Behalf Of Johan Corveleyn Sent: Saturday, October 1, 2016 10:10 AM To: David Keeler Cc: enterprise@mozilla.org Subject: Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113) Hi David, I think CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE is indeed the correct key that corresponds to HKLM\SOFTWARE\Microsoft\EnterpriseCertificates (though it's hard to find information about this). So if that could be added together with fixing bug 1289865 that would be great! I've added it to the comments in that bug. Thanks, -- Johan On Fri, Sep 30, 2016 at 10:53 PM, David Keeler wrote: Hi Johan, Currently the implementation only uses the CERT_SYSTEM_STORE_LOCAL_MACHINE flag to search for certificates, which as you've discovered corresponds to the registry location HKLM\SOFTWARE\Microsoft\SystemCertificates (see [0]). We're investigating looking in other locations such as CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY (which I think corresponds to HKLM\SOFTWARE\Policy\Microsoft\SystemCertificates) (see [1] and [2]). I'm not certain which flag corresponds to HKLM\SOFTWARE\Microsoft\EnterpriseCertificates, but it might be CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE. If this turns out to be correct, we can probably just make that change in bug 1289865 as well. Cheers, David [0] https://dxr.mozilla.org/mozilla-central/rev/9baec74b3db1bf005c66ae2f50 bafbdb02c3be38/security/manager/ssl/nsNSSComponent.cpp#974 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1289865 [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa388136(v=vs .85).aspx On 09/28/2016 02:18 AM, Johan Corveleyn wrote: Hi all, this is my first post to this list. After asking a question in bugzilla issue 1265113 [1], David Keeler asked to post to this list instead of discussing in the issue tracker. So here we go: The feature of trusting custom root CA's when they're in Windows' truststore (which is the subject of issue 1265113) works as of FF 49 (when config option security.enterprise_roots.enable is set to true). However, it's not clear to me why FF only trust one particular registry location and not the other. If our Root CA is installed in HKLM\SOFTWARE\Microsoft\SystemCertificates\Root, it works, but if it's installed in HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root, it doesn't. Is that intended? How was it decided which registry keys to trust? 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? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1265113 (Windows platform support for trusting enterprise roots) ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe" ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ.
Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
As I wrote that we deploy our certificates via GPO, you meant that it is AD Certificate Services. What we do: - Open Group Policy Editor - choose and open policy for our clients - Navigate through: Computer Configuration / Policies / Windows Settings / Security Settings / Policies for Public Keys - Add our root certificate to Trustworthy Root Certificate Authorities - Add our intermediate certificate to Intermediate Authorities (As we have German systems, I translated the above to English, in Original English it might have slightly different names.) For me, this is Group Policy (GPO). The result is, that in the Registry on the clients you find our certificates in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates I do not know why it works on some machines with Firefox 49, and not on some others, always the EnterpriseCertificates location. I downloaded FF 50.0.b5 today, no difference to FF 49 release version, only on some machines it works. And I cannot see a difference between the machine configurations. I do not know if in FF 50 beta 5 the other reg keys are already added. So far, Michael ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
sorry for bad formatting, the important stuff again: Distribution Method: 1. AD Group Policy Management Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates Certutil command: certutil -viewstore -grouppolicy root Flag to read using CertOpenStore: CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY Used already when security.enterprise_roots.enable is true: no Distribution Method: 2. AD Certificate Services Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates Certutil command: certutil -viewstore -enterprise root Flag to read using CertOpenStore: CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE Used already when security.enterprise_roots.enable is true: no Distribution Method: 3. Manually import certificate on a system Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates Certutil command: certutil -viewstore root Flag to read using CertOpenStore: CERT_SYSTEM_STORE_LOCAL_MACHINE Used already when security.enterprise_roots.enable is true: yes Bruno -Original Message- From: Bruno Marsal [mailto:br...@marsal.biz] Sent: Sunday, October 2, 2016 5:39 AM To: 'David Keeler' Cc: enterprise@mozilla.org Subject: RE: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113) As Johan mentioned "it's hard to find information about" which CERT_SYSTEM_STORE_* flag corresponds to which registry location, I looked into this topic again and want to try to summarize my findings hoping this may be of help... There are at least the following methods to distribute Trusted CAs within an enterprise environment: Distribution Method: 1. AD Group Policy Management Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates Certutil command: certutil -viewstore -grouppolicy root Flag to read using CertOpenStore: CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY Used already when security.enterprise_roots.enable is true: no Distribution Method: 2. AD Certificate Services Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates Certutil command: certutil -viewstore -enterprise root Flag to read using CertOpenStore: CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE Used already when security.enterprise_roots.enable is true: no Distribution Method: 3. Manually import certificate on a system Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates Certutil command: certutil -viewstore root Flag to read using CertOpenStore: CERT_SYSTEM_STORE_LOCAL_MACHINE Used already when security.enterprise_roots.enable is true: yes Depending which method IT administrators use to roll out the Trusted CAs, the certificates will reside at a different registry location. In my opinion, FF should read from all these locations, due to the fact companies rollout certificates using different methods. The initial attempt in https://bugzilla.mozilla.org/show_bug.cgi?id=1265113 "for trusting enterprise roots" solved the support for the "3. Manually import certificate on a system" method. Another bug https://bugzilla.mozilla.org/show_bug.cgi?id=1289865 will hopefully solve the support for the "1. AD Group Policy Management" method. Johans sysadmins say "EnterpriseCerificates is the location where you get the CA cert automatically installed by AD". This is the case when certificates are distributed using "2. AD Certificate Services". I invested some hours for searching/testing/interpreting and finally set a up test environment (for distribution method 1 and 2) and just invoked the CertOpenStore function verifying the flags to be used. I wasn't 100% sure about the registry locations before, but now I am as I have tested them myself. I hope the above summary helps, at least it is personal summary for myself now. You may skip the next part unless you are interested in the test environment setup. This is how the locations of the certificates were verified after distributing them. I first created the following servers within the Azure test environment: 1 domain controller, 1 client. Created a new domain and joined the client to it. To find out at which location the "Trusted Root CAs" are located when distributing them using "1. AD Group Policy Management", did the following (typical steps for IT admins): - Created a Organizational Unit (OU) "emea" using "Active Directory Users and Computers" - Moved the client to OU "emea" - Created a new GPO named "trust-internal-services" in the "emea" OU using "Active Directory Group Policy Management" - Imported a test CA (took one from this location: https://www.geotrust.com/resources/root-certificates/) into the "trust-internal-service" GPO in the following setting: Computer C
Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
CertOpenStore using PowerShell [1] with flag CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE (0x9) this initial root CA from Certificate Services was revealed. Bruno PS: I just set up a test env within my free Azure trial (200$). Contact me in case you want to do some further tests within this test env. Will power it up again for few hours if somebody wants access to look at this group policy management / certificate services stuff. [1] http://pastebin.com/xW2s4Guf - PowerShell snippet for calling CertOpenStore without need for compiling anything. I copied and edited the snippet from this thread: https://social.technet.microsoft.com/Forums/office/en-US/eb3f8f93-07ff-4d30-8b0a-7a5bfbb9420e/how-to-retrieve-certificate-information-from-a-remote-server-with-powershell?forum=winserverManagement -----Original Message----- From: Enterprise [mailto:enterprise-boun...@mozilla.org] On Behalf Of Johan Corveleyn Sent: Saturday, October 1, 2016 10:10 AM To: David Keeler Cc: enterprise@mozilla.org Subject: Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113) Hi David, I think CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE is indeed the correct key that corresponds to HKLM\SOFTWARE\Microsoft\EnterpriseCertificates (though it's hard to find information about this). So if that could be added together with fixing bug 1289865 that would be great! I've added it to the comments in that bug. Thanks, -- Johan On Fri, Sep 30, 2016 at 10:53 PM, David Keeler wrote: > Hi Johan, > > Currently the implementation only uses the > CERT_SYSTEM_STORE_LOCAL_MACHINE flag to search for certificates, which > as you've discovered corresponds to the registry location > HKLM\SOFTWARE\Microsoft\SystemCertificates (see [0]). > > We're investigating looking in other locations such as > CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY (which I think > corresponds to HKLM\SOFTWARE\Policy\Microsoft\SystemCertificates) (see [1] > and [2]). > > I'm not certain which flag corresponds to > HKLM\SOFTWARE\Microsoft\EnterpriseCertificates, but it might be > CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE. If this turns out to be > correct, we can probably just make that change in bug 1289865 as well. > > Cheers, > David > > [0] > https://dxr.mozilla.org/mozilla-central/rev/9baec74b3db1bf005c66ae2f50 > bafbdb02c3be38/security/manager/ssl/nsNSSComponent.cpp#974 > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1289865 > [2] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa388136(v=vs > .85).aspx > > On 09/28/2016 02:18 AM, Johan Corveleyn wrote: >> Hi all, this is my first post to this list. >> >> After asking a question in bugzilla issue 1265113 [1], David Keeler >> asked to post to this list instead of discussing in the issue tracker. >> So here we go: >> >> The feature of trusting custom root CA's when they're in Windows' >> truststore (which is the subject of issue 1265113) works as of FF 49 >> (when config option security.enterprise_roots.enable is set to true). >> However, it's not clear to me why FF only trust one particular >> registry location and not the other. If our Root CA is installed in >> HKLM\SOFTWARE\Microsoft\SystemCertificates\Root, it works, but if >> it's installed in >> HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root, it doesn't. Is >> that intended? How was it decided which registry keys to trust? >> >> 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? >> >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1265113 (Windows >> platform support for trusting enterprise roots) >> > > > ___ > Enterprise mailing list > Enterprise@mozilla.org > https://mail.mozilla.org/listinfo/enterprise > > To unsubscribe from this list, please visit > https://mail.mozilla.org/listinfo/enterprise or send an email to > enterprise-requ...@mozilla.org with a subject of "unsubscribe" ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe" ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
Michael, do you deploy using GPO or via AD Certificate services? If I understand correctly, deploying CAs using GPO result them beeing stored in HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates deploying CAs using AD Certificate services results them beeing stored in HKLM\SOFTWARE\Microsoft\EnterpriseCertificates The behaviour you are describing may be due the fact the machines are in different OUs and the CAs are rolled out to specific OUs only!? Also, FF neither trusts certis in HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates or HKLM\SOFTWARE\Microsoft\EnterpriseCertificates. It only trusts certificates stored at HKLM\SOFTWARE\Microsoft\SystemCertificates. There is no way certificates are stored at the latter location when distributed using GPOs -> This means your FF will not trust your certs distributed using GPOs unless you have another services which copies them from HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates to HKLM\SOFTWARE\Microsoft\SystemCertificates Bruno -Original Message- From: Enterprise [mailto:enterprise-boun...@mozilla.org] On Behalf Of Michael Haase Sent: Saturday, October 1, 2016 9:34 AM To: enterprise@mozilla.org Subject: Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113) Hi, we deploy our own certificates via GPO to our clients. Those are (only) in HKLM\SOFTWARE\Microsoft\EnterpriseCertificates (not in HKLM\SOFTWARE\Microsoft\SystemCertificates). I put a Firefox 49 portable on USB stick to test the same version and profile on different machines and different Windows users. And I always call the same internal https intranet site to see if I can open it without certificate interaction. On a Windows 10 x64 test machine with standard user it works. On my own Windows 7 x86 machine with my user having admin rights (but you work without admin rights unless Windows requests them via UAC), it does not work. Starting Firefox as another user and running it as a standard user, it does not work either. On a second Windows 7 x86 machine from my colleague the same, it does not work. On a third Windows 7 x86 machine it works with its standard user, also with my test standard user, and also if I start Firefox with my admin user. So, it seems to be the machine configuration whether it works or not. But I do not know what it is. All machines are deployed centrally using SCCM. And all Windows 7 machines have received the same updates. I did tests with Process Monitor on all machines, and I can see that Firefox reads both registry paths mentioned above (SystemCertificates and EnterpriseCertificates), I can see nothing that helps me understand why it does work on some machines and not on others. I know that my tests are quite limited to very few machines and users, but I wanted to share that information with you, maybe you can help. But what David writes, that Firefox does right now not use EnterpriseCertificates confuses me, as our certificates are only there, and I checked SystemCertificates location in registry - they are not in there, only in EnterpriseCertificates and it works on some machines. And why does Process Monitor show that Firefox reads EnterpriseCertificates? Cheers, Michael ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe" ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
Hi Michael, Glad to see I'm not the only one running into these issues. Though it's not exactly clear what's precisely going on in your situation. In my case, I saw that if I manually copied the specific cert from EnterpriseCertificates to SystemCertificates (creating a new key with the same value, and copying the blob), then it worked. But indeed, I also found it quite strange that, using ProcMon, I could see that firefox really read all the registry keys in EnterpriseCertificates, but didn't turn out to trust them. Maybe that registry access is done by another part of the FF code, not related to trusting root CA's ... hard to say. Anyway, given David's response I added the request to also trust CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE (aka HKLM\SOFTWARE\Microsoft\EnterpriseCertificates, if I understand correctly) to bug 1289865 [1]. Crossing my fingers now :-) ... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1289865 -- Johan On Sat, Oct 1, 2016 at 9:33 AM, Michael Haase wrote: > Hi, > > we deploy our own certificates via GPO to our clients. > Those are (only) in HKLM\SOFTWARE\Microsoft\EnterpriseCertificates (not in > HKLM\SOFTWARE\Microsoft\SystemCertificates). > > I put a Firefox 49 portable on USB stick to test the same version and > profile on different machines and different Windows users. And I always call > the same internal https intranet site to see if I can open it without > certificate interaction. > > On a Windows 10 x64 test machine with standard user it works. > On my own Windows 7 x86 machine with my user having admin rights (but you > work without admin rights unless Windows requests them via UAC), it does not > work. Starting Firefox as another user and running it as a standard user, it > does not work either. > On a second Windows 7 x86 machine from my colleague the same, it does not > work. > On a third Windows 7 x86 machine it works with its standard user, also with > my test standard user, and also if I start Firefox with my admin user. > > So, it seems to be the machine configuration whether it works or not. But I > do not know what it is. > All machines are deployed centrally using SCCM. And all Windows 7 machines > have received the same updates. > > I did tests with Process Monitor on all machines, and I can see that Firefox > reads both registry paths mentioned above (SystemCertificates and > EnterpriseCertificates), I can see nothing that helps me understand why it > does work on some machines and not on others. > > I know that my tests are quite limited to very few machines and users, but I > wanted to share that information with you, maybe you can help. > > But what David writes, that Firefox does right now not use > EnterpriseCertificates confuses me, as our certificates are only there, and > I checked SystemCertificates location in registry - they are not in there, > only in EnterpriseCertificates and it works on some machines. And why does > Process Monitor show that Firefox reads EnterpriseCertificates? > > Cheers, > Michael > > ___ > Enterprise mailing list > Enterprise@mozilla.org > https://mail.mozilla.org/listinfo/enterprise > > To unsubscribe from this list, please visit > https://mail.mozilla.org/listinfo/enterprise or send an email to > enterprise-requ...@mozilla.org with a subject of "unsubscribe" ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
Hi David, I think CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE is indeed the correct key that corresponds to HKLM\SOFTWARE\Microsoft\EnterpriseCertificates (though it's hard to find information about this). So if that could be added together with fixing bug 1289865 that would be great! I've added it to the comments in that bug. Thanks, -- Johan On Fri, Sep 30, 2016 at 10:53 PM, David Keeler wrote: > Hi Johan, > > Currently the implementation only uses the > CERT_SYSTEM_STORE_LOCAL_MACHINE flag to search for certificates, which > as you've discovered corresponds to the registry location > HKLM\SOFTWARE\Microsoft\SystemCertificates (see [0]). > > We're investigating looking in other locations such as > CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY (which I think corresponds > to HKLM\SOFTWARE\Policy\Microsoft\SystemCertificates) (see [1] and [2]). > > I'm not certain which flag corresponds to > HKLM\SOFTWARE\Microsoft\EnterpriseCertificates, but it might be > CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE. If this turns out to be > correct, we can probably just make that change in bug 1289865 as well. > > Cheers, > David > > [0] > https://dxr.mozilla.org/mozilla-central/rev/9baec74b3db1bf005c66ae2f50bafbdb02c3be38/security/manager/ssl/nsNSSComponent.cpp#974 > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1289865 > [2] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa388136(v=vs.85).aspx > > On 09/28/2016 02:18 AM, Johan Corveleyn wrote: >> Hi all, this is my first post to this list. >> >> After asking a question in bugzilla issue 1265113 [1], David Keeler >> asked to post to this list instead of discussing in the issue tracker. >> So here we go: >> >> The feature of trusting custom root CA's when they're in Windows' >> truststore (which is the subject of issue 1265113) works as of FF 49 >> (when config option security.enterprise_roots.enable is set to true). >> However, it's not clear to me why FF only trust one particular >> registry location and not the other. If our Root CA is installed in >> HKLM\SOFTWARE\Microsoft\SystemCertificates\Root, it works, but if it's >> installed in HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root, it >> doesn't. Is that intended? How was it decided which registry keys to >> trust? >> >> 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? >> >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1265113 (Windows >> platform support for trusting enterprise roots) >> > > > ___ > Enterprise mailing list > Enterprise@mozilla.org > https://mail.mozilla.org/listinfo/enterprise > > To unsubscribe from this list, please visit > https://mail.mozilla.org/listinfo/enterprise or send an email to > enterprise-requ...@mozilla.org with a subject of "unsubscribe" ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
Hi, we deploy our own certificates via GPO to our clients. Those are (only) in HKLM\SOFTWARE\Microsoft\EnterpriseCertificates (not in HKLM\SOFTWARE\Microsoft\SystemCertificates). I put a Firefox 49 portable on USB stick to test the same version and profile on different machines and different Windows users. And I always call the same internal https intranet site to see if I can open it without certificate interaction. On a Windows 10 x64 test machine with standard user it works. On my own Windows 7 x86 machine with my user having admin rights (but you work without admin rights unless Windows requests them via UAC), it does not work. Starting Firefox as another user and running it as a standard user, it does not work either. On a second Windows 7 x86 machine from my colleague the same, it does not work. On a third Windows 7 x86 machine it works with its standard user, also with my test standard user, and also if I start Firefox with my admin user. So, it seems to be the machine configuration whether it works or not. But I do not know what it is. All machines are deployed centrally using SCCM. And all Windows 7 machines have received the same updates. I did tests with Process Monitor on all machines, and I can see that Firefox reads both registry paths mentioned above (SystemCertificates and EnterpriseCertificates), I can see nothing that helps me understand why it does work on some machines and not on others. I know that my tests are quite limited to very few machines and users, but I wanted to share that information with you, maybe you can help. But what David writes, that Firefox does right now not use EnterpriseCertificates confuses me, as our certificates are only there, and I checked SystemCertificates location in registry - they are not in there, only in EnterpriseCertificates and it works on some machines. And why does Process Monitor show that Firefox reads EnterpriseCertificates? Cheers, Michael ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
Re: [Mozilla Enterprise] Trusting Root CA's on Windows: which registry keys? (issue 1265113)
Hi Johan, Currently the implementation only uses the CERT_SYSTEM_STORE_LOCAL_MACHINE flag to search for certificates, which as you've discovered corresponds to the registry location HKLM\SOFTWARE\Microsoft\SystemCertificates (see [0]). We're investigating looking in other locations such as CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY (which I think corresponds to HKLM\SOFTWARE\Policy\Microsoft\SystemCertificates) (see [1] and [2]). I'm not certain which flag corresponds to HKLM\SOFTWARE\Microsoft\EnterpriseCertificates, but it might be CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE. If this turns out to be correct, we can probably just make that change in bug 1289865 as well. Cheers, David [0] https://dxr.mozilla.org/mozilla-central/rev/9baec74b3db1bf005c66ae2f50bafbdb02c3be38/security/manager/ssl/nsNSSComponent.cpp#974 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1289865 [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa388136(v=vs.85).aspx On 09/28/2016 02:18 AM, Johan Corveleyn wrote: > Hi all, this is my first post to this list. > > After asking a question in bugzilla issue 1265113 [1], David Keeler > asked to post to this list instead of discussing in the issue tracker. > So here we go: > > The feature of trusting custom root CA's when they're in Windows' > truststore (which is the subject of issue 1265113) works as of FF 49 > (when config option security.enterprise_roots.enable is set to true). > However, it's not clear to me why FF only trust one particular > registry location and not the other. If our Root CA is installed in > HKLM\SOFTWARE\Microsoft\SystemCertificates\Root, it works, but if it's > installed in HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root, it > doesn't. Is that intended? How was it decided which registry keys to > trust? > > 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? > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1265113 (Windows > platform support for trusting enterprise roots) > signature.asc Description: OpenPGP digital signature ___ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
