Here is the list of expected error codes.

bad_record_mac

This alert is returned if:

A record is received with an incorrect MAC.
A TLSCiphertext is decrypted in an invalid way; either it wasn't an even multiple of the block length, or its padding values, when checked, were in

This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).

decryption_failed_RESERVED

This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode [CBCATT]. It must not be sent by compliant implementations.

record_overflow

A TLSCiphertext record was received that with a length of more than 2^14+2048 bytes

Or

A record is decrypted to a TLSCompressed record with more than 2^14+1024 bytes.

This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).

decompression_failure

The decompression function received improper input (e.g., data that would expand to excessive length).

This message is always fatal and should never be observed in communication between proper implementations.

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 available options.

This is a fatal error.

no_certificate_RESERVED

This alert was used in SSLv3 but not any version of TLS. It must not be sent by compliant implementations.

bad_certificate

The certificate was corrupt, it contained signatures that could not be verified.

unsupported_certificate

The certificate type is unsupported.

certificate_revoked

The certificate was revoked by its signer.

certificate_expired

The 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 message 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 the negotiation.

This message is always fatal.

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 and should never be observed in communication between proper implementations (except when messages were corrupted in the network).

decrypt_error

A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message.

This message is always fatal.

export_restriction_RESERVED

This alert was used in some earlier versions of TLS. It must not be sent by compliant implementations.

protocol_version

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

insufficient_security

Returned instead of handshake_failure when a negotiation has failed specifically because the server requires ciphers more secure than those supported by the client.

This message is always fatal.

internal_error

An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible to continue.

This message is always fatal.

user_canceled

This handshake is being canceled for an unclear reason 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.

no_renegotiation

Sent by the client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these would normally lead to a renegotiation. If that is not appropriate, the recipient should respond with this alert. At that point, the original requester can decide whether or not to proceed with the connection.

One case where this would be appropriate is where a server has spawned a process to satisfy a request. This process might receive security parameters (key length, authentication, etc.) at startup, and it might be difficult to communicate changes to these parameters after that point.

This message is always a warning.

unsupported_extension

Sent by clients that receive an extended server hello containing an extension that they did not put in the corresponding client hello. This message is always fatal.

Source RFC 5246 7.2.2 https://www.ietf.org/rfc/rfc5246.txt