SSL/TLS Alert Protocol & the Alert Codes

There have been many occasions where a event corresponding to SChannel is logged in the System event logs which indicates a problem with the SSL/TLS handshake and many a times depicts a number. The logging mechanism is a part of the SSL/TLS Alert Protocol. These alerts are used to notify peers of the normal and error conditions. The numbers especially, play a trivial role in understanding the problem/failure with the SSL/TLS handshake.

SChannel logging may have to be enabled on the windows machines to get detailed SChannel messages. Please refer the following article to do so:

Below is an example of one such event:

Log Name:      System
Source:        Schannel
Date:          x/xx/xxxx x:xx:xx
Event ID:      36887
Task Category: None
Level:         Error
User:          SYSTEM
Computer:      xxxxxxx
The following fatal alert was received: 47.

These warnings sometimes are very helpful in troubleshooting SSL related issues and provide important clues. However, there is not much documentation available on the description of the alert codes.

These alert codes have been defined precisely in TLS/SSL RFC’s for all the existing protocol versions. For example lets consider the RFC 5246 (TLS 1.2). This RFC corresponds to the latest protocol version and it defines the alert messages.

Follow this link:

Below is a snippet from the above RFC describing the various alert messages:

A.3.  Alert Messages

   enum { warning(1), fatal(2), (255) } AlertLevel;
   enum {
       unsupported_extension(110),           /* new */
   } AlertDescription;
   struct {
       AlertLevel level;
       AlertDescription description;
   } Alert;

There is MSDN article which describes these messages more briefly. Here is the link:

However, the article never mentions the alert codes while explaining the messages. For simplicity, I have created a simpler table combining both the MSDN documentation and the RFC for usability. Below is the table:

Alert Code





Notifies the recipient that the sender will not send any more messages on this connection.



Received an inappropriate message This alert should never be observed in communication between proper implementations. This message is always fatal.



Received a record with an incorrect MAC. This message is always fatal.



Decryption of a TLSCiphertext record is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were not correct. This message is always fatal.



Received a TLSCiphertext record which had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14+1024 bytes. This message is always fatal.



Received improper input, such as data that would expand to excessive length, from the decompression function. This message is always fatal.



Indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. This is a fatal error.



There is a problem with the certificate, for example, a certificate is corrupt, or a certificate contains signatures that cannot be verified.



Received an unsupported certificate type.



Received a certificate that was revoked by its signer.



Received a certificate has expired or is not currently valid.



An unspecified issue took place while processing the certificate that made it unacceptable.



Violated security parameters, such as a field in the handshake was out of range or inconsistent with other fields. This is always fatal.



Received a valid certificate chain or partial chain, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known, trusted CA. This message is always fatal.



Received a valid certificate, but when access control was applied, the sender did not proceed with negotiation. This message is always fatal.



A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This message is always fatal.



Failed handshake cryptographic operation, including being unable to correctly verify a signature, decrypt a key exchange, or validate a finished message.



Detected a negotiation that was not in compliance with export restrictions; for example, attempting to transfer a 1024 bit ephemeral RSA key for the RSA_EXPORT handshake method. This message is always fatal.



The protocol version the client attempted to negotiate is recognized, but not supported. For example, old protocol versions might be avoided for security reasons. This message is always fatal.



Failed negotiation specifically because the server requires ciphers more secure than those supported by the client. Returned instead of handshake_failure. This message is always fatal.



An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue, such as a memory allocation failure. The error is not related to protocol. This message is always fatal.



Cancelled handshake for a reason that is unrelated to a protocol failure. If the user cancels an operation after the handshake is complete, just closing the connection by sending a close_notify is more appropriate. This alert should be followed by a close_notify. This message is generally a warning.



Sent by the client in response to a hello request or sent by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert; at that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate would be where a server has spawned a process to satisfy a request; the process might receive security parameters (key length, authentication, and so on) at start-up and it might be difficult to communicate changes to these parameters after that point. This message is always a warning.




There were few articles that I found while searching that contain additional alert codes. However, I don’t find these to be part of the RFC. Here is one:

It includes additional alerts like 110, 111, 112, 113, 114, 115. You can browse the above link for further reading.

Hope someone finds the above table useful. It may not help you in solving any issue but would provide useful pointers.

Until then, Ciao! Smile

Comments (30)

  1. Rob says:

    Thanks for combing those together. A very useful table for understanding what the specific codes really mean! 🙂

  2. 48 says:

    How do you fix #48? I have a CA key installed.

  3. Could you provide more detail? what is the error? #48 is not about having the CA key installed. Its about verifying the CA, a simple comparison of the CA cert part of  the certificate chain to the CA cert present in the corresponding certificate stores.

  4. Mike Ramalho says:

    I'm actually receiving error 42 and 43 while the user is connected via usb ethernet. When i disable his usb ethernet and connect through wifi he is fine. Any ideas?

  5. Craig Williams says:

    Good information, but still unanswered questions. When this event is logged why does it not include the name of the cert with the issue and the client presenting the cert?

  6. @Mike I'm assuming that there was an issue with the users certificate. However, this is a guess based on the response. I'm not entirely sure. You may wanna take up this question in the Certificates discussion forums of Microsoft.


    I couldn't agree with you more. One reason I can think of is that most of the times when there is a schannel failure the certificate information is not available and hence it is not logged. Also parsing through a certificate requires certain amount of processing which will incurr compute cost on the logging per say. I guess the developers did a trade off here to save processing time.

  7. Anders Skar says:

    We have a problem with error #46 on a IIS server. Any idea how to troubleshoot this issue? (Our IIS serversseems to have a problem with receiving requests from another server, since no requests are logged and error #46 is logged in the event log).

  8. @Anders

    The description is really not helping me to provide you any suggestions. The site on your server to which the other server connects to should have a SSL cert I believe. Is the SSL cert installed on the site issued by a internal CA or a public CA. Is the cert trusted which implies is the issuer of the cert trusted by both your server and the client (in this case the other server)

    This is typically seen in Client Certificate Authentication. Are you using client certificate Auth for the site?

  9. Carsten says:

    Verry good article. Now you only need to read this Post for Server 2008 & 2011:



  10. Hi Carsten,

    Thanks for your comment. I would suggest you to go through this…/245030

    It is more in detail than the link you shared. Another things is that disabling and enabling of protocols is done via registry which remains consistent throughout different version of windows. You may copy the registry from a older version to a newer version.

    NOTE: I'm only referring to the registry keys corresponding to enabling and disabling of SSL protocols. The registry keys do change from an older version to a newer version. Please be careful while migrating registry keys, as it can put the OS in an unstable state.

  11. Tim says:

    This article is useless without an explanation of what to do when the errors occur!!

  12. Thomas says:

    I like the article, but it does not mention any further RFCs. Alert 115 for example is used for PSK key exchange, which is described in RFC 4279 (…/rfc4279.txt ).

    Note, that RFC 5246 does not cover all possibilities of TLS 1.2.

  13. Raj says:


    How do you fix #40 (Handshake fatal error)?


  14. George says:

    How do you fix #20 (A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 20. The Windows SChannel error state is 960.)

    thank in advance

  15. @George

    In this case I will gather a TCP dump from client and server and enable logging on either client/server depending on where the message was seen.

    In case of Windows Server I will enable SChannel logging.

  16. Mark McLean says:

    I have #49 repeatedly filling logs, no idea what the problem is

  17. Mark McLean says:

    Server is Windows Server 2012 R2 and keeps registering the schannel error 49 I am not running IIS it's just a file server, how can I determine cause and resolve this issue?

  18. Jivachh says:

    Server is Windows Server 2012 R2 and Keep receiving the alerts " SY:Schannel: Error: 36887:A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 112. " and " SY:Schannel: Error: 36887:A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40. "

    Please let me know how to fix this issue… IIS running on the server.

  19. @Mark,

    49 for a File server sounds tricky. I would suggest you to get a support ticket logged for this and have Microsoft support take a look at this.


    Looks there are compatibility issues with one of the clients trying to connect to the server. If you have access to the client, then capture a end to end network trace and review it to see what parameters are being passed in client hello by that client.

  20. Steven Reid says:

    I am getting lots of 49 errors on my workstation, and wonder if there is a way to find out what machine is causing the error.  Are you able to find what machine the communication is with?

  21. Paul Lindsey says:

    Hi, anyone ever seen lots of 70 errors on an Exchange 2010 CAS? getting loads of these throughout the day, we have also noticed that Outlook Anywhere users get randomly disconnected, but dont know if this is just a red herring

  22. Abhijeet Kale says:

    I am getting message type id 128. i dont find any description for 128.

  23. Willie says:

    THank you very much received error 45, and your article helped me to solve this

  24. Hunter Scout says:

    Only get the SChannel 36887 error when I remove a service account from the Administrator group. Otherwise the ssl/tls handshake works. Problem is, I cannot have the service account in the Administrator group for Security reasons.

  25. Beverly says:

    Thanks for this great collection in human friendly form.

  26. Dominic says:

    I originally had a DC (DC02) configured as the root CA in my environment. I forgot about this DC role and I recently configured my second DC (DC01) as another root CA using a different key SHA256. When I noticed that my DC02 has already the root CA configured, I uninstalled the CA role on that DC and re-installed that role but as a subordinate CA requesting the certificate from the parent DC01.

    Since this change, I’m receiving the TLS fatal error #48 and I don’t know what I have to do to fix it. It’s probably related to the old original root Ca that I didn’t properly uninstalled…

    any Idea?


  27. Diego says:

    Awesome man! thanks a lot for your deep info!

  28. shambhu prasad says:

    UDTS 36887 Error Schannel System 20/04/2017 18:47:55
    how to remove this error please suggest

  29. rakesh says:

    40 how to fix

    1. @Rakesh. You will have to debug this further to determine what caused the handshake to fail. You can start by gather network traces via Wireshark.

Skip to main content