Issues with CAPI2 on Windows 2008 R2 Event ID 11 and 41

Friday, May 18, 2012 1:06 PM

Hi,

Windows 2008r2 DB server is without any Internet connection and not in AD by design. Windows updates have installed on the server from local WSUS.
I manualy installed http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab and used

>certutil -urlcache * delete

from http://support.microsoft.com/default.aspx?scid=kb;en-us;2328240

>sfc /scannow

Verification 100% complete.
Windows Resource Protection did not find any integrity violations.

I have not rebooted the server.

Events ID 11 47 are flooding logs. Any solution?

Event ID.
+ System 
  - Provider 
   [ Name]  Microsoft-Windows-CAPI2 
   [ Guid]  {5bbca4a8-b209-48dc-a8c7-b23d3e5216fb} 
   EventID 11 
   Version 0 
   Level 2 
   Task 11 
   Opcode 2 
   Keywords 0x4000000000000003 
  - TimeCreated 
   [ SystemTime]  2012-05-18T11:36:24.424239800Z 
   EventRecordID 9205 
   Correlation 
  - Execution 
   [ ProcessID]  1944 
   [ ThreadID]  440 
   Channel Microsoft-Windows-CAPI2/Operational 
   Computer MyServer 
  - Security 
   [ UserID]  S-1-5-21-2061264036-1160607325-1859214576-1008 
