X509V3_EXT_PRINT(3)

💅 X509V3_EXT_PRINT(3) — bestie edition

okay so this is the page for X509V3_EXT_print and X509V3_EXT_print_fp from the libcrypto library manual — yes, that libcrypto — and we're gonna pretty-print an X.509 extension together. grab a strawberry drink, this is actually so fun 🍓✨

---

✨ NAME ✨

X509V3_EXT_print, X509V3_EXT_print_fp — pretty-print an X.509 extension 💅

🌸 SYNOPSIS 🌸

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

int
X509V3_EXT_print(BIO *bio, X509_EXTENSION *ext, unsigned long flags,
    int indent);

int
X509V3_EXT_print_fp(FILE *file, X509_EXTENSION *ext, int flags,
    int indent);

🦋 DESCRIPTION 🦋

so X509V3_EXT_print() and X509V3_EXT_print_fp() both take ext, decode it, and print the data inside it — to the bio or the file respectively — in a human-readable format, with a left margin of indent space characters. 🫶

and like, the details of both the decoding and the printing depend on the type of ext. no cap.

🎀 the decoding situation

for most extension types, the decoding is done the exact same way it would be done by the appropriate public API function, for example:

• NID_authority_key_identifier → d2i_AUTHORITY_KEYID(3)
• NID_certificate_policies → d2i_CERTIFICATEPOLICIES(3)
• NID_crl_number → d2i_ASN1_INTEGER(3)
• NID_crl_reason → d2i_ASN1_ENUMERATED(3)
• NID_hold_instruction_code → d2i_ASN1_OBJECT(3)
• NID_id_pkix_OCSP_CrlID → d2i_OCSP_CRLID(3)
• NID_id_pkix_OCSP_noCheck → d2i_ASN1_NULL(3)
• NID_id_pkix_OCSP_Nonce → non-public function built into the library
• NID_invalidity_date → d2i_ASN1_GENERALIZEDTIME(3)
• NID_key_usage → d2i_ASN1_BIT_STRING(3)
• NID_subject_alt_name → d2i_GENERAL_NAMES(3)
• NID_subject_key_identifier → d2i_ASN1_OCTET_STRING(3)

👑 the printing situation

for some types, the printing is performed by a dedicated non-public function built into the library. for some other types, the printing function is a public API function, for example:

• NID_crl_number → i2s_ASN1_INTEGER(3)
• NID_crl_reason → i2s_ASN1_ENUMERATED_TABLE(3)
• NID_delta_crl → i2s_ASN1_INTEGER(3)
• NID_hold_instruction_code → i2a_ASN1_OBJECT(3)
• NID_id_pkix_OCSP_archiveCutoff → ASN1_GENERALIZEDTIME_print(3)
• NID_id_pkix_OCSP_Nonce → i2a_ASN1_STRING(3)
• NID_inhibit_any_policy → i2s_ASN1_INTEGER(3)
• NID_invalidity_date → ASN1_GENERALIZEDTIME_print(3)
• NID_key_usage → i2v_ASN1_BIT_STRING(3)
• NID_subject_key_identifier → i2s_ASN1_OCTET_STRING(3)

ngl, some of the public printing functions are not documented yet. 😭 (it's giving "we'll get to it", and honestly? same.)

🧚 the unknown / broken extension lore

if ext is of an unknown extension type, or if decoding fails while using the decoding function for the relevant type, the action taken depends on the flags argument:

• If the bit X509V3_EXT_PARSE_UNKNOWN is set, ASN1_parse_dump(3) is called on the BER-encoded data of the extension, passing -1 for the dump argument. so like, some info about the encoding of the extension gets printed and some about its decoded content, falling back to BIO_dump_indent(3) for the decoded content unless a dedicated printing method is known for the respective data type(s). and note — even if an extension type is unknown, the data type used by the unknown extension, or, if that data type is constructed, of the values contained in it, may still be known, which may allow printing the content of even an unknown extension in a structured or partially structured form. slay, honestly. ✨
• If the bit X509V3_EXT_DUMP_UNKNOWN is set, BIO_dump_indent(3) is called on the BER-encoded data of the extension without decoding it first, which is usually less readable than the above but poses a smaller risk of omitting or misrepresenting parts of the information.
• If the bit X509V3_EXT_ERROR_UNKNOWN is set, only the fixed string "<Not Supported>" is printed for an unknown type, or only the fixed string "<Parse Error>" if the parsing function fails — but printing is considered as successful anyway. 🙈
• If more than one of these three bits is set, or if a bit in X509V3_EXT_UNKNOWN_MASK is set that is not listed above, nothing is printed, but printing is considered as successful anyway.
• If none of the bits in X509V3_EXT_UNKNOWN_MASK are set, nothing is printed and printing is considered as failed.

💀 lowkey the mask logic is the main character here, k? read it twice, iykyk.

⭐ RETURN VALUES ⭐

X509V3_EXT_print() and X509V3_EXT_print_fp() return 0 if failure was both detected and considered relevant. otherwise, 1 is returned — and in general the user cannot tell whether failure simply went undetected, whether the function detected failure but regarded it as irrelevant, or whether printing did indeed succeed. 😭 yeah. it's that kind of vibe check.

🌈 SEE ALSO 🌈

• BIO_new(3)
• X509_EXTENSION_new(3)
• X509_get0_extensions(3)
• X509_get_ext(3)
• X509V3_extensions_print(3)

💜 HISTORY 💜

these functions first appeared in OpenSSL 0.9.2 and have been available since OpenBSD 2.6. iconic longevity behavior, fr fr. 👑

🔥 BUGS 🔥

these functions lack error handling throughout. when a write operation fails, they will usually ignore the fact that information was omitted from the output and report success to the caller anyway. 🫠

🚨 for real though — that's a real caveat, not just me being dramatic. write fails, info goes missing, function still says "we're so good". watch out.

---

and that's the page, bestie 🎀 this one's from the Debian build of the manual, dated June 8, 2025 — X509V3_EXT_PRINT(3), signing off 💖✨🦋