Update 18.08.2010: added workaround at the bottom of the post.


Many Windows customers have received an error message in Application log when they try to update third-party root list. Prior to issue description I want to explain about the subject. Third-party root list is the list of third-party (non-Microsoft) root certification authorities (hereinafter CA) that participate in Microsoft Root Certificate Program. All these CAs are trusted by Windows and applications. About Program participants you can read the following article: Windows root certificate program members. You can add your own CAs to a trusted root list, but you cannot remove predefined CAs from computer. Therefore if new program member appears or retires, Microsoft issues update that will add or remove corresponding certificate to (from) Trusted Root CAs certificate container. Internally update contains a Certificate Trust List (CTL). Let's see the error message:

Log Name:      Application
Source:        Microsoft-Windows-CAPI2
Date:          2010.07.28. 4:28:10
Event ID:      4107
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      ComputerName
Description:
Failed extract of third-party root list from auto update cab at: <http://www.download.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.
.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-CAPI2" Guid="{5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}" EventSourceName="Microsoft-Windows-CAPI2" />
    <EventID Qualifiers="0">4107</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8080000000000000</Keywords>
    <TimeCreated SystemTime="2010-07-28T01:28:10.499942000Z" />
    <EventRecordID>5113</EventRecordID>
    <Correlation ActivityID="{00000100-0000-0000-C461-9AF48816CB01}" />
    <Execution ProcessID="952" ThreadID="1428" />
    <Channel>Application</Channel>
    <Computer>ComputerName</Computer>
    <Security />
  </System>
  <EventData>
    <Data>http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab</Data>
    <Data>A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.
</Data>
  </EventData>
</Event>

Download 'authrootstl.cab' file and open extracted file. You'll get the message: This certificate trust list is not valid. Certificate that signed the list is not valid.

Invalid CTL

What's happened with the signing certificate? Click 'View Signature' and you'll get detailed message about the error: This certificate is not valid for the requested usage.

Invalid CTL signature

 

Right now, we need to find a source of the problem. Click 'View Certificate', switch to Details tab and scroll down to Enhanced Key Usage extension and check the value. Extension contains only single EKU: Root List Signer (1.3.6.1.4.1.311.10.3.9).

Invalid EKU

However you MUST have at least 'Microsoft Trust List Signing' (1.3.6.1.4.1.311.10.3.1) EKU in order to sign CTL. Actually you can sign a CTL without this EKU, but this will cause that applications will ignore your signature and will not trust your CTL.

But hey, the eventlog tell us that 'A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file'!!!

Actually this is not true, because signing certificate is valid from 09 April 2010 to 09 July 2011. Current date is 28 July 2010, so the certificate is within it's validity period. In addition, the signature is timestamped. Therefore the signature will be considered as a valid after signing (or time stamp) certificate expiration.

Experienced users may check my thought by using CAPI2 eventlog. Use Method 1 from the following article to enable CAPI2 logging: http://support.microsoft.com/kb/976235. And open again extracted CTL. After that check the most recent event with ID=11. You will see that certificate chaining engine will check the certificate against the following EKU:

-ExtendedKeyUsage
     -Usage
          [ oid] 1.3.6.1.4.1.311.10.3.1
          [ name] Microsoft Trust List Signing

As you see in the last screenshot, required EKU is missing in the certificate and automatically raises the following text in the event:

-ErrorStatus
     [ value] 10
     [ CERT_TRUST_IS_NOT_VALID_FOR_USAGE] true

What you should to do when you see mentioned error in Application eventlog? There is unofficial workaround:

Backup and delete the content of the following folders:

C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content
C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData

Backup and delete the certificates listed under "Certificates" key:

HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\AuthRoot\Certificates

and restart the system.


Share this article:

Comments:

Baiduo

Sorry for this message, but if I add extended key usage including 1.3.6.1.4.1.311.10.3.9 and 1.3.6.1.4.1.311.10.3.1 to my self-signed certificate, can I sign a CTL successfully? 

I have tried several times but failed, when I execute "Get-AuthenticodeSignature" it shows just "the certificate is not valid for the requested usage". Maybe I can't use a self-signed certificate to sign the list? Can you tell me what should I check or do? Thank you!


Post your comment:

Please, solve this little equation and enter result below. Captcha