SSL_alert_desc_string man page on MirBSD

Man page or keyword search:  
man Server   6113 pages
apropos Keyword Search (all sections)
Output format
MirBSD logo
[printable version]



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 tex-
     tual description of alert information

SYNOPSIS
      #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);

DESCRIPTION
     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.

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 SSL_alert_type_string()
     or SSL_alert_type_string_long():

MirOS BSD #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

MirOS BSD #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"

MirOS BSD #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.

SEE ALSO
     ssl(3), SSL_CTX_set_info_callback(3)

MirOS BSD #10-current	   2005-02-05				4

[top]

List of man pages available for MirBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net