SSL_alert_type_string 3 2003-07-24 0.9.9-dev OpenSSL
NAME
SSL_alert_type_string, SSL_alert_type_string_long, SSL_alert_desc_string, SSL_alert_desc_string_long - get textual description of alert information
LIBRARY
libcrypto, -lcrypto
SYNOPSIS
#include
const char *SSL_alert_type_string(int value);
const char *SSL_alert_type_string_long(int value);
const char *SSL_alert_desc_string(int value);
const char *SSL_alert_desc_string_long(int value);
DESCRIPTION
_S_S_L___a_l_e_r_t___t_y_p_e___s_t_r_i_n_g_(_) returns a one letter string indicating the
type of the alert specified by vvaalluuee.
_S_S_L___a_l_e_r_t___t_y_p_e___s_t_r_i_n_g___l_o_n_g_(_) returns a string indicating the type of the alert
specified by vvaalluuee.
_S_S_L___a_l_e_r_t___d_e_s_c___s_t_r_i_n_g_(_) returns a two letter string as a short form
describing the reason of the alert specified by vvaalluuee.
_S_S_L___a_l_e_r_t___d_e_s_c___s_t_r_i_n_g___l_o_n_g_(_) returns a string describing the reason
of the alert specified by vvaalluuee.
NOTES
When one side of an SSL/TLS communication wants to inform the peer about
a special situation, it sends an alert. The alert is sent as a special message
and does not influence the normal data stream (unless its contents results
in the communication being canceled).
A warning alert is sent, when a non-fatal error condition occurs. The
"close notify" alert is sent as a warning alert. Other examples for
non-fatal errors are certificate errors ("certificate expired",
"unsupported certificate"), for which a warning alert may be sent.
(The sending party may however decide to send a fatal error.) The
receiving side may cancel the connection on reception of a warning
alert on it discretion.
Several alert messages must be sent as fatal alert messages as specified
by the TLS RFC. A fatal alert always leads to a connection abort.
RETURN VALUES
The following strings can occur for _S_S_L___a_l_e_r_t___t_y_p_e___s_t_r_i_n_g_(_) or
_S_S_L___a_l_e_r_t___t_y_p_e___s_t_r_i_n_g___l_o_n_g_(_):
-
"W"/"warning"
-
-
"F"/"fatal"
-
-
"U"/"unknown"
This indicates that no support is available for this alert type.
-
Probably vvaalluuee does not contain a correct alert message.
The following strings can occur for _S_S_L___a_l_e_r_t___d_e_s_c___s_t_r_i_n_g_(_) or
_S_S_L___a_l_e_r_t___d_e_s_c___s_t_r_i_n_g___l_o_n_g_(_):
-
"CN"/"close notify"
The connection shall be closed. This is a warning alert.
-
-
"UM"/"unexpected message"
An inappropriate message was received. This alert is always fatal
-
and should never be observed in communication between proper
implementations.
-
"BM"/"bad record mac"
This alert is returned if a record is received with an incorrect
-
MAC. This message is always fatal.
-
"DF"/"decompression failure"
The decompression function received improper input (e.g. data
-
that would expand to excessive length). This message is always
fatal.
-
"HF"/"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.
-
"NC"/"no certificate"
A client, that was asked to send a certificate, does not send a certificate
-
(SSLv3 only).
-
"BC"/"bad certificate"
A certificate was corrupt, contained signatures that did not
-
verify correctly, etc
-
"UC"/"unsupported certificate"
A certificate was of an unsupported type.
-
-
"CR"/"certificate revoked"
A certificate was revoked by its signer.
-
-
"CE"/"certificate expired"
A certificate has expired or is not currently valid.
-
-
"CU"/"certificate unknown"
Some other (unspecified) issue arose in processing the
-
certificate, rendering it unacceptable.
-
"IP"/"illegal parameter"
A field in the handshake was out of range or inconsistent with
-
other fields. This is always fatal.
-
"DC"/"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.
-
"RO"/"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.
-
"CA"/"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.
-
"AD"/"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.
-
"DE"/"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.
-
"CY"/"decrypt error"
A handshake cryptographic operation failed, including being
-
unable to correctly verify a signature, decrypt a key exchange,
or validate a finished message.
-
"ER"/"export restriction"
A negotiation not in compliance with export restrictions was
-
detected; for example, attempting to transfer a 1024 bit
ephemeral RSA key for the RSA_EXPORT handshake method. This
message is always fatal.
-
"PV"/"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.
-
"IS"/"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.
-
"IE"/"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). This message is always fatal.
-
"US"/"user canceled"
This handshake is being canceled for some 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.
-
"NR"/"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 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, etc.) at startup and it might be
difficult to communicate changes to these parameters after that
point. This message is always a warning.
-
"UK"/"unknown"
This indicates that no description is available for this alert type.
-
Probably vvaalluuee does not contain a correct alert message.
SEE ALSO
_s_s_l(3), _S_S_L___C_T_X___s_e_t___i_n_f_o___c_a_l_l_b_a_c_k(3)