Schannel errors on three of my DC's; Event ID 36887, Alert 46


  • I too am recieving the elusive schannel errors on three of my DC's, Event ID 36887, Alert 46. They only happen occasionally, at seemingly arbitrary times.

    All three are Domain Controllers only; no IIS installed, no Exchange servers. No one logs in to these and browses from them (yes, I checked the event logs). There are no third party browsers installed. I have even tried disabling TLS in the IE settings, no luck (not sure how or wy that would even work).

    I have read as many forum posts as I can on this, and am still no closer to understanding what is going on.

    How do I track this down?

    EventID            : 36887
    MachineName        :
    Data               : {}
    Index              : 27206
    Category           : (0)
    CategoryNumber     : 0
    EntryType          : Error
    Message            : The following fatal alert was received: 46.
    Source             : Schannel
    ReplacementStrings : {46}
    InstanceId         : 36887
    TimeGenerated      : 3/26/2012 7:21:36 AM
    TimeWritten        : 3/26/2012 7:21:36 AM
    UserName           : NT AUTHORITY\SYSTEM
    Monday, March 26, 2012 5:25 PM

All replies

    1. Do you have a CA in your infrastructure? Do you use certificates to secure traffic/ipsec? Can the certificate be checked for revocation?
    2. Have you recently modified the domain controllers policy? Make sure the Domain controllers policy settings are default as below:

    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, March 26, 2012 10:54 PM
  • Thanks for the reply Marius.

    1. Yes, I have a CA in my infrastructure, and yes we are using the certificates. I reviewed the certs on the DC's and nothing is reported as being problematic; If I open up the Certificates in the MMC, and I browse though all of them, I don't see any issues in the status column.

    2. I reviewed the policy applied to domain controllers, and it appears that none of these things are defined as you have them. I will review these changes with my team lead, and see if this is something we want to pursue.


    Tuesday, March 27, 2012 5:07 PM
  • The sample I provided is from a fresh standard server installation with no alterations made, no errors. You have somewhere "Message: the following fatal alert was recieved: 46"; acording to this article  46 is for TLS1_ALERT_CERTIFICATE_UNKNOWN (46) which would make me think that certificate could not be verified for revocation. I would install MS network monitor / Wireshar and try to see in detail what happens (TLS handshake in detail, what version of TLS is used,etc).

    Microsoft released Security Bulletin MS12-006 on January 10, 2012 wich fixed some vulnerability by changing the way that the Windows Secure Channel (SChannel) component transmits encrypted network packets.

    I didn't ask what OS version are the Domain Controllers? Are they fully updated? Is the DC certificates valid and from a Trusted Root CA (sorry if th questions seem dull but I have to ask)?

    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, March 27, 2012 7:11 PM
  • Everything is Server 2008 R2 service pack 1, and all current patches were just updated last month. The CA, however, is behind schedule.

    The DC's certificate appears to be valid, and was issued by my subordinate CA. It also appears that I have an Enterprise CA, which explains why I'm not seeing the auto-enrollment in Group Policy (this is a system I inherited, so I am trying to figure all this stuff out as I go...)

    I may have to go with the sniffer after all; I still cannot tell *which* certificate is having issues. The event log is not giving me that kind of detail.


    Tuesday, March 27, 2012 9:27 PM
  • The sniffer still isn't telling me anything. It only happens once every few days, and when it does happen, it is difficult to correlate events in the sniffer to the corresponding instance in the event log. The only server that *might* be the culprit appears to be connecting just fine at all other times...

    Also, I looked up alert ID 46, and all is says is "Certificate Unkown".

    There hast to be some owther way to get detail on where this "unkown certificate" is coming from....

    • Edited by Paul.LaVigne Tuesday, April 10, 2012 6:05 PM
    • Proposed as answer by Gnomenomicon Monday, September 07, 2015 5:07 AM
    • Unproposed as answer by Gnomenomicon Monday, September 07, 2015 5:07 AM
    Tuesday, April 10, 2012 3:29 PM
  • Hello,

    we are getting the same error on nearly all of our DCs (about 100 errors in one hour!). We don't have Exchange or IIS, too. And we have an internal CA on one DC. We are using our AD for external Web-Applications as an LDAP-Server for user-authentication. These are nearly all Linux-based-applications, and they connect via LDAP(S) on port 636. Perhaps they do not connect in the right way or are not able to get the CRL because we do not have an ISS to get the CRL. How can we get rid of this error? Disabling schannel-Logging isn't a solution for us...

    Any would be appreciated.

    Kind regards,


    Tuesday, May 22, 2012 2:56 PM
  • I wish I knew. I too would prefer not to disable schannel logging either.

    If you have any better results with running a sniffer or something, by all means, let me know.

    Tuesday, May 22, 2012 3:38 PM
  • In the meantime i was able to find the cause for the errors: One of our Linux Boxes which connects via LDAPS to our AD used a certificate from one DC which was nearly out of date. After renewing this certificate the errors do not occur anymore.

    I used network Monitor to scan the network traffic and saw a connection from the Linux Box at the same time the error occured in the eventlog. So i talked to my colleague to check the connection and he renewed the certificate.

    Hope this helps!



    Tuesday, May 29, 2012 7:17 PM
  • Thanks for the tip. I tried Wireshark before, and there were several potential candidates for the machine with the issue, but it was not easy to zero in on the culprit. Hopefully Microsoft's Network Mnitor will give me a clearer answer.
    Tuesday, May 29, 2012 9:16 PM
  • I'm hunting this Schannel issue down as well.  It didn't start until today.  Computer crashes after 10 minutes of Diablo III of all things.  It starts by losing video going to the monitor, then the audio starts to cut in and out (both mic and speakers) every 4 seconds until nothing.  Blank screen, no sound, no mic.  Power button has to be held down to regain control.

     No updates applied to Diablo or Windows 8 CP.   The only other system on my network (that's turned on) is a Linux box my brother setup to run my phone system (Asterix).  No changes to for weeks now.    

    Just thought I would throw in my 2 cents.  Usually video games like to put stress on the video card.  This forum though makes it sound like possibly encrypted network traffic?

    Clicking on the "Event Log Online Help" in the event viewer just takes me to a Microsoft site that says "We're sorry There is no additional information about this issue..."

    I'm going to keep digging.

    EDIT: Sorry,  this is a Server forum.  You an ignore all this.  Its on a client install.

    • Edited by Macgyvers Sunday, June 03, 2012 4:56 AM
    Sunday, June 03, 2012 4:45 AM
  • Hello

    Check out this solution.

    MMC, file, Add remove snapin..., Certificates, computer.

    Navigate into "Trusted RootCertificationAuthorities" "Certificates"

    Look at the certificates. Is there more than 50-60 cert you have a problem.

    Find a computer you can compare the cert store with. Delete root certs, witch you do not need.

    The issue is to many root cert for the computer to check throgh! good luck!

    Scan your computer, you may have a virus or a Worm!


    • Proposed as answer by Ujoshi Friday, April 05, 2013 4:46 PM
    • Unproposed as answer by Ujoshi Friday, April 05, 2013 4:46 PM
    Thursday, January 03, 2013 11:44 AM
  • We were able to resolve this issue.

    Using Wireshark, I was able to correlate the event's occurrence with LDAPS authentication attempts from a web server that was misconfigured to use an incorrect certificate (the public of another DC). Once the web server had the correct cert, these errors stopped on the DC.

    • Proposed as answer by tester411 Wednesday, April 19, 2017 9:21 PM
    Friday, April 05, 2013 4:49 PM
  • I am going to use Wireshark to troubleshoot the same. Can you give hints for how to find the packets that show the relevant information? 
    Wednesday, August 14, 2013 5:12 PM
    - Provider
    EventID 36887
    Version 0
    Level 2
    Task 0
    Opcode 0
    Keywords 0x8000000000000000
    - TimeCreated
    EventRecordID 5190
    - Execution
    Channel System
    Computer 5CD3182MR2
    - Security
    - EventData




    Sunday, January 12, 2014 10:23 PM
  • We had a very similar (if not the same) issue on our Domain with the Error 36886 popping up on one site's Domain Controllers. I can't believe some people are suggesting to implement CA on your AD as a solution to this issue. Certificate Authority is a great enterprise system but only when and if it's needed, otherwise I would avoid implementing it on my AD domain infrastructure.

    Simple solution:

    We had a W2K08R2 server which we used to test / trial a new software product. The server was installed and configured but NEVER activated since we wee only used it to test the trial application.

    That's what was creating all of the S Channel errors (36886) only for our local site domain controllers.

    Shutting that server down solved the issue. Seems like that server was trying to obtain a certificate form our current domain and maybe because it was not activated caused all the errors. Hope this might help someone out there so you won't have to spend all day troubleshooting CA, LDAP, AD and almost started the traffic capture / debug process



    Thursday, December 17, 2015 8:47 PM
  • I had the same error and found a solution for my problem. Yesterday I added a new certificate to the server and left an old expired cert with the same name and purpose. When I deleted the old cert I stopped getting the error events and it then allowed clients to authenticate against the correct cert.

    Hope this helps someone.

    Keith Berling, MCSE, CCNA, VCP
    • Edited by burntpepsi Thursday, April 21, 2016 2:33 PM adding signature
    Thursday, April 21, 2016 2:21 PM
  • For those who come across this forum still today looking for answers like I was...

    An IT analyst recently installed the Microsoft Baseline Security Analyzer on all of our DCs. Our certificates are fine, but these events immediately disappeared from the Exchange server after uninstalling the MBSA from the DCs.

    Friday, October 21, 2016 8:36 PM
  • QUESTION: Is this error just an annoyance or is there a real impact? I'm asking cause I'm trying to find a root cause to another problem and this is the last person at the scene.

    Thanks In Advance

    Dum loquimur fugerit invida aetas. Carpe diem quam minimum credula postero. "Research your own experiences for the truth, absorb what is useful, reject what is useless, add what is specifically your own" - Jiddu Krishnamurti. "Strength does not come from physical capacity. It comes from an indomitable will" - Gandhi. Freelancer: 0423 009 408

    Thursday, March 30, 2017 3:52 AM
  • It appears to be more of an annoyance, however, if this is the symptom of a deeper underlying problem, then, there is no way to know.
    Friday, March 31, 2017 3:34 PM
  • I ended up using Microsoft Message Analyzer to capture the offending packets. I created a Live Trace session with the Local Network Interfaces for my Select Scenario and entered < *Summary == "Records: [Alert]" > for the Session Filter. This helped me to identify systems with cert problems.

    I original found the TLS handshake and specific packet I wanted to capture by using the Start Local Trace from the Microsoft Message Analyzer Start Page and, after capturing some traffic, filter on tcp.port == 636.

    Wednesday, April 19, 2017 9:21 PM