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
Quoting Bruno Marsal <[email protected]>:
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"
