Distributing SSL Certificates to All Browsers in an Active Directory Environment

Writing a comprehensive tutorial on this might not be suitable for a Q/A site, but here's some advices. Also, this is from the perspective of managing the installation for a single client within their own intranet. For e.g. SaaS installations it's better to use global FQDNs & PKI.

As a software vendor, you SHOULD NOT:

• implement own PKI and push it across your clients, as it enables you to issue certificates for arbitrary hosnames, giving you a God mode over their entire infrastucture.
• use the same self-signed certificates for multiple clients with hard-coded private keys, as they can easily be extracted and used against other clients.
• combine these mistakes, as it would give every client a God mode over all other clients.

Create your own PKI instead of trusting individual certificates

This is mainly a security consideration, but it's also easier to maintain, as you mention having multiple installations at multiple intranet sites.

• From the security perspective, you don't want every application to be able to sign certificates for arbitrary hostnames. Therefore, the individual self-signed certificates should not all be trusted certificate authorities.

• From the maintenance perspective, you don't want to update your policies and wait for them to propagate every time you need to add a new web application.

• Although preferable, sometimes it's not possible (or wanted) to get certificates from external CAs. The intranet sites may not have globally valid FQDNs, making domain verification impossible, or their connectivity to the Internet is restricted, making it harder to maintain certificate renewals.

In this case, the recommended alternative is to create an own certificate authority for the client (do not push your PKI to multiple clients as a software vendor) and sign all the application certificates with it. This way you only need to add a single certificate to the trusted certificate authorities using GP, and every application certificate signed with it will be trusted.

If you only need a tiny certificate authority for this purpose alone, you might go with OpenSSL:

1. Generate the root key (rootCA.key) and the root certificate (rootCA.crt).

   openssl genrsa -aes256 -out rootCA.key 4096
   openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 7300 -out rootCA.crt
   

   Keep the key safe, recommendably offline, and distribute the certificate using Group Policy.
   
   

2. Create a certificate for your application starting with a key and a certificate signing request (.csr).

   openssl genrsa -out app.example.com.key 2048
   
   openssl req -new -sha256 \
       -key app.example.com.key \
       -subj "/C=US/ST=CA/O=My Application/CN=app.example.com" \
       -out app.example.com.csr
   

3. Create an application certificate signed with your CA:

   openssl x509 -req -in app.example.com.csr \
       -CA rootCA.crt -CAkey rootCA.key -CAcreateserial \
       -days 730 -sha256 \
       -out app.example.com.crt
   

4. Use the app.example.com.key and app.example.com.crt in your application.

For heavier solutions there's Active Directory Certificate Services (AD CS), but that really needs some planning, and your skillset might not be adequate for that, yet.

Use a GPO instead of editing the Default Domain Policy

As a side note, I wouldn't edit the Default Domain Policy for this, but create a new Group Policy Object (GPO), instead. It makes a lot easier to limit the scope of the changes, e.g. making it possible to apply them to a group of test computers, first. It also makes it easier to revert changes, if something goes wrong.

Firefox has own cert store – possible to use certificates from Windows

Mozillaʼs CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is used in Mozilla products such as the Firefox browser, and is also used by other companies in a variety of products.

This means certificates added to Windows certificate store doesn't apply to Firefox, by default. For easier maintenance it might be a good idea to make Firefox use the certificate authories installed on Windows. Using own certificate store is a good idea for protecting privacy of individuals using Firefox, but not that suitable for Windows AD environments. Luckily, there's a way to disable it.

Assuming the installation directory of Firefox is C:\Program Files\Mozilla Firefox\, you need to add two ANSI encoded configuration files:

1. C:\Program Files\Mozilla Firefox\defaults\pref\local-settings.js having

   pref("general.config.obscure_value", 0); 
   pref("general.config.filename", "ownsettings.cfg");
   

   This simply refers to the next file, having the actual configuration parameters.

2. C:\Program Files\Mozilla Firefox\ownsettings.cfg having

   //
   lockPref("security.enterprise_roots.enabled", true);
   

   It's important the actual settings starts from the second line after //!

These files can be distributed on the same GPO using:

Computer Configuration \ Preferences \ Windows Settings \ Files