SSL_alert_type_string(3) - NetBSD Manual Pages

Command: Section: Arch: Collection:  



SSL_alert_type_string(3)     OpenSSL     SSL_alert_type_string(3)



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 <openssl/ssl.h> char *SSL_alert_type_string(int value); char *SSL_alert_type_string_long(int value); char *SSL_alert_desc_string(int value); char *SSL_alert_desc_string_long(int value);
DESCRIPTION
SSL_alert_type_string() returns a one letter string indi- cating 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.
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 mes- sages as specified by the TLS RFC. A fatal alert always leads to a connection abort.
RETURN VALUES
The following strings can occur for 2002-08-05 0.9.6g 1 SSL_alert_type_string(3) OpenSSL SSL_alert_type_string(3) SSL_alert_type_string() or SSL_alert_type_string_long(): ""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 communi- cation 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 indi- cates 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. 2002-08-05 0.9.6g 2 SSL_alert_type_string(3) OpenSSL SSL_alert_type_string(3) ""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 inconsis- tent 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 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 mes- sage 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 restric- tions was detected; for example, attempting to trans- fer 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 reasons). This message is always fatal. 2002-08-05 0.9.6g 3 SSL_alert_type_string(3) OpenSSL SSL_alert_type_string(3) ""IS""/""insufficient security"" Returned instead of handshake_failure when a negotia- tion 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 cor- rectness of the protocol makes it impossible to con- tinue (such as a memory allocation failure). This mes- sage 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 clos- ing 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 ini- tial 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, authentica- tion, 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.
SEE ALSO
ssl(3), SSL_CTX_set_info_callback(3) 2002-08-05 0.9.6g 4
Powered by man-cgi (2024-03-20). Maintained for NetBSD by Kimmo Suominen. Based on man-cgi by Panagiotis Christias.