This event (and its cousin Schannel 36870) can indicate that there is a problem with the server certificate on the system that is logging the event.
The error is typically logged when a service (for example LSASS on a Domain Controller) has attempted to load and verify the private and public key pair of the server certificate and that either of these operations has failed which makes the the service unable to use that certificate for SSL encryption(f.x. LDAPS, HTTPS, etc.).
The root cause for the event can be several different things:
a) Incorrect ACL’s on the MachineKeys folder on the system disk
b) The server certificate failing revocation checking
c) The system not being able to build a certificate chain up to a trusted root CA for the server certificate
d) The server certificate not being in a format usable by the component
e) The server certificate being expired
’a’ is commonly caused by modifying the ACL’s on the system disk post-install, for example by applying a restrictive security policy to the server that prevents the System account from reading the private or public key.
Check KB 278831 278381 for the default ACL’s for the MachineKeys folder, the security entity reading the public and private keys needs to have access (for LSASS it is the Local System account).
’b’ can be caused by the certificate having been revoked *or* by the system account not being able to download any of the CRL’s that is stamped on to all of the certificates in the certificate chain.
Proxy servers requiring authentication are a known cause for revocation failures as the System account can’t authenticate using NTLM (it can authenticate using Kerberos if the proxy supports it).
Exporting all the certificates in the chain to a .cer file and running certutil –v –verify –urlfetch <cert.cer> in the security context of the server should tell you if this is a problem (use psexec –s to run it in the System context).
A network trace taken during the period when the error message is generated should also show whether there is a problem downloading any of the CRL’s.
’c’ usually means the certificate of the Root CA at the top of the certificate chain is not in the list of Trusted Root Certification Authorities, whichin turn means that the whole chain is not trusted.
’d’ is typically caused by incorrectly formatted or missing information in either the Subject or the Subject Alternate Name (SAN) of the certificate. A certificate you want to be used for domain controller authentication should have a SAN DNS name that matches the DNS name of the domain controller (see also http://social.technet.microsoft.com/wiki/contents/articles/3824.updated-requirements-for-a-windows-server-2008-r2-domain-controller-certificate-from-a-3rd-party-ca.aspx).
KB 932834 has some important functionality changes for Windows Server 2003 concerning how expired or revoked domain controller certificates are treated by LSASS. Prior to that hotfix it was a requirement to reboot the DC in order to get LSASS to pick up any new Domain Controller Authentication certificate, post 932834 behaviour is that it is picked up on the fly.
Note: On Windows 2008 or later operating systems you can enable CAPI2 logging to get more details concerning this error, see http://blogs.technet.com/b/instan/archive/2011/09/09/using-wevtutil-to-capture-and-view-capi2-operational-logging.aspx.
Default permissions for the MachineKeys folders
Event ID 36872 on a Windows 2000 domain controller or on a Windows Server 2003 domain controller
How to enable LDAP over SSL with a third-party certification authority
Guidelines for enabling smart card logon with third-party certification authorities
Troubleshooting Certificate Status and Revocation
Summary of changes to the CryptoAPI certificate chain validation logic
Certificate Revocation and Status Checking
You may be unable to connect to a Windows Server 2003-based domain controller by using LDAP over an SSL connection