- UserData 
  - CertGetCertificateChain 
  - Certificate 
   [ fileRef]  564E01066387F26C912010D06BD78D3CF1E845AB.cer 
   [ subjectName]  Microsoft Corporation 
   ValidationTime 2006-08-28T12:19:22Z 
  - AdditionalStore 
  - Certificate 
   [ fileRef]  564E01066387F26C912010D06BD78D3CF1E845AB.cer 
   [ subjectName]  Microsoft Corporation 
  - Certificate 
   [ fileRef]  D07EA64088A80085F01BD40AA4EAD82F470482A6.cer 
   [ subjectName]  Microsoft Code Signing PCA 
  - Certificate 
   [ fileRef]  A43489159A520F0D93D032CCAF37E7FE20A8B419.cer 
   [ subjectName]  Microsoft Root Authority 
  - Certificate 
   [ fileRef]  817E78267300CB0FE5D631357851DB366123A690.cer 
   [ subjectName]  VeriSign Time Stamping Services Signer 
  - Certificate 
   [ fileRef]  F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D.cer 
   [ subjectName]  VeriSign Time Stamping Services CA 
  - ExtendedKeyUsage 
  - Usage 
   [ oid]  1.3.6.1.5.5.7.3.3 
   [ name]  Code Signing 
  - Flags 
   [ value]  C8000005 
   [ CERT_CHAIN_CACHE_END_CERT]  true 
   [ CERT_CHAIN_CACHE_ONLY_URL_RETRIEVAL]  true 
   [ CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT]  true 
   [ CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY]  true 
   [ CERT_CHAIN_REVOCATION_ACCUMULATIVE_TIMEOUT]  true 
  - ChainEngineInfo 
   [ context]  user 
  - CertificateChain 
   [ chainRef]  {7E5A0219-5CA0-43BF-827E-AA3A75DB75FF} 
  - TrustStatus 
  - ErrorStatus 
   [ value]  1000040 
   [ CERT_TRUST_REVOCATION_STATUS_UNKNOWN]  true 
   [ CERT_TRUST_IS_OFFLINE_REVOCATION]  true 
  - InfoStatus 
   [ value]  100 
   [ CERT_TRUST_HAS_PREFERRED_ISSUER]  true 
  - ChainElement 
  - Certificate 
   [ fileRef]  564E01066387F26C912010D06BD78D3CF1E845AB.cer 
   [ subjectName]  Microsoft Corporation 
  - SignatureAlgorithm 
   [ oid]  1.2.840.113549.1.1.5 
   [ hashName]  SHA1 
   [ publicKeyName]  RSA 
  - PublicKeyAlgorithm 
   [ oid]  1.2.840.113549.1.1.1 
   [ publicKeyName]  RSA 
   [ publicKeyLength]  2048 
  - TrustStatus 
  - ErrorStatus 
   [ value]  1000040 
   [ CERT_TRUST_REVOCATION_STATUS_UNKNOWN]  true 
   [ CERT_TRUST_IS_OFFLINE_REVOCATION]  true 
  - InfoStatus 
   [ value]  101 
   [ CERT_TRUST_HAS_EXACT_MATCH_ISSUER]  true 
   [ CERT_TRUST_HAS_PREFERRED_ISSUER]  true 
  - ApplicationUsage 
  - Usage 
   [ oid]  1.3.6.1.5.5.7.3.3 
   [ name]  Code Signing 
   IssuanceUsage 
  - RevocationInfo 
  - RevocationResult The revocation function was unable to check revocation because the revocation server was offline. 
   [ value]  80092013 
  - ChainElement 
  - Certificate 
   [ fileRef]  D07EA64088A80085F01BD40AA4EAD82F470482A6.cer 
   [ subjectName]  Microsoft Code Signing PCA 
  - SignatureAlgorithm 
   [ oid]  1.3.14.3.2.29 
   [ hashName]  SHA1 
   [ publicKeyName]  RSA 
  - PublicKeyAlgorithm 
   [ oid]  1.2.840.113549.1.1.1 
   [ publicKeyName]  RSA 
   [ publicKeyLength]  2048 
  - TrustStatus 
  - ErrorStatus 
   [ value]  40 
   [ CERT_TRUST_REVOCATION_STATUS_UNKNOWN]  true 
  - InfoStatus 
   [ value]  101 
   [ CERT_TRUST_HAS_EXACT_MATCH_ISSUER]  true 
   [ CERT_TRUST_HAS_PREFERRED_ISSUER]  true 
  - ApplicationUsage 
  - Usage 
   [ oid]  1.3.6.1.5.5.7.3.3 
   [ name]  Code Signing 
   IssuanceUsage 
  - RevocationInfo 
  - RevocationResult The revocation function was unable to check revocation for the certificate. 
   [ value]  80092012 
  - ChainElement 
  - Certificate 
   [ fileRef]  A43489159A520F0D93D032CCAF37E7FE20A8B419.cer 
   [ subjectName]  Microsoft Root Authority 
  - SignatureAlgorithm 
   [ oid]  1.2.840.113549.1.1.4 
   [ hashName]  MD5 
   [ publicKeyName]  RSA 
  - PublicKeyAlgorithm 
   [ oid]  1.2.840.113549.1.1.1 
   [ publicKeyName]  RSA 
   [ publicKeyLength]  2048 
  - TrustStatus 
  - ErrorStatus 
   [ value]  0 
  - InfoStatus 
   [ value]  109 
   [ CERT_TRUST_HAS_EXACT_MATCH_ISSUER]  true 
   [ CERT_TRUST_IS_SELF_SIGNED]  true 
   [ CERT_TRUST_HAS_PREFERRED_ISSUER]  true 
  - ApplicationUsage 
   [ any]  true 
  - IssuanceUsage 
   [ any]  true 
  - EventAuxInfo 
   [ ProcessName]  fdhost.exe 
  - CorrelationAuxInfo 
   [ TaskId]  {9807570F-D658-44C3-8A2B-07212E12E0D6} 
   [ SeqNumber]  5 
  - Result The revocation function was unable to check revocation because the revocation server was offline. 
   [ value]  80092013 

