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 Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies/Trusted Root Certification Authorities - Rebooted the client and then looked for the location of the certificate After the client rebooted and updated the group policy, this test certificate could be found at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates and can be listed on the client using "certutil -viewstore -grouppolicy root". Also using CertOpenStore using PowerShell [1] with flag CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY (0x80000) this test CA is revealed. To find out at which location the "Trusted Root CAs" are located when distributing them using "2. AD Certificate Services", did the following (typical steps for IT admins): - Set up a new server named "pki1" and joined it to the domain - Installed the "Active Directory Certificate Services" 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 (0x90000) 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:[email protected]] On Behalf Of Johan Corveleyn Sent: Saturday, October 1, 2016 10:10 AM To: David Keeler <[email protected]> Cc: [email protected] 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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/enterprise > > To unsubscribe from this list, please visit > https://mail.mozilla.org/listinfo/enterprise or send an email to > [email protected] with a subject of "unsubscribe" _______________________________________________ Enterprise mailing list [email protected] https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to [email protected] with a subject of "unsubscribe" _______________________________________________ Enterprise mailing list [email protected] https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to [email protected] with a subject of "unsubscribe"
