ASN1_GET_OBJECT(3)

💅 ASN1_GET_OBJECT(3) — the ASN1_get_object page, but make it make sense

okay so bestie, welcome to the ASN1_get_object(3) manual page. grab a lil snack 🍓, because this one is genuinely so useful once it clicks — it's all about sniffing out the start of a BER-encoded value. let's go ✨

---

🌸 NAME

ASN1_get_object — parse identifier and length octets

---

🎀 SYNOPSIS

library “libcrypto” #include <openssl/asn1.h>

int
ASN1_get_object(const unsigned char **ber_in, long *plength, int *ptag,
    int *pclass, long omax);

---

🦋 DESCRIPTION

So ASN1_get_object() parses the identifier and length octets of a BER-encoded value. cute, right? 🫶

When you call it, *ber_in is expected to point to the first identifier octet. and if the identifier and length octets turn out to be valid, the function advances *ber_in to the first content octet before it returns — like it just walks you past the header and dips 👑

If the identifier octets are valid, ASN1_get_object() stores the tag number in *ptag and the class of the tag in *pclass. the class is either V_ASN1_UNIVERSAL or V_ASN1_APPLICATION or V_ASN1_CONTEXT_SPECIFIC or V_ASN1_PRIVATE. slay, four whole options 💅

And if the length octets are valid too, ASN1_get_object() stores the number encoded in the length octets in *plength. ngl this next bit is a lil cursed: if the length octet indicates the indefinite form, *plength is set to 0. not a typo, that's just the vibe 🙈

It inspects at most omax bytes. if parsing of the length octets remains incomplete after inspecting that number of bytes, parsing fails with ASN1_R_HEADER_TOO_LONG. periodt.

---

✨ RETURN VALUES

the bits set in the return value of ASN1_get_object() mean the following, and honestly the way this is encoded is highkey iconic:

• 0x80 — an error occurred. one of the “ERRORS” described below has been set. 😭
• 0x20 = V_ASN1_CONSTRUCTED — the encoding is constructed rather than primitive, and the identifier and length octets are valid.
• 0x01 — the length octet indicates the indefinite form. this bit can only occur if V_ASN1_CONSTRUCTED is also set.

consequently, the following combinations can occur — lowkey a little vibe check of its own:

• 0x00 — a valid primitive encoding.
• 0x20 — a valid constructed encoding, definite form.
• 0x21 — a valid constructed encoding, indefinite form.
• 0x80 — either a primitive encoding with a valid tag and definite length, but the content octets won't fit into omax, or parsing failed. use ERR_GET_REASON(3) to distinguish the two cases. 🔍
• 0xa0 — a constructed encoding with a valid tag and definite length, but the content octets won't fit into omax.

and the bit combinations 0x01, 0x81, and 0xa1 cannot occur as return values. so if you see those, something is deeply not giving 💀

---

🔥 ERRORS

if the bit 0x80 is set in the return value, diagnostics can be retrieved with ERR_get_error(3), ERR_GET_REASON(3), and ERR_reason_error_string(3):

💜 ASN1_R_HEADER_TOO_LONG "header too long"

so this one fires when inspecting omax bytes was insufficient to finish parsing, the tag number encoded in the identifier octets exceeds INT_MAX, the number encoded in the length octets exceeds LONG_MAX, or using the indefinite form for the length octets is attempted even though the encoding is primitive. a whole bouquet of problems, one error name 🌸

in this case, the return value is exactly 0x80; no other bits are set. crystal clear, bestie.

if the problem occurred while parsing the identifier octets, *ptag and *pclass remain unchanged. if the problem occurred while parsing the length octets, *ptag and *pclass are set according to the identifier octets. in both cases, *ber_in and *plength remain unchanged. so like, nothing gets half-updated behind your back 🫶

the wording of the error message is confusing. on the one hand, the header might be just fine, and the root cause of the problem could be that the chosen omax argument was too small. on the other hand, outright BER syntax errors are also reported as ASN1_R_HEADER_TOO_LONG. not me defending it, i'm just telling you what it says 😭

🌈 ASN1_R_TOO_LONG "too long"

the identifier and length octets are valid, but the content octets won't fit into omax. the following have been set as appropriate and can safely be inspected: *pclass, *ptag, *plength, and the bits V_ASN1_CONSTRUCTED and 0x01 in the return value. the parse pointer *ber_in has been advanced to the first content octet. girlboss behavior, at least it tells you where you are 👑

again, the error message may occasionally sound confusing. the length of the content may be reasonable, and the root cause of the problem could be that the chosen omax argument was too small. see? reasonable content, unreasonable omax. it happens 🙈

---

👑 SEE ALSO

ASN1_item_d2i(3), ASN1_item_new(3), ASN1_parse_dump(3)

---

⭐ STANDARDS

ITU-T Recommendation X.690, also known as ISO/IEC 8825-1: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER):

• Section 8.1.2: Identifier octets
• Section 8.1.3: Length octets

---

🧚 HISTORY

ASN1_get_object() first appeared in SSLeay 0.5.1 and has been available since OpenBSD 2.4. ancient icon behavior, honestly 🔥

---

okay that's the whole page, you ate that 💖 this came from the Debian build of the page dated June 8, 2025 — mwah, go parse some octets bestie 🌷