Nothing matches that yet. Tell us what you were looking for and it goes on the list.
Windows Application Log · Event 4107
Windows downloads a signed list of trusted certificate authorities from Microsoft in the background. This event says that refresh failed. Nothing breaks immediately, which is why it gets ignored — but the machine's trust list, including which roots Microsoft has distrusted, is now frozen.
Also written as CAPI2 4107authrootstl.cab errorEvent ID 4107 CAPI2
Windows keeps a list of the companies it trusts to vouch for secure websites, and it refreshes that list from Microsoft periodically. This error means one of those refreshes failed. It does not stop you browsing and it is often just a temporary network hiccup. If it repeats for weeks, something is blocking the update.
The usual cause on a healthy network is a stale cached copy under CryptnetUrlCache signed by a certificate that has since expired — `certutil -urlcache * delete` clears it. The usual cause on a locked-down network is that ctldl.windowsupdate.com is not reachable, which is normal for isolated environments and should be handled deliberately with an offline CTL refresh rather than left failing.
Sanitised. Addresses come from the RFC 5737 documentation ranges.
Log Name: Application
Source: Microsoft-Windows-CAPI2
Event ID: 4107
Level: Error
Computer: DESKTOP-WKS042
Failed extract of third-party root list from auto update cab at:
<http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab>
with error: A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.Everything else in the log line is context.
authrootstl.cabThe trusted root list. Failing to update it means new certificate authorities are not trusted and removed ones stay trusted. disallowedcertstl.cabThe untrusted list. This is the more serious one — it is how Microsoft revokes trust in a compromised root across the whole ecosystem. pinrulesstl.cabCertificate pinning rules. Least consequential of the three. A required certificate is not within its validity periodA cached copy of the list is signed by an expired certificate. Clear the cache; the machine is not actually broken. The server name or address could not be resolvedDNS cannot reach ctldl.windowsupdate.com. Expected on isolated networks, unexpected on connected ones. A connection with the server could not be establishedA proxy or firewall is blocking the fetch. The endpoint is plain HTTP by design because the payload is itself signed. Most of the time it is one of these.
What gives it awayThe disallowed-certificate list specifically failing while other fetches succeed, or the automatic root update policy having been disabled in the registry around the same time (Event 4657 if registry auditing is on).
ATT&CK T1553.004What gives it awayCompare the machine's root store against a known-good build: `Get-ChildItem Cert:\LocalMachine\Root` and look for authorities that no other machine in the estate has.
ATT&CK T1553.004Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Microsoft-Windows-CAPI2'; Id=4107,4110} -MaxEvents 30 | Format-List TimeCreated, Id, Messagecertutil -verifyctl AuthRootGet-ChildItem Cert:\LocalMachine\Root | Select-Object Subject, NotAfter, Thumbprint | Sort-Object SubjectGet-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot' -ErrorAction SilentlyContinueRun `certutil -urlcache * delete` from an elevated command prompt, then `certutil -verifyctl AuthRoot` to force a fresh fetch. That clears the cached, expired copy of the list that causes the great majority of these errors. If it still fails, the machine cannot reach ctldl.windowsupdate.com and the problem is network access, not certificates.
Not immediately. It means one background refresh of Windows' trusted root list failed. The concern is cumulative: that list is also how Microsoft withdraws trust from certificate authorities that have been compromised, so a machine that has failed to update it for months keeps trusting things the rest of the world no longer does. Fix it, do not just silence it.
Because the file itself is a signed cabinet, and Windows verifies that signature before using anything inside it. Fetching it over HTTPS would add nothing, and it avoids a bootstrapping problem — you cannot rely on certificate validation to fetch the list that certificate validation depends on. It also means TLS-inspecting proxies should leave ctldl.windowsupdate.com alone, since intercepting it breaks the signature check.
Yes, and it will repeat indefinitely. A machine with no route to Microsoft's update endpoints cannot refresh the list. The right response is not to ignore it but to refresh the trust list offline: run `certutil -generateSSTFromWU roots.sst` on a connected machine and import the result on the isolated one, on whatever schedule your environment can support.
Last reviewed 7 September 2026