PEM_READ(3SSL)

📦
version 4.0.3 · 14 versions
, in ubuntu stonking

💖 NAME 💖

okay so bestie, meet the PEM squad: PEM_read, PEM_read_bio, PEM_do_header, PEM_get_EVP_CIPHER_INFO, PEM_write, PEM_write_bio, PEM_ASN1_write, PEM_ASN1_write_bio, and PEM_ASN1_write_bio_ctx — they're the PEM encoding routines, aka the ones doing all the ✨ heavy lifting ✨ so you don't have to. (This is from the OpenSSL manual, section 3SSL, iykyk.)

✨ SYNOPSIS ✨

#include <openssl/pem.h>

int PEM_read(FILE *fp, char **name, char **header,
             unsigned char **data, long *len);
int PEM_read_bio(BIO *bp, char **name, char **header,
                 unsigned char **data, long *len);

int PEM_get_EVP_CIPHER_INFO(char *header, EVP_CIPHER_INFO *cinfo);
int PEM_do_header(EVP_CIPHER_INFO *cinfo, unsigned char *data, long *len,
                  pem_password_cb *cb, void *u);

int PEM_write(FILE *fp, const char *name, const char *header,
              const unsigned char *data, long len);
int PEM_write_bio(BIO *bp, const char *name, const char *header,
                  const unsigned char *data, long len);
int PEM_ASN1_write(i2d_of_void *i2d, const char *name, FILE *fp,
                   const void *x, const EVP_CIPHER *enc,
                   const unsigned char *kstr, int klen,
                   pem_password_cb *callback, void *u);
int PEM_ASN1_write_bio(i2d_of_void *i2d, const char *name, BIO *bp,
                       const void *x, const EVP_CIPHER *enc,
                       const unsigned char *kstr, int klen,
                       pem_password_cb *callback, void *u);
int PEM_ASN1_write_bio_ctx(OSSL_i2d_of_void_ctx *i2d, void *vctx,
                           const char *name, BIO *bp, const void *x,
                           const EVP_CIPHER *enc, const unsigned char *kstr,
                           int klen, pem_password_cb *callback, void *u);

🌸 DESCRIPTION 🌸

So these functions read and write PEM-encoded objects. They work with the PEM type name, whatever extra header info comes along for the ride, and the raw data of length len. Simple as that, no cap. 🫶

PEM is the term for binary content encoding, and it was first defined in IETF RFC 1421. The content is literally just a series of base64-encoded lines, wrapped up by begin/end markers, each marker chillin' on its own line. Like this:

-----BEGIN PRIVATE KEY-----
MIICdg....
... bhTQ==
-----END PRIVATE KEY-----

Optional header line(s) may show up after the begin line, and whether they exist depends on the type of object being written or read. It's giving mysterious ✨

PEM_write() writes to the file fp, and PEM_write_bio() writes to the BIO bp. The name is what you use in the marker, the header is the header value or NULL, and data plus len specify the data and its length. 💅

The final data buffer is typically an ASN.1 object, which you can decode with the d2i function that matches the type name — peep d2i_X509(3) for examples. 📚

PEM_read() reads from the file fp, and PEM_read_bio() reads from the BIO bp. Both of them skip any non-PEM data hanging out before the start of the next PEM object. (They're so unbothered.) When an object gets successfully retrieved:

  • the type name from the "----BEGIN <type>-----" comes back through the name argument
  • any encapsulation headers come back in header
  • the base64-decoded content and its length come back via data and len respectively

The name, header and data pointers are allocated via OPENSSL_malloc(), so you (yes you, bestie) have to free them with OPENSSL_free() when they're no longer needed. Don't be a memory leaker, that's not the vibe. 🙈

PEM_get_EVP_CIPHER_INFO() is the detective 🔍 — you can use it to figure out whether the data returned by PEM_read() or PEM_read_bio() is encrypted, and to retrieve the associated cipher and IV. The caller passes a pointer to a structure of type EVP_CIPHER_INFO via the cinfo argument, plus the header returned via PEM_read() or PEM_read_bio(). If the call succeeds, 1 is returned and the cipher and IV get stored at the address that cinfo points to. When the header is malformed, or not supported, or when the cipher is unknown, or when some internal error happens → 0 is returned. This function is deprecated, see NOTES below. 💀

PEM_do_header() can then be used to decrypt the data if the header says it's encrypted. The cinfo argument is a pointer to the structure that got initialized by the previous call to PEM_get_EVP_CIPHER_INFO(). The data and len arguments are those returned by the previous call to PEM_read() or PEM_read_bio(). The cb and u arguments make it possible to override the default password prompt function, as described in PEM_read_PrivateKey(3). On successful completion the data is decrypted in place, and len is updated to indicate the plaintext length. This function is deprecated too, see NOTES below. 😭

And if the data is a priori known to not be encrypted? Then you don't need to call PEM_do_header() or PEM_get_EVP_CIPHER_INFO() at all. Save yourself the steps, queen. 👑

🌈 RETURN VALUES 🌈

PEM_read(), and PEM_read_bio() return 1 on success and 0 on failure — and yes, that failure case includes when there are no more PEM objects left in the input file. 😬 To tell the difference between "yay we're done" end-of-file and more serious errors, the caller must peek at the error stack and check for PEM_R_NO_START_LINE, which indicates that no more PEM objects were found. See ERR_peek_last_error(3), ERR_GET_REASON(3).

PEM_get_EVP_CIPHER_INFO() and PEM_do_header() return 1 on success, and 0 on failure. And heads up: the data is likely meaningless if these functions fail. 🫠

🎀 NOTES 🎀

PEM_get_EVP_CIPHER_INFO() and PEM_do_header() are deprecated. Why, you ask? Because the underlying PEM encryption format is obsolete and should be avoided entirely. It uses an encryption format with an OpenSSL-specific key-derivation function, which employs MD5 with an iteration count of 1! 😱 Not the flex. Instead, private keys should be stored in PKCS#8 form, with a strong PKCS#5 v2.0 PBE. See PEM_write_PrivateKey(3) and d2i_PKCS8PrivateKey_bio(3).

PEM_do_header() makes no assumption regarding the pass phrase received from the password callback. It will simply be treated as a byte sequence. Periodt. 💅

PEM_write() and PEM_write_bio() return the number of encoded bytes (not counting the PEM header and end marker) written on success, or 0 on failure. ✍️

PEM_ASN1_write_bio(), and PEM_ASN1_write_bio_ctx() return 1 on success and 0 on failure. The latter function passes an additional application-provided context value to the i2d function that serialises the input ASN.1 object. 🦋

🦋 SEE ALSO 🦋

⭐ HISTORY ⭐

The PEM_ASN1_write_bio_ctx() function was added in OpenSSL 3.5. ✨ (She's new here but she's already slaying.)

Copyright 1998-2025 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, no crumbs left 🍓 version 4.0.3, dated 2026-09-29 — go forth and encode responsibly, mwah 💖🧚

📦 where this page comes from