+ System 
  - Provider 
   [ Name]  Microsoft-Windows-CAPI2 
   [ Guid]  {5bbca4a8-b209-48dc-a8c7-b23d3e5216fb} 
   EventID 41 
   Version 0 
   Level 2 
   Task 41 
   Opcode 2 
   Keywords 0x4000000000000005 
  - TimeCreated 
   [ SystemTime]  2012-05-18T11:36:24.423239800Z 
   EventRecordID 9204 
   Correlation 
  - Execution 
   [ ProcessID]  1944 
   [ ThreadID]  440 
   Channel Microsoft-Windows-CAPI2/Operational 
   Computer MyServer 
  - Security 
   [ UserID]  S-1-5-21-2061264036-1160607325-1859214576-1008 
- UserData 
  - CertVerifyRevocation 
  - Certificate 
   [ fileRef]  564E01066387F26C912010D06BD78D3CF1E845AB.cer 
   [ subjectName]  Microsoft Corporation 
  - IssuerCertificate 
   [ fileRef]  D07EA64088A80085F01BD40AA4EAD82F470482A6.cer 
   [ subjectName]  Microsoft Code Signing PCA 
  - Flags 
   [ value]  6 
   [ CERT_VERIFY_CACHE_ONLY_BASED_REVOCATION]  true 
   [ CERT_VERIFY_REV_ACCUMULATIVE_TIMEOUT_FLAG]  true 
  - AdditionalParameters 
   [ timeToUse]  2006-08-28T12:19:22Z 
   [ currentTime]  2012-05-18T11:36:24.422Z 
   [ urlRetrievalTimeout]  PT20S 
   [ cacheResyncTime]  2012-05-11T09:15:49.137Z 
  - RevocationStatus 
   [ index]  0 
   [ error]  80092013 
   [ reason]  0 
  - EventAuxInfo 
   [ ProcessName]  fdhost.exe 
  - CorrelationAuxInfo 
   [ TaskId]  {9807570F-D658-44C3-8A2B-07212E12E0D6} 
   [ SeqNumber]  4 
  - Result The revocation function was unable to check revocation because the revocation server was offline. 
   [ value]  80092013

Edited by Vadims Zenins Wednesday, May 23, 2012 11:04 AM

All Replies

Friday, May 18, 2012 1:28 PM

0

Since CA server hasn't internet connection, you can ignore this error message.
My weblog: http://en-us.sysadmins.lv
PowerShell PKI Module: http://pspki.codeplex.com
Windows PKI reference: on TechNet wiki
- Reply
- Quote
Monday, May 21, 2012 7:59 AM

Moderator

0

Hi,

The issues occurs in offliene OCSP scenrairo when CertOpenServerOcspResponse stamps EarliestOnlineTime on TVO cache and consequently is EarliestOnlineTime constantly pushed out into the future.

The problem has been fixed in:

You cannot use a certificate-based logon method to log on to an NPS server that is running Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;2666300

Hope this helps!

Best Regards
Elytis Cheng
Elytis Cheng

TechNet Community Support
- Reply
- Quote
Wednesday, May 23, 2012 10:15 AM

0

Since CA server hasn't internet connection, you can ignore this error message.
No, we cannot ignore events flooding on production server.
- Reply
- Quote
Wednesday, May 23, 2012 10:59 AM

0

Why? It is expected behavior in your scenario. As a workaround you can download (by using external means) all required files (CRT/CRL) and manually install them on server. Note that you may need to update CRLs on a regular basis.
My weblog: http://en-us.sysadmins.lv
PowerShell PKI Module: http://pspki.codeplex.com
Windows PKI reference: on TechNet wiki
- Reply
- Quote
Wednesday, May 23, 2012 11:06 AM

0
As a workaround you can download (by using external means) all required files (CRT/CRL) and manually install them on server.
```
I manualy installed http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
```
The issue is flooding events report system as well.
- Reply
- Quote
Wednesday, May 23, 2012 11:09 AM

0

It is expected behavior in your scenario.

We had 6 months without the issue an all DB servers.
- Reply
- Quote
Wednesday, May 23, 2012 11:39 AM

0

Microsoft CTL PCA issues CRLs each 4 months. Therefore once you have existing CRL installed you may face no errors up to 4 months. Once cached CRL is expired and new CRL cannot be retrieved (as in your scenario) an error message is logged in CAPI2 eventlog. This is not security critical error and can be ignored. Or you must manually install CRLs locally.
My weblog: http://en-us.sysadmins.lv
PowerShell PKI Module: http://pspki.codeplex.com
Windows PKI reference: on TechNet wiki
- Reply
- Quote
Wednesday, May 23, 2012 11:46 AM

0

Or you must manually install CRLs locally.

Vadim, I have manually installed the www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab on the server without reboot, but it doesn't fix the issue.

I accept manual certificate update on production DB if Microsoft cannot do certificate updates trough WSUS. Microsoft takes care about administator's jobs. :)
- Reply
- Quote
Wednesday, May 23, 2012 11:55 AM

0

authrootstl.cab is digitally signed. Error indicates that the system cannot verify digital signature for revocation. In order to enable this, you need to install all CRLs in the signing certificate's chain (which are issued by Microsoft CTL PCA and root CA). Only then an error disappears.
My weblog: http://en-us.sysadmins.lv
PowerShell PKI Module: http://pspki.codeplex.com
Windows PKI reference: on TechNet wiki
- Reply
- Quote
Wednesday, May 23, 2012 12:08 PM

0

authrootstl.cab is digitally signed. Error indicates that the system cannot verify digital signature for revocation. In order to enable this, you need to install all CRLs in the signing certificate's chain (which are issued by Microsoft CTL PCA and root CA). Only then an error disappears.
Where could I download them?
- Reply
- Quote
Wednesday, May 23, 2012 2:22 PM

0
Hi,

The issues occurs in offliene OCSP scenrairo when CertOpenServerOcspResponse stamps EarliestOnlineTime on TVO cache and consequently is EarliestOnlineTime constantly pushed out into the future.

The problem has been fixed in:

You cannot use a certificate-based logon method to log on to an NPS server that is running Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;2666300

Hope this helps!
Best Regards
Elytis Cheng

The fix Windows6.1-KB2666300-x64.msu doesn't help. Event log is flooding by CAPI2 events 11, 20, 30, 41, 53, 81.
- Edited by Vadims Zenins Wednesday, May 23, 2012 3:06 PM
- Reply
- Quote
Wednesday, May 23, 2012 3:07 PM

0

Any solution for Windows 2008R2 MSSQL server without Internet and AD connection?
- Reply
- Quote
Thursday, May 24, 2012 5:23 AM

0

Or you must manually install CRLs locally.

Vadim, I have manually installed the www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab on the server without reboot, but it doesn't fix the issue.

I accept manual certificate update on production DB if Microsoft cannot do certificate updates trough WSUS. Microsoft takes care about administator's jobs. :)

BTW, Microsoft provides root certificate updates via WSUS too: http://social.technet.microsoft.com/wiki/contents/articles/9964.windows-root-certificate-program-members-april-2012.aspx
My weblog: http://en-us.sysadmins.lv
PowerShell PKI Module: http://pspki.codeplex.com
Windows PKI reference: on TechNet wiki
- Reply
- Quote
Thursday, May 24, 2012 10:46 AM

0

BTW, Microsoft provides root certificate updates via WSUS too: http://social.technet.microsoft.com/wiki/contents/articles/9964.windows-root-certificate-program-members-april-2012.aspx

Thanks for info. I have WSUS on Windows 2008R2 64-bit :(

By using WSUS, administrators can fully manage the distribution of updates that are released through Microsoft Update to computers in their network. In April, the releases available by WSUS are targeted to 32-bit Windows client and specific server platforms only. Future root update releases will also be available via WSUS for 64-bit Windows platforms.
- Reply
- Quote

Issues with CAPI2 on Windows 2008 R2 Event ID 11 and 41

All Replies

Products

Resources

Solutions

Updates

Trials

Related Sites

Training

Certifications

Other resources

Support by product

Other support links

Not an IT pro?