X509_KEYID_SET1(3)

💅 X509_KEYID_SET1(3) — like, the whole page, bestie

okay so this is from the libcrypto library manual, and honestly? it's giving "niche PKCS#12 glow-up" and I'm obsessed. grab your iced coffee, we're learning about auxiliary certificate data for PKCS#12 ✨

---

🌸 NAME 🌸

X509_keyid_set1, X509_keyid_get0, X509_alias_set1, X509_alias_get0 — auxiliary certificate data for PKCS#12 🎀

---

🦋 SYNOPSIS 🦋

bestie. the library is libcrypto, and you gotta include this first, no cap:

#include <openssl/x509.h>

then the four icons themselves:

int
X509_keyid_set1(X509 *x, const unsigned char *data, int len);

unsigned char *
X509_keyid_get0(X509 *x, int *plen);

int
X509_alias_set1(X509 *x, const unsigned char *data, int len);

unsigned char *
X509_alias_get0(X509 *x, int *plen);

---

💖 DESCRIPTION 💖

so these functions literally just store non-standard auxiliary data in x and then go get it back. that's the whole vibe. 💅

the len bytes of data that you store with X509_keyid_set1() will get written to the localKeyID attribute of the PKCS#12 structure if PKCS12_create(3) is later called on x. and the data you store with X509_alias_set1() gets written to the friendlyName attribute. cute, right? 🎀

pro tip (it's in the manual so it's legit): if data points to a NUL-terminated string, you can pass -1 as the len argument and let len be calculated internally using strlen(3). main character energy, honestly.

and if you pass a NULL pointer as the data argument? the respective auxiliary data stored in x, if any, is removed from x and freed. bye bestie 👋

conversely (love that word), PKCS12_parse(3) retrieves these attributes from a PKCS#12 structure so they can subsequently be accessed with X509_keyid_get0() and X509_alias_get0(). unless NULL is passed for the plen argument, these functions store the size of the returned buffer in bytes in *plen. 🫶

⚠️ important vibe check: after the call, the returned buffer is not necessarily NUL-terminated, but it may contain internal NUL bytes. so like, don't assume it's a cute little string, okay? 😭

and now for the spicy take that lives rent-free in my head: API design is very incomplete; given the complexity of PKCS#12, that's probably an asset rather than a defect. (the manpage said it, not me!!) the PKCS#12 standard defines many attributes that cannot be stored in X509 objects. 💀

to associate certificates with alternative names and key identifiers, X.509 certificate extensions are more commonly used than PKCS#12 attributes — for example using X509_EXTENSION_create_by_NID(3) with NID_subject_alt_name or NID_subject_key_identifier. slay. ⭐

---

🔥 RETURN VALUES 🔥

X509_keyid_set1() and X509_alias_set1() return 1 if data is NULL or if the input data was successfully copied into x, or 0 if data is not NULL but could not be copied because x is NULL or memory allocation failed. so like, 0 = the vibe check failed, basically. 💀

X509_keyid_get0() and X509_alias_get0() return an internal pointer to an array of bytes, or NULL if x does not contain auxiliary data of the requested kind. 🙈

---

🌈 SEE ALSO 🌈

• ASN1_STRING_set(3)
• X509_CERT_AUX_new(3)
• X509_EXTENSION_new(3)
• X509_new(3)
• X509V3_get_d2i(3)

---

👑 HISTORY 👑

• X509_alias_set1() and X509_alias_get0() first appeared in OpenSSL 0.9.5 and have been available since OpenBSD 2.7. 🧚
• X509_keyid_set1() first appeared in OpenSSL 0.9.6 and have been available since OpenBSD 2.9. 🦋
• X509_keyid_get0() first appeared in OpenSSL 0.9.8 and have been available since OpenBSD 4.5. ✨

---

and that's the whole page, bestie, you ate that 🍓 this little Debian-flavored gem is dated June 8, 2025, so go forth and set your keyids responsibly 💜 periodt.