SSL_ALERT_TYPE_STRING(3)

💅 SSL_ALERT_TYPE_STRING(3)

okay bestie, so this is a page from the Library Functions Manual — yes, the libssl / libcrypto girlies 💖 — and it's literally all about turning alert numbers into cute little text strings so you can actually tell what the TLS handshake is screaming about. ✨

---

🌸 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

library “libssl” libcrypto
#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 the four besties work like this:

• SSL_alert_type_string() — hands you a one letter string that tells you the type of the alert that value refers to. one letter. minimalist. iconic. 💅
• SSL_alert_type_string_long() — same vibe but it gives you an actual string spelling out the type of the alert value refers to. the long version. the yapper version. 🗣️
• SSL_alert_desc_string() — always returns the two letter string "!!". bestie that's it. that's the whole function. it is not going to elaborate. 😭
• SSL_alert_desc_string_long() — this one actually returns a string describing the reason of the alert that value specifies. the real gossip. 🍓

Now for the lore: when one side of an SSL/TLS communication wants to tell the peer "hey something's up", it sends an alert. the alert goes out as a special message and does not mess with the normal data stream — unless, of course, whatever's inside it ends up cancelling the communication entirely 💀

A warning alert is what gets sent when a non-fatal error condition happens. the "close notify" alert is sent as a warning alert — that's the classic. other non-fatal examples are certificate errors like "certificate expired" and "unsupported certificate", where a warning alert may be sent. (key word: may. the sending party can totally decide to send a fatal error instead, don't @ me 🙈) and the receiving side can cancel the connection on reception of a warning alert at its discretion — it's giving "your call, boo". ✨

Several alert messages must be sent as fatal alert messages as specified by the TLS RFC. and a fatal alert always leads to a connection abort. always. no take-backs. 🔥

---

👑 RETURN VALUES

here's the whole lineup, no skips, we don't gatekeep 💖

the following strings can occur for SSL_alert_type_string() or SSL_alert_type_string_long():

• "W" / "warning" — a warning. the soft launch. 🌸
• "F" / "fatal" — fatal. it's over. 💀
• "U" / "unknown" — this indicates that no support is available for this alert type. probably value does not contain a correct alert message. lowkey a you problem 🫶

the following strings can occur for SSL_alert_desc_string_long():

• "close notify" — the connection shall be closed. this is a warning alert. 👋
• "unexpected message" — an inappropriate message was received. this alert is always fatal and should never be observed in communication between proper implementations. so if you're seeing it… 👀
• "bad record mac" — returned if a record is received with an incorrect MAC. this message is always fatal. 🔥
• "decompression failure" — the decompression function received improper input (e.g., data that would expand to excessive length). this message is always fatal. 😭
• "handshake failure" — receiving 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. 🧚
• "no certificate" — a client that was asked to send a certificate does not send a certificate (SSLv3 only). 🙈
• "bad certificate" — a certificate was corrupt, contained signatures that did not verify correctly, etc. 💀
• "unsupported certificate" — a certificate was of an unsupported type. 🎀
• "certificate revoked" — a certificate was revoked by its signer. ✂️
• "certificate expired" — a certificate has expired or is not currently valid. ⏰
• "certificate unknown" — some other (unspecified) issue arose in processing the certificate, rendering it unacceptable. mysterious. 🦋
• "illegal parameter" — a field in the handshake was out of range or inconsistent with other fields. this is always fatal. 🚨
• "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. 🔓
• "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. 🌊
• "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. 🏛️
• "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. 🚫
• "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. 🧩
• "decrypt error" — a handshake cryptographic operation failed, including being unable to correctly verify a signature, decrypt a key exchange, or validate a finished message. 🔐
• "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. 🛂
• "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. 📼
• "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. 🛡️
• "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. 🫠
• "inappropriate fallback" — sent by a server in response to an invalid connection retry attempt from a client (see RFC 7507). 📞
• "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. 🙋
• "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. 🔁
• "unknown PSK identity" — sent by the server to indicate that it does not recognize a PSK identity or an SRP identity. 🤷
• "certificate required" — sent by servers when a client certificate is desired but none was provided by the client. 📭
• "no application protocol" — sent by servers when a client ALPN extension advertises only protocols that the server does not support (see RFC 7301). 🌐
• "unknown" — this indicates that no description is available for this alert type. probably value does not contain a correct alert message. bestie. 🫶

---

🦋 SEE ALSO

ssl(3), SSL_CTX_set_info_callback(3)

---

⭐ HISTORY

these functions first appeared in SSLeay 0.8.0 and have been available since OpenBSD 2.4. vintage. literally the blueprint. 💜

---

mwah 💋 this page came to you from Debian, dated June 22, 2026 — go forth and decode those alerts, bestie, you're gonna slay 🎀✨