Why are many admins using 'Turn off Automatic Root Certificates Update' Policy?

Question

My company distributes a Windows Installer for a Server based product. As per best practices it is signed using a certificate. In line with Microsoft's advice we use a GlobalSign code signing certificate, which Microsoft claims is recognised by default by all Windows Server versions.

Now, this all works well unless a server has been configured with Group Policy: Computer Configuration / Administrative Templates / System / Internet Communication Management / Internet Communication settings / Turn off Automatic Root Certificate Update as Enabled.

We found that one of our early beta testers was running with this configuration resulting in the following error during installation

A file that is required cannot be installed because the cabinet file [long path to cab file] has an invalid digital signature. This may indicate that the cabinet file is corrupt.

We wrote this off as an oddity, after all no-one was able to explain why the system was configured like this. However, now that the software is available for general use, it appears that a double digit (percentage) of our customers are configured with this setting and no-one knows why. Many are reluctant to change the setting.

We have written a KB article for our customers, but we really don't want the problem to happen at all as we actually care about the customer experience.

Some things we have noticed while investigating this:

1. A fresh Windows Server installation does not show the Globalsign cert in the list of trusted root authorities.
2. With Windows Server not connected to the internet, installing our software works fine. At the end of the installation the Globalsign cert is present (not imported by us). In the background Windows appears to install it transparently on first use.

So, here is my question again. Why is it so common to disable updating of root certificates? What are the potential side effects of enabling updates again? I want to make sure we can provide our customers with the appropriate guidance.

Answer 1

In late 2012 / early 2013 there was an issue with automatic root certificate updates. The interim fix was to disable the automatic updates, so partly this issue is historical.

The other cause is the Trusted Root Certificate program and Root Certificate Distribution, which (to paraphrase Microsoft)...

Root certificates are updated on Windows automatically. When a [system] encounters a new root certificate, the Windows certificate chain verification software checks the appropriate Microsoft Update location for the root certificate.

So far, so good but then...

If it finds it, it downloads it to the system. To the user, the experience is seamless. The user does not see any security dialog boxes or warnings. The download happens automatically, behind the scenes.

When this happens it can appear that certs are being automagically added to the Root store. All this makes some sysadmins nervous as you can't remove a 'bad' CA from the certificate management tools because they're not there to remove...

Actually there are ways to make windows download the full list so they can edit it as they wish but it's common to just block the updates. A great number of sysadmins don't understand encryption or security (generally) so they follow received wisdom (correct or otherwise) without question and they don't like making changes to things involving security that they don't fully understand believing it to be some black art.

Answer 2

The Automatic Root Certificates Update component is designed to automatically check the list of trusted authorities on the Microsoft Windows Update Web site. Specifically, there is a list of trusted root certification authorities (CAs) stored on the local computer. When an application is presented with a certificate issued by a CA, it will check the local copy of the trusted root CA list. If the certificate is not in the list, the Automatic Root Certificates Update component will contact the Microsoft Windows Update Web site to see if an update is available. If the CA has been added to the Microsoft list of trusted CAs, its certificate will automatically be added to the trusted certificate store on the computer.

Why is it so common to disable updating of root certificates?

The short answer is probably that it's about control. If you want to control what root CAs are trusted (rather than using this feature and letting Microsoft do it for you), it's easiest and most secure to come up with a list of root CAs you want to trust, distribute them to your domain computers, and then lock that list. Since changes to the list of root CAs an organization wants to trust would be relatively rare, it makes a certain amount of sense that an administrator would want to review and approve any changes rather than allowing an automatic update.

To be completely frank, if no one knows why this setting is enabled in a given environment, that means that it shouldn't be set.

What are the potential side effects of enabling updates again?

Domain computers would be allowed to check against the list of trusted CAs on the Microsoft Windows Update Site, and potentially add new certificates into their trusted certificate store.

If this is unacceptable to your clients/customers, certificates can be distributed by GPO, and they would need to include your certificate in whatever distribution method they currently use for trusted certificates.

Or you could always suggest temporarily disabling this particular policy, to allow installation of your product.

Answer 3

My reason for disabling the certif.service is as follows:

I have many systems without internet connection. Also in most cases they lack display/kb/mouse because of the fact they are virtual machines on a big DatastoreServer. So in all cases when they need maintenance/modification I use Windows RDP to get to them. If you connect to a machine via RDP, Windows first checks certificate updates online. If your server/client doesn't have internet, it hangs for 10-20 seconds before continuing connection.

I make a lot of RDP connections each day. I save hours on not staring at the message: "securing remote connection":) +1 for disabling certif.service!

Answer 4

I would not agree that it is common to disable this. A better way to phrase it would be to ask why someone would disable it. And a better solution for your problem would be for the installer to check for the root/intermediate CA certificates and install them if not present.

The Trusted Root CA program is essential. A TON of applications would just not work as expected if it were turned off widely. Sure, there may be some organizations that disable this feature, but that's really up to the organizations, based on their requirements. It is a flawed assumption that any application that requires an external dependency (root certificate) would always work without testing it. Both developers of applications and organizations that disable this feature own the responsibility of ensuring the external dependency (root certificate) is present. That means if an organization disables this, they know to expect this issue (or will soon learn about it).

It's also worth noting that one useful purpose of the Trusted Root CA program mechanism (dynamic installation of root CA certificates) is that it isn't practical to install all or even most of the well-known/trusted root CA certificates. Some components in Windows break if there are too many certificates installed, so the only feasible practice is to install only the certificates that are needed, when they are needed.

http://blogs.technet.com/b/windowsserver/archive/2013/01/12/fix-available-for-root-certificate-update-issue-on-windows-server.aspx

"The issue is this: the SChannel security package used to send trusted certificates to clients has a limit of 16KB. Therefore, having too many certificates in the store can prevent TLS servers from sending needed certificate information; they start sending but have to stop when they reach 16KB. If clients don’t have the right certificate information, they cannot use services requiring TLS for authentication. Because the root certificate update package available in KB 931125 manually adds a large number of certificates to the store, applying it to servers results in the store exceeding the 16KB limit and the potential for failed TLS authentication. "

Answer 5

I know this is an older thread; however, I would like to submit an alternative solution. Use a certificate authority (ROOT CA) other than the one you are using. In other words, switch your signing certificate to one that has a much older, approved root CA.

DIGICert offers this when requesting a cert. While this might not be your default root CA within your DIGICert account, it is an option available when submitting the CSR to them. BTW, I do not work for DIGICert nor have I any gain by recommending them.. I simply feel this pain and have spent way too many hours on saving $1000 US on a cheap cert when I could have bought a more expensive cert and spent much less time dealing with the support issues. This is simply an example. There are other certificate providers offering the same thing.

99% Compatibility DigiCert Root Certificates are among the most widely-trusted authority certificates in the world. As such, they are automatically recognized by all common web browsers, mobile devices, and mail clients.

Caveat - if you select the correct root CA when making the CSR.