Microsoft removed root CA updates from WSUS in January 2013. I now have some fresh installs of Windows Server 2012 that have an insufficient set of root CAs (basically just Microsoft's own CAs). This means that whenever our application calls an https web service it will fail unless I specifically install the root CA.

Since our application uses SSL termination at a load balancer I don't need to worry about the 16KB SChannel limitation that prompted Microsoft to remove these updates. I'd like to find a resource to install and update standard root CAs. Does anyone know of such a resource?

Here is an image of the default root CAs in WS2012. default WS2012 root CAs

  • 4
    Wait, really? They aren't providing a base set of trusted CAs with fresh installs anymore? That seems.. misguided. Sep 26, 2013 at 16:23
  • 3
    I was reading through that article, and it mostly applies to XP/2003 and below right? Vista/2808 and above use a different method for automatically updating their roots. The method can supposedly be control ed by a group policies. I would guess it is disabled on 2012, but can be enabled? - See technet.microsoft.com/en-us/library/cc733922(v=ws.10).aspx and technet.microsoft.com/en-us/library/…
    – Zoredache
    Sep 26, 2013 at 16:32
  • @Zoredache Good call on the GPO setting. Looks like that's still there in WS2012. If you write that up as an answer I'll accept it.
    – pdubs
    Sep 26, 2013 at 17:03
  • Go ahead and self-answer if that works for you. I don't really like to provide an answer when I really only have a vague idea, and no good way to test/replicate.
    – Zoredache
    Sep 26, 2013 at 17:41

3 Answers 3


It seems that this is due to the oddball GPO that my company uses.

As outlined here the GPO setting Computer Configuration\Administrative Templates\System\Internet Communication Management\Turn off Automatic Root Certificates Update was Enabled, meaning that the OS wouldn't pull root CAs from Microsoft. Setting this to Disabled fixed the issue.


We found that the root CAs were out of date on some of our Windows 2012 R2 servers.

Having investigated this is appears Microsoft released a patch to provide the ability for "Controlling the Update Root Certificates Feature to Prevent the Flow of Information to and from the Internet" (KB article).

This patch introduces new registry keys for stopping Windows Update from updating the root CAs along with other functionality.

Setting the following registry Key to 0 fixes the problem. The certificates begin installing immediately after the change.


Whilst I can see that Admins may want to control their machines from updating without their consent, I think not allowing root CAs to update is an edge case which is likely to cause more problems that it fixes and I do not yet know why the registry key has been set on our servers.

There is discussion of these registry keys and other things you can do on Windows 2012 R2 servers here


If no-one else will say it, I will. Microsoft screwed up years ago and published an update to the trusted root CAs that broken any machine lucky enough to get said update prior to Microsoft pulling the update. To this day, I still deal with this problem.

Because I understand the security implications, I am not providing direct links to these issues. Instead, this is what one searches for in Google to find the related information:

Update KB3004394 breaks Root Certificate in Windows 7/ Windows Server 2008 R2

Microsoft releases 'Silver Bullet' patch KB 3024777 to eliminate KB 3004394

And the one I experienced and to this day causes countless issues:

SSL/TLS communication problems after you install KB 931125

This package installed more than 330 Third-party Root Certication Authorities. Currently, the maximum size of the trusted certificate authorities list that the Schannel security package supports is 16 kilobytes (KB). Having a large amount of Third-party Root Certication Authorities will go over the 16k limit, and you will experience TLS/SSL communication problems.

Another reason is because Microsoft has distrusted a number of root CAs over the years. Lazy admins will simply disable this feature for their Intranet servers and never resolve the root problem -- re-signing everything no longer trusted.

Anyway, simple answer is to use a different code signing certificate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.