SSL_ALERT_TYPE_STRING(3SSL)

✨ SSL_ALERT_TYPE_STRING ✨

okay bestie, sit down, hydrate, because we're about to talk about SSL_alert_type_string, SSL_alert_type_string_long, SSL_alert_desc_string, and SSL_alert_desc_string_long β€” the little icons of the 3SSL manual, aka the OpenSSL girlies that turn alert numbers into actual human words πŸ’…


πŸ¦‹ NAME

SSL_alert_type_string, SSL_alert_type_string_long, SSL_alert_desc_string, SSL_alert_desc_string_long β€” get a textual 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

so like, four functions, two jobs: one tells you the type of an alert, the other tells you the reason for it. And each one comes in a short version and a long version, because sometimes you want the tl;dr and sometimes you want the whole essay 🫢

  • SSL_alert_type_string() β€” hands you a one letter string saying what type of alert value is. bougie minimalist energy.
  • SSL_alert_type_string_long() β€” same vibe, but it returns a string (like, a whole readable word) indicating the type of the alert specified by value. no cap.
  • SSL_alert_desc_string() β€” returns a two letter string, a lil short form describing the reason of the alert specified by value. it's giving acronym core.
  • SSL_alert_desc_string_long() β€” returns a string describing the reason of the alert specified by value. the full story, periodt.

πŸ‘‘ NOTES

okay so when one side of an SSL/TLS communication wants to inform its peer about a special situation, it sends an alert. it's sent as a special message and it does not influence the normal data stream β€” unless its contents result in the communication being canceled, in which case, yeah, everything's over πŸ’€

A warning alert gets sent when a non-fatal error condition occurs. The "close notify" alert is sent as a warning alert. Other examples of non-fatal errors are certificate errors ("certificate expired", "unsupported certificate"), for which a warning alert may be sent. Now β€” plot twist β€” the sending party may however decide to send a fatal error instead. and the receiving side may cancel the connection on reception of a warning alert, at its discretion. so, like, warnings are warnings but they can still ghost you 😭

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. always. no exceptions. fatal means fatal bestie πŸ”₯


πŸ’… RETURN VALUES

⭐ the type strings

here's what can pop out of 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 description strings

and here's what can pop out of SSL_alert_desc_string() or SSL_alert_desc_string_long() β€” buckle up, it's a long list, but every single one of these is iconic in its own way:

  • "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. like... who raised you.
  • "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). girl just didn't show up πŸ’€
  • "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. it's not them, it's us 😭
  • "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.
  • "UP" / "unknown PSK identity" β€” sent by the server to indicate that it does not recognize a PSK identity or an SRP identity.
  • "UK" / "unknown" β€” this indicates that no description is available for this alert type. probably value does not contain a correct alert message. πŸ™ˆ

🧚 SEE ALSO


Copyright 2001-2016 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


and that's the whole page bestie, you ate that πŸ«ΆπŸ’– this was OpenSSL 4.0.3, dated 2026-09-29, signing off from the SSL_ALERT_TYPE_STRING(3SSL) chapter of your life. go forth and decode those alerts, queen πŸ‘‘βœ¨

πŸ“¦ where this page comes from