X509_STORE_CTX_NEW(3SSL)

📦

version 4.0.3 · 14 versions

🎀 X509_STORE_CTX_NEW 🎀

ok so bestie, this is the X509_STORE_CTX_NEW(3SSL) page from the OpenSSL manual, and it's a whole squad of functions that get an X509_STORE_CTX all set up and ready for certificate verification. She's long, so she comes in 2 parts — this is part 1 💅

✨ NAME ✨

X509_STORE_CTX_new_ex, X509_STORE_CTX_new, X509_STORE_CTX_cleanup, X509_STORE_CTX_free, X509_STORE_CTX_init, X509_STORE_CTX_init_rpk, X509_STORE_CTX_set0_trusted_stack, X509_STORE_CTX_set_cert, X509_STORE_CTX_set0_crls, X509_STORE_CTX_set0_rpk, X509_STORE_CTX_get0_param, X509_STORE_CTX_set0_param, X509_STORE_CTX_get0_untrusted, X509_STORE_CTX_set0_untrusted, X509_STORE_CTX_get_num_untrusted, X509_STORE_CTX_get0_chain, X509_STORE_CTX_set0_verified_chain, X509_STORE_CTX_get0_rpk, X509_STORE_CTX_set_default, X509_STORE_CTX_set_verify, X509_STORE_CTX_verify_fn, X509_STORE_CTX_set_ocsp_resp, X509_STORE_CTX_set_purpose, X509_STORE_CTX_set_trust, X509_STORE_CTX_purpose_inherit — a.k.a. X509_STORE_CTX initialisation 🦋

🌸 SYNOPSIS 🌸

#include <openssl/x509_vfy.h>

X509_STORE_CTX *X509_STORE_CTX_new_ex(OSSL_LIB_CTX *libctx, const char *propq);
X509_STORE_CTX *X509_STORE_CTX_new(void);
void X509_STORE_CTX_cleanup(X509_STORE_CTX *ctx);
void X509_STORE_CTX_free(X509_STORE_CTX *ctx);

int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *trust_store,
                        X509 *target, STACK_OF(X509) *untrusted);
int X509_STORE_CTX_init_rpk(X509_STORE_CTX *ctx, X509_STORE *trust_store,
                            EVP_PKEY *rpk);

void X509_STORE_CTX_set0_trusted_stack(X509_STORE_CTX *ctx, STACK_OF(X509) *sk);

void X509_STORE_CTX_set_cert(X509_STORE_CTX *ctx, X509 *target);
void X509_STORE_CTX_set0_crls(X509_STORE_CTX *ctx, STACK_OF(X509_CRL) *sk);
void X509_STORE_CTX_set0_rpk(X509_STORE_CTX *ctx, EVP_PKEY *target);

X509_VERIFY_PARAM *X509_STORE_CTX_get0_param(const X509_STORE_CTX *ctx);
void X509_STORE_CTX_set0_param(X509_STORE_CTX *ctx, X509_VERIFY_PARAM *param);

STACK_OF(X509)* X509_STORE_CTX_get0_untrusted(const X509_STORE_CTX *ctx);
void X509_STORE_CTX_set0_untrusted(X509_STORE_CTX *ctx, STACK_OF(X509) *sk);

int X509_STORE_CTX_get_num_untrusted(const X509_STORE_CTX *ctx);
STACK_OF(X509) *X509_STORE_CTX_get0_chain(const X509_STORE_CTX *ctx);
void X509_STORE_CTX_set0_verified_chain(X509_STORE_CTX *ctx, STACK_OF(X509) *chain);
EVP_PKEY *X509_STORE_CTX_get0_rpk(const X509_STORE_CTX *ctx);

int X509_STORE_CTX_set_default(X509_STORE_CTX *ctx, const char *name);
typedef int (*X509_STORE_CTX_verify_fn)(X509_STORE_CTX *);
void X509_STORE_CTX_set_verify(X509_STORE_CTX *ctx, X509_STORE_CTX_verify_fn verify);

void X509_STORE_CTX_set_ocsp_resp(X509_STORE_CTX *ctx, STACK_OF(OCSP_RESPONSE) *sk);
int X509_STORE_CTX_set_purpose(X509_STORE_CTX *ctx, int purpose);
int X509_STORE_CTX_set_trust(X509_STORE_CTX *ctx, int trust);
int X509_STORE_CTX_purpose_inherit(X509_STORE_CTX *ctx, int def_purpose,
                                   int purpose, int trust);

💖 DESCRIPTION 💖

ok so real talk: these functions are the get-ready-with-me routine for an X509_STORE_CTX structure, so that afterwards X509_verify_cert(3) or X509_STORE_CTX_verify(3) can actually do their thing. 🫶

X509_STORE_CTX_new_ex() — hands you back a newly initialised X509_STORE_CTX structure, tied to the library context libctx and the property query string propq you passed in. Any cryptographic algorithms that get fetched while this X509_STORE_CTX is doing its processing will use that library context and property query string. it's giving contextual ✨
X509_STORE_CTX_new() — literally the same as X509_STORE_CTX_new_ex(), except it uses the default library context and a NULL property query string. that's the whole difference, no cap.
X509_STORE_CTX_cleanup() — internally cleans up an X509_STORE_CTX structure. It's used by X509_STORE_CTX_init() and X509_STORE_CTX_free(). it's the behind-the-scenes bestie 🧚
X509_STORE_CTX_free() — completely frees up ctx. After this call ctx is no longer valid. (crying, throwing up 😭) If ctx is NULL, nothing is done. no drama, no crash.

🦋 setting up ctx for verification 🦋

X509_STORE_CTX_init() sets up ctx for a subsequent verification operation, and it also initializes the internal state and resources of the given ctx. Among others, it sets the verification parameters associated with the method name "default", which includes the "any" purpose, and it takes over callback function pointers from trust_store (unless that's NULL).

ok so this is the part you cannot skip: it must be called before each call to X509_verify_cert(3) or X509_STORE_CTX_verify(3), i.e., a context is only good for one verification. Wanna verify a further certificate or chain with the same ctx? You gotta call X509_STORE_CTX_init() again. periodt.

The trusted certificate store gets set to trust_store, which is of type X509_STORE. That one may be NULL — either because there are no trusted certificates, or because they're just being provided as a list using X509_STORE_CTX_set0_trusted_stack(). The certificate to be verified gets set to target, and a list of additional certificates can be handed over in untrusted — those will be untrusted, but they may be used to build the chain.

The target certificate is not copied (its reference count is not updated), and the caller must not free it before verification is complete. 🙈

Each of the trust_store, target and untrusted parameters can be NULL. But heads up: X509_verify_cert(3) and X509_STORE_CTX_verify(3) will need a verification target. This can also be set using X509_STORE_CTX_set_cert(). For X509_STORE_CTX_verify(3), which takes by default the first element of the list of untrusted certificates as its verification target, this can also be set indirectly using X509_STORE_CTX_set0_untrusted().

X509_STORE_CTX_init_rpk() sets up ctx for a subsequent verification operation for the target raw public key. It behaves similarly to X509_STORE_CTX_init(). The target raw public key can also be supplied separately, via X509_STORE_CTX_set0_rpk(). The target public key is not copied (its reference count is not updated), and the caller must not free it before verification is complete. 🔑

X509_STORE_CTX_set0_trusted_stack() sets the set of trusted certificates of ctx to sk. This is an alternative way of specifying trusted certificates instead of using an X509_STORE — handy when its complexity is not needed, or to make sure that only the given set sk of certificates are trusted. 👑

X509_STORE_CTX_set_cert() sets the target certificate to be verified in ctx to target. Again: the target certificate is not copied (its reference count is not updated), and the caller must not free it before verification is complete.

X509_STORE_CTX_set0_rpk() sets the target raw public key to be verified in ctx to target. A non-NULL raw public key preempts any target certificate, which is then simply ignored. The target public key is not copied (its reference count is not updated), and the caller must not free it before verification is complete. ✨

X509_STORE_CTX_set0_verified_chain() sets the validated chain to chain. Ownership of the chain is transferred to ctx, and so it should not be free'd by the caller. it's hers now, bestie 💅

X509_STORE_CTX_get0_chain() returns the internal pointer used by the ctx that contains the constructed (output) chain.

X509_STORE_CTX_get0_rpk() returns the internal pointer used by the ctx that contains the raw public key.

X509_STORE_CTX_set0_crls() sets a set of CRLs to use to aid certificate verification to sk. These CRLs will only be used if CRL verification is enabled in the associated X509_VERIFY_PARAM structure. This might be used where additional "useful" CRLs are supplied as part of a protocol — for example in a PKCS#7 structure. 🍓

X509_STORE_CTX_get0_param() retrieves an internal pointer to the verification parameters associated with ctx.

X509_STORE_CTX_set0_param() sets the internal verification parameter pointer to param. After this call, param should not be used. (it belongs to ctx now, sorry 🫶)

X509_STORE_CTX_get0_untrusted() retrieves an internal pointer to the stack of untrusted certificates associated with ctx.

X509_STORE_CTX_set0_untrusted() sets the internal pointer to the stack of untrusted certificates associated with ctx to sk. X509_STORE_CTX_verify() will take the first element, if any, as its default target if the target certificate is not set explicitly.

X509_STORE_CTX_get_num_untrusted() returns the number of untrusted certificates that were used in building the chain. This is can be used after calling X509_verify_cert(3) and similar functions. With X509_STORE_CTX_verify(3), this does not count the first chain element. 🔢

X509_STORE_CTX_get0_chain() returns the internal pointer used by the ctx that contains the validated chain.

Details of the chain building and checking process are described in "Certification Path Building" in openssl-verification-options(1) and "Certification Path Validation" in openssl-verification-options(1).

X509_STORE_CTX_set0_verified_chain() sets the validated chain used by ctx to be chain. Ownership of the chain is transferred to ctx, and so it should not be free'd by the caller. (yes, she gets mentioned twice — icon behavior, we don't make the rules 💀)

🎀 methods, verify functions & vibes 🎀

X509_STORE_CTX_set_default() looks up and sets the default verification method. This uses the function X509_VERIFY_PARAM_lookup() to find the set of parameters associated with the given verification method name. Among others, the parameters determine the trust model and verification purpose. More detail, including the list of currently predefined methods, is described for the -verify_name command-line option in "Verification Options" in openssl-verification-options(1).

X509_STORE_CTX_set_verify() provides the capability for overriding the default verify function. This function is responsible for verifying chain signatures and expiration times. ⏰

A verify function is defined as an X509_STORE_CTX_verify type which has the following signature:

int (*verify)(X509_STORE_CTX *);

This function should receive the current X509_STORE_CTX as a parameter and return 1 on success or 0 on failure. simple as that, fr fr.

👑 purposes & trust (the meta bit) 👑

ok this next part is a whole vibe, stay with me. X509 certificates may contain information about what purposes keys contained within them can be used for. For example "TLS WWW Server Authentication" or "Email Protection". This extended key usage information is held internally to the certificate itself.

In addition, the trust store containing trusted certificates can declare what purposes we trust different certificates for. This "trust" information is not held within the certificate itself, but is "meta" information held alongside it. This "meta" information is associated with the certificate after it is issued and could be determined by a system administrator. For example, a certificate might declare that it is suitable for use for both "TLS WWW Server Authentication" and "TLS Client Authentication", but a system administrator might only trust it for the former. Not me side-eyeing a cert that's doing too much 🙈

An X.509 certificate extension exists that can record extended key usage information to supplement the purpose information described above. This extended mechanism is arbitrarily extensible and not well suited for a generic library API; applications that need to validate extended key usage information in certificates will need to define a custom "purpose" (see below) or supply a nondefault verification callback (X509_STORE_set_verify_cb_func(3)). 🦋

okay so X509_STORE_CTX_set_ocsp_resp() 💫 drops the OCSP response(s) into the ctx — either for verifying a cert chain, or for sliding them into the TLS handshake when the client is out here requesting OCSP stapling. and bestie, listen: that stack of OCSP responses, sk, is not copied, it's literally just stored on the context. ctx holds a pointer to the stack, so the stack has to outlive the ctx or you're gonna have a bad time. 👑🫶

X509_STORE_CTX_set_purpose() sets the purpose for the target certificate being verified in the ctx. The built-in values for the purpose argument are:

X509_PURPOSE_SSL_CLIENT
X509_PURPOSE_SSL_SERVER
X509_PURPOSE_NS_SSL_SERVER
X509_PURPOSE_SMIME_SIGN
X509_PURPOSE_SMIME_ENCRYPT
X509_PURPOSE_CRL_SIGN
X509_PURPOSE_ANY
X509_PURPOSE_OCSP_HELPER
X509_PURPOSE_TIMESTAMP_SIGN
X509_PURPOSE_CODE_SIGN

and yes you can absolutely create a custom purpose value, we love options 💅. Setting a purpose requests that the key usage and extended key usage (EKU) extensions optionally declared inside the certificate and its chain get verified as consistent with that purpose. For SSL client, SSL server, and S/MIME purposes, the EKU is checked for the CA certificates along the chain too — including any given trust anchor certificate 👀. Potentially further checks happen as well (depending on the purpose you gave). Every purpose also comes with an associated default trust id, which gets set at the same time. During verification, that trust setting is checked against the trust the system administrator set for the certificates in the chain. no cap. ✨

X509_STORE_CTX_set_trust() sets the trust id value for the target certificate being verified in the ctx. Built-in values for the trust id argument are:

X509_TRUST_COMPAT
X509_TRUST_SSL_CLIENT
X509_TRUST_SSL_SERVER
X509_TRUST_EMAIL
X509_TRUST_OBJECT_SIGN
X509_TRUST_OCSP_SIGN
X509_TRUST_OCSP_REQUEST
X509_TRUST_TSA

Custom trust id? Also possible, go off 🎀. But here's the thing — since X509_STORE_CTX_set_purpose() also sets the trust id, calling just that one is normally enough. If you do call both, then X509_STORE_CTX_set_trust() should come after X509_STORE_CTX_set_purpose(), because the trust setting from the last call is the one that's used. order matters, bestie, always 🫡

lowkey it should not normally be necessary for end user applications to call X509_STORE_CTX_purpose_inherit() directly — typical applications call X509_STORE_CTX_set_purpose() or X509_STORE_CTX_set_trust() instead, iykyk. But using this function, you can set the purpose and trust id values for the ctx at the same time ✨. Both ctx and its internal verification parameter pointer must not be NULL 🚫. The def_purpose and purpose arguments can take the same purpose values as described for X509_STORE_CTX_set_purpose() above, and the trust argument can take the same trust ids as described in X509_STORE_CTX_set_trust() above. Any of def_purpose, purpose, or trust may also be the value 0, which means "ignore this parameter, thanks" 🙈.

After calling this function:

the purpose used for verification is set from the purpose argument — unless the purpose was already set in ctx before,
and the trust is set from the trust argument — unless the trust was already set in ctx before.

If trust is 0, then the trust id gets set from the default trust id for purpose. And if the default trust id for the purpose is X509_TRUST_DEFAULT and trust is 0, then the default trust id associated with the def_purpose value is used for the trust setting instead. nested defaults, she's layered like that 💅

📝 NOTES

The certificates and CRLs in a store are used internally and should not be freed up until after the associated X509_STORE_CTX is freed. put it down bestie, not yet 🫶

💀 BUGS

The certificates and CRLs in a context are used internally and should not be freed up until after the associated X509_STORE_CTX is freed. Copies should be made or reference counts increased instead. do not free them early, fr fr, it's giving undefined behaviour and we are NOT doing that today 😭

🔥 RETURN VALUES

X509_STORE_CTX_new() — returns a newly allocated context, or NULL if an error occurred.
X509_STORE_CTX_init() and X509_STORE_CTX_init_rpk() — return 1 for success, or 0 if an error occurred.
X509_STORE_CTX_get0_param() — returns a pointer to an X509_VERIFY_PARAM structure, or NULL if an error occurred.
X509_STORE_CTX_get0_rpk() — returns a pointer to an EVP_PKEY structure if present, or NULL if absent.
X509_STORE_CTX_cleanup(), X509_STORE_CTX_free(), X509_STORE_CTX_set0_trusted_stack(), X509_STORE_CTX_set_cert(), X509_STORE_CTX_set0_crls(), and X509_STORE_CTX_set0_param() — these ones do not return values. they just do the thing ✨
X509_STORE_CTX_set_default() — returns 1 for success, or 0 if an error occurred.
X509_STORE_CTX_get_num_untrusted() — returns the number of untrusted certificates used.

👀 SEE ALSO

🦋 HISTORY

The X509_STORE_CTX_set0_crls() function was added in OpenSSL 1.0.0.
The X509_STORE_CTX_get_num_untrusted() function was added in OpenSSL 1.1.0.
The X509_STORE_CTX_new_ex() function was added in OpenSSL 3.0.
The X509_STORE_CTX_init_rpk(), X509_STORE_CTX_get0_rpk(), and X509_STORE_CTX_set0_rpk() functions were added in OpenSSL 3.2.
The X509_STORE_CTX_set_ocsp_resp() function was added in OpenSSL 3.6.

and the glow-up nobody asked for but everybody needed: there is no need to call X509_STORE_CTX_cleanup() explicitly since OpenSSL 3.0. she's automatic now, main character energy 👑

💖 COPYRIGHT

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 a wrap on the whole page bestie!! 💖✨ this lil legend came from version 4.0.3, dated 2026-09-29, filed under X509_STORE_CTX_NEW(3SSL) — go forth and verify those chains responsibly, mwah 🎀🦋💅

📦 where this page comes from

ubuntu stonking: libssl-doc 4.0.3-1ubuntu1 · Apache-2.0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-03: a language model's rewrite of the original, under its terms