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: http://support.microsoft.com/kb/260729

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
Keywords:     
User:          SYSTEM
Computer:      xxxxxxx
Description:
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: http://tools.ietf.org/html/rfc5246#appendix-A.3

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 {
       close_notify(0),
       unexpected_message(10),
       bad_record_mac(20),
       decryption_failed_RESERVED(21),
       record_overflow(22),
       decompression_failure(30),
       handshake_failure(40),
       no_certificate_RESERVED(41),
       bad_certificate(42),
       unsupported_certificate(43),
       certificate_revoked(44),
       certificate_expired(45),
       certificate_unknown(46),
       illegal_parameter(47),
       unknown_ca(48),
       access_denied(49),
       decode_error(50),
       decrypt_error(51),
       export_restriction_RESERVED(60),
       protocol_version(70),
       insufficient_security(71),
       internal_error(80),
       user_canceled(90),
       no_renegotiation(100),
       unsupported_extension(110),           /* new */
       (255)
   } AlertDescription;
   struct {
       AlertLevel level;
       AlertDescription description;
   } Alert;

There is MSDN article which describes these messages more briefly. Here is the link: http://technet.microsoft.com/en-us/library/cc783349%28v=ws.10%29.aspx.

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

Alert
Message

Description

0

close_notify

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

10

unexpected_message

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

20

bad_record_mac

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

21

decryption_failed

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.

22

record_overflow

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.

30

decompression_failure

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

40

handshake_failure

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

42

bad_certificate

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

43

unsupported_certificate

Received an unsupported certificate type.

44

certificate_revoked

Received a certificate that was revoked by its signer.

45

certificate_expired

Received a certificate has expired or is not currently valid.

46

certificate_unknown

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

47

illegal_parameter

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

48

unknown_ca

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.

49

access_denied

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

50

decode_error

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.

51

decrypt_error

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

60

export_restriction

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.

70

protocol_version

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.

71

insufficient_security

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.

80

internal_error

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.

90

user_cancelled

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.

100

no_renegotiation

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.

255

unsupported_extension

 

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: http://botan.randombit.net/doxygen/classBotan_1_1TLS_1_1Alert.html

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