SSL_ALERT_TYPE_STRING(3) OpenSSL SSL_ALERT_TYPE_STRING(3)
SSL_alert_type_string, SSL_alert_type_string_long,
SSL_alert_desc_string, SSL_alert_desc_string_long - get tex-
tual description of alert information
#include <openssl/ssl.h>
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);
SSL_alert_type_string() returns a one letter string indicat-
ing the type of the alert specified by value.
SSL_alert_type_string_long() returns a string indicating the
type of the alert specified by value.
SSL_alert_desc_string() returns a two letter string as a
short form describing the reason of the alert specified by
value.
SSL_alert_desc_string_long() returns a string describing the
reason of the alert specified by value.
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.
The following strings can occur for SSL_alert_type_string()
or SSL_alert_type_string_long():
MirBSD #10-current 2005-02-05 1
SSL_ALERT_TYPE_STRING(3) OpenSSL SSL_ALERT_TYPE_STRING(3)
"W"/"warning"
"F"/"fatal"
"U"/"unknown"
This indicates that no support is available for this
alert type. Probably value does not contain a correct
alert message.
The following strings can occur for SSL_alert_desc_string()
or SSL_alert_desc_string_long():
"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 communica-
tion 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 mes-
sage 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
MirBSD #10-current 2005-02-05 2
SSL_ALERT_TYPE_STRING(3) OpenSSL SSL_ALERT_TYPE_STRING(3)
certificate, rendering it unacceptable.
"IP"/"illegal parameter"
A field in the handshake was out of range or incon-
sistent 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 pad-
ding 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 cer-
tificate 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 con-
trol 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 nego-
tiate is recognized, but not supported. (For example,
old protocol versions might be avoided for security rea-
sons). This message is always fatal.
"IS"/"insufficient security"
MirBSD #10-current 2005-02-05 3
SSL_ALERT_TYPE_STRING(3) OpenSSL SSL_ALERT_TYPE_STRING(3)
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 correct-
ness 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 unre-
lated 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 reci-
pient 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 value does not contain a correct
alert message.
ssl(3), SSL_CTX_set_info_callback(3)
MirBSD #10-current 2005-02-05 4