~ Meghan Stewart | Support Escalation Engineer
Here in product support we get a lot of questions regarding how to tell if computers are protected when Microsoft Security Advisories include updates to the Certificate Trust List (CTL), which is also known as the Disallowed Certificates update. Microsoft updates the CTL for Windows to remove trust of certificates that have the potential to be used in a fraudulent manner to help protect customers. This topic can be a little confusing for administrators who want to make sure that their systems have the updated CTL and has been especially plaguing Configuration Manager and WSUS administrators. When we see a KB number, we automatically assume we can push it out with our management tools, however this is not typically the case with CTLs.
Let’s look at an example of a Security Advisory for an update to the disallowed CTL (3046310) and answer some of the common questions that arise.
Question: What is a Certificate Trust List (CTL)?
Answer: A Certificate Trust List (CTL) is pretty well summed up by this MSDN article: https://msdn.microsoft.com/en-us/library/windows/desktop/aa376545(v=vs.85).aspx. This article states:
“A CryptoAPI CTL is a list of items that has been signed by a trusted entity. The list of items could be anything, such as a list of hashes of certificates, or a list of file names. In most cases, a CTL is a list of hashed certificate contexts. All the items in the list are authenticated and approved by the signing entity. The primary use of CTLs is to verify signed Messages, using the CTL as a source of trusted root certificates.”
Now, as Microsoft loves to do, we have overloaded the term to also include CTL to mean a signed list of Root Certification Authorities that should no longer be trusted, which is why most people internally call this update the Disallowed Certificates update.
Question: How do machines automatically update their CTL?
Answer: We have had the root update program since Windows XP. The way it works is that when VeriSign, Entrust or another Internet CA provider stands up a new PKI hierarchy, someone has to deploy the root certificate to your computers Trusted Root Certification Authority store before things like Internet Explorer actually start trusting certificates issued by that hierarchy. This was accomplished by the root update system. Every week your computer accesses the Windows Update site to see if there is an updated root update CAB file sitting out there. If there is, it downloads the file and adds the new roots to the computers trusted root store.
So as you can see, we had a great story for mass deployment of new root certification authority certificates to Windows clients, however what about when that root or PKI hierarchy gets compromised and should no longer be trusted? For the longest time, the Windows Operating System did not have a way to easily update millions of Windows computers so that they do not trust comprised Root Certification Authorities. We expected our customers to be PKI experts and know where to look and watch for the next compromised root. We then decided that “Heck, we should be looking out for our customers, and when an Internet Root Certification Authority gets compromised, we should help customers by coming up with a way to deploy these compromised roots so that they are no longer trusted”. This is how the Disallowed Certificates (CTL) came about.
Disallowed Certificates basically works on the same premise as the root update program. Once a day it attempts to access the Window Update site and see if the disallowed update cab file has changed. If not then it does nothing. If it has then it downloads the latest version.
The functionality for Disallowed Certificates update came in the following update:
Note that in both cases, if you deny the computer access to Windows Update site then the root update and Disallowed certificate update will constantly try to access the Windows Update site every time there is certificate chaining or revocation checking done. If you want or need to support the root update and disallowed certificate updates within environments where the computers are not allowed to connect to the internet, or you specifically do not allow your clients to access Windows Update via Firewall rules because you use WSUS for patching, we have another option. This option requires the deployment of the following update:
2813430 – An update is available that enables administrators to update trusted and disallowed CTLs in disconnected environments in Windows (https://support.microsoft.com/en-us/kb/2813430/)
This update, along with a configuration document hyperlinked within the KB article, allows for a file server UNC path to be used to host the Root Update and Disallowed certificate updates. The downside to this is that someone has to maintain these files on the file server and make sure that they are up to date constantly.
Question: How do I get Microsoft Security Advisory 3046310 into WSUS or Configuration Manager?
Answer: You don’t import 3046310 unless you need to update Windows Server 2003. Note that a Security Advisory is different from a Security Bulletin (see https://technet.microsoft.com/en-us/security/advisory/).
In short, this Security Advisory is basically a notification that certificates for live.fi were added to the disallowed Certificate Trust List (CTL). This should be automatically updated by the client if they meet the following criteria:
|Windows Vista, Windows Server 2008||
|Windows 7, Windows Server 2008 R2||
|Windows 8, Windows Server 2012||
|Windows 8.1, Windows Server 2012 R2||
The table above summarizes the prerequisite updates. Note that 2813430 lists the file information for Crypt32.dll.mui based on OS. This is the minimum version the file must be in order to update the disallowed CTL automatically in a disconnected environment. Similarly, 2677070 list the minimum version for Crypt32.dll.mui for Internet connected clients. The ability to update CLTs automatically was not built into the OS until Windows 8, and the disconnected client scenario was added in Windows 8.1.
Question: My computers do not have Internet access because I am in a disconnected network. How do I verify that my admin has updated the disallowed CTL?
Answer: In the Security Advisory 3046310 we tell you how to check this. For systems not using the automatic updater of revoked certificates, in the Certificates MMC snap-in, verify that the following certificate has been added to the Untrusted Certificates folder:
|www.live.fi||COMODO RSA Domain Validation Secure Server CA||08 e4 98 72 49 bc 45 07 48 a4 a7 81 33 cb f0 41 a3 51 00 33|
Note For information on how to view certificates with the MMC Snap-in, see the MSDN article How to: View Certificates with the MMC Snap-in.
Question: I am an administrator of a disconnected network. How do I setup my environment to update the disallowed CTL?
Answer: Follow the guide at https://gallery.technet.microsoft.com/Configuring-Trusted-Roots-281be43a. It is important to note that this changes the behavior of the root update program as well. For instance, update 931125 is a general KB number for updating Root Certificates. This KB is reused each time the Root Update Program needs to deploy a new set of Root Certification Authorities. This update is used for adding new internet Root CAs automatically to Microsoft operating systems.
Special thanks to Rob Greene from our AskDSBlog for his extensive help with this article.
Meghan Stewart | Support Escalation Engineer | Microsoft GBS Management and Security Division
System Center All Up: http://blogs.technet.com/b/systemcenter/
Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
Data Protection Manager Team blog: http://blogs.technet.com/dpm/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
Microsoft Intune: http://blogs.technet.com/b/microsoftintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The RMS blog: http://blogs.technet.com/b/rms/
App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Surface Team blog: http://blogs.technet.com/b/surface/
The Application Proxy blog: http://blogs.technet.com/b/applicationproxyblog/
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
System Center 2012 Configuration Manager System Center 2012 R2 Configuration Manager ConfigMgr 2012 R2