RFC 2246              The TLS Protocol Version 1.0          January 1999


   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended. If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation may choose to close the
   transport without waiting for the responding close_notify. No part of
   this standard should be taken to dictate the manner in which a usage
   profile for TLS manages its data transport, including when
   connections are opened or closed.

   NB: It is assumed that closing a connection reliably delivers
       pending data before destroying the transport.

7.2.2. Error alerts

   Error handling in the TLS Handshake protocol is very simple. When an
   error is detected, the detecting party sends a message to the other
   party. Upon transmission or receipt of an fatal alert message, both
   parties immediately close the connection. Servers and clients are
   required to forget any session-identifiers, keys, and secrets
   associated with a failed connection. The following error alerts are
   defined:

   unexpected_message
       An inappropriate message was received. This alert is always fatal
       and should never be observed in communication between proper
       implementations.

   bad_record_mac
       This alert is returned if a record is received with an incorrect
       MAC. This message is always fatal.

   decryption_failed
       A TLSCiphertext decrypted in an invalid way: either it wasn`t an
       even multiple of the block length or its padding values, when
       checked, weren`t correct. This message is always fatal.

   record_overflow
       A TLSCiphertext record was received 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.

   decompression_failure
       The decompression function received improper input (e.g. data
       that would expand to excessive length). This message is always
       fatal.




 
RFC 2246              The TLS Protocol Version 1.0          January 1999


   handshake_failure
       Reception of a handshake_failure alert message indicates that the
       sender was unable to negotiate an acceptable set of security
       parameters given the options available. This is a fatal error.

   bad_certificate
       A certificate was corrupt, contained signatures that did not
       verify correctly, etc.

   unsupported_certificate
       A certificate was of an unsupported type.

   certificate_revoked
       A certificate was revoked by its signer.

   certificate_expired
       A certificate has expired or is not currently valid.

   certificate_unknown
       Some other (unspecified) issue arose in processing the
       certificate, rendering it unacceptable.

   illegal_parameter
       A field in the handshake was out of range or inconsistent with
       other fields. This is always fatal.

   unknown_ca
       A valid certificate chain or partial chain was received, but the
       certificate was not accepted because the CA certificate could not
       be located or couldn`t be matched with a known, trusted CA.  This
       message is always fatal.

   access_denied
       A valid certificate was received, but when access control was
       applied, the sender decided not to proceed with negotiation.
       This message is always fatal.

   decode_error