X509_VERIFY_PARAM_NEW(3)
๐ X509_VERIFY_PARAM_NEW โ like, the whole X509 verification parameter object saga
okay bestie, so this is the X509_VERIFY_PARAM_NEW(3) page from the library functions manual, and it's literally all about X509 verification parameter objects โ the little config blobs that tell certificate verification how to behave. buckle up ๐
โจ NAME โจ
X509_VERIFY_PARAM_new, X509_VERIFY_PARAM_inherit, X509_VERIFY_PARAM_set1, X509_VERIFY_PARAM_free, X509_VERIFY_PARAM_add0_table, X509_VERIFY_PARAM_lookup, X509_VERIFY_PARAM_get_count, X509_VERIFY_PARAM_get0, X509_VERIFY_PARAM_table_cleanup โ X509 verification parameter objects ๐ฆ
๐ธ SYNOPSIS ๐ธ
#include <openssl/x509_vfy.h>
X509_VERIFY_PARAM *
X509_VERIFY_PARAM_new(void);
int
X509_VERIFY_PARAM_inherit(X509_VERIFY_PARAM *destination,
const X509_VERIFY_PARAM *source);
int
X509_VERIFY_PARAM_set1(X509_VERIFY_PARAM *destination,
const X509_VERIFY_PARAM *source);
void
X509_VERIFY_PARAM_free(X509_VERIFY_PARAM *param);
int
X509_VERIFY_PARAM_add0_table(X509_VERIFY_PARAM *param);
const X509_VERIFY_PARAM *
X509_VERIFY_PARAM_lookup(const char *name);
int
X509_VERIFY_PARAM_get_count(void);
const X509_VERIFY_PARAM *
X509_VERIFY_PARAM_get0(int id);
void
X509_VERIFY_PARAM_table_cleanup(void);
๐ DESCRIPTION ๐
X509_VERIFY_PARAM_new() allocates and initializes an empty X509_VERIFY_PARAM object. brand new, fresh out the box โจ
X509_VERIFY_PARAM_inherit() copies some data from the source object to the destination object. not all of it, bestie โ some. ๐
The verification flags set with X509_VERIFY_PARAM_set_flags(3) in the source object are always OR'ed into the verification flags of the destination object. always. no exceptions, periodt.
Fields having their default value in the source object are not copied. if it's already default, it's not invited to the party ๐
By default, fields in the destination object already having a non-default value are not overwritten. BUT โ and this is the plot twist โ if at least one of the source or destination objects was created during a call to X509_STORE_CTX_init(3) that did not have a store argument, and if that object was not previously used as the destination in an earlier call to X509_VERIFY_PARAM_inherit(), this restriction is waived and even non-default fields in the destination object get overwritten. If fields overwritten in this way contain pointers to allocated memory, that memory is freed. so yeah, memory management main character energy ๐ญ
As far as permitted by the above rules, the following fields are copied:
- the verification purpose identifier set with
X509_VERIFY_PARAM_set_purpose(3) - the trust setting set with
X509_VERIFY_PARAM_set_trust(3) - the verification time set with
X509_VERIFY_PARAM_set_time(3); in this case, the only condition is thatX509_V_FLAG_USE_CHECK_TIMEis not set in thedestinationobject, whereas the time value in thedestinationobject is not inspected before overwriting it ๐ - the acceptable policy set with
X509_VERIFY_PARAM_set1_policies(3) - the maximum verification depth set with
X509_VERIFY_PARAM_set_depth(3) - flags that were set with
X509_VERIFY_PARAM_set_hostflags(3) - the list of expected DNS hostnames built with
X509_VERIFY_PARAM_set1_host(3)andX509_VERIFY_PARAM_add1_host(3) - the expected RFC 822 email address set with
X509_VERIFY_PARAM_set1_email(3) - the expected IP address set with
X509_VERIFY_PARAM_set1_ip(3)orX509_VERIFY_PARAM_set1_ip_asc(3)
Some data that may be contained in the source object is never copied โ for example the subject name of the peer certificate that can be retrieved with X509_VERIFY_PARAM_get0_peername(3). sorry girl, that one's staying home ๐
If source is a NULL pointer, the function has no effect but returns successfully. slay, no crash, we love a graceful no-op ๐ซถ
X509_VERIFY_PARAM_set1() is identical to X509_VERIFY_PARAM_inherit() except that fields in the destination object are overwritten even if they do not match their default values. Still, fields having their default value in the source object are not copied. so it's the more aggressive version, basically inherit with a gym membership ๐ฅ
โ ๏ธ IfX509_VERIFY_PARAM_inherit()orX509_VERIFY_PARAM_set1()fail, partial copying may have occurred, so all data in thedestinationobject should be regarded as invalid. like, do not trust it, do not look at it, it's giving corrupted vibes ๐ญ
X509_VERIFY_PARAM_inherit() is used internally by X509_STORE_CTX_init(3) and by X509_STORE_CTX_set_default(3), and X509_VERIFY_PARAM_set1() is used internally by X509_STORE_set1_param(3). iykyk ๐
X509_VERIFY_PARAM_free() clears all data contained in param and releases all memory used by it. If param is a NULL pointer, no action occurs. clean, simple, no drama ๐
X509_VERIFY_PARAM_add0_table() adds param to a static list of X509_VERIFY_PARAM objects maintained by the library.
๐ this function is EXTREMELY DANGEROUS because โ contrary to the name of the function โ if the list already contains an object that happens to have the same name, that old object is not only silently removed from the list, but also silently freed, which may silently invalidate various pointers existing elsewhere in the program. not me reading this and screaming. fr fr, be careful.
X509_VERIFY_PARAM_lookup() searches this list for an object of the given name. If no match is found, the predefined objects built-in to the library are also inspected. ๐
X509_VERIFY_PARAM_get_count() returns the sum of the number of objects on this list and the number of predefined objects built-in to the library. Note that this is not necessarily the total number of X509_VERIFY_PARAM objects existing in the program, because there may be additional such objects that were never added to the list. math is mathing but only partially ๐งฎ
X509_VERIFY_PARAM_get0() accesses predefined and user-defined objects using id as an index, useful for looping over objects without knowing their names. An argument less than the number of predefined objects selects one of the predefined objects; a higher argument selects an object from the list. perfect for a little for loop moment ๐
๐ X509_VERIFY_PARAM_table_cleanup() deletes all objects from this list. It is extremely dangerous because it also invalidates all data that was contained in all objects that were on the list and because it frees all these objects, which may invalidate various pointers existing elsewhere in the program. this one ate and also destroyed everything, lowkey terrifying ๐
โญ RETURN VALUES โญ
X509_VERIFY_PARAM_new()returns a pointer to the new object, orNULLon allocation failure.X509_VERIFY_PARAM_inherit(),X509_VERIFY_PARAM_set1(), andX509_VERIFY_PARAM_add0_table()return1for success or0for failure.X509_VERIFY_PARAM_lookup()andX509_VERIFY_PARAM_get0()return a pointer to an existing built-in or user-defined object, orNULLif no object with the givennameis found, or ifidis at leastX509_VERIFY_PARAM_get_count().X509_VERIFY_PARAM_get_count()returns a number of objects.
๐ฆ SEE ALSO ๐ฆ
SSL_set1_param(3), X509_STORE_CTX_set0_param(3), X509_STORE_set1_param(3), X509_verify_cert(3), X509_VERIFY_PARAM_set_flags(3)
go read those next bestie, the lore goes deep ๐ซถ
๐ HISTORY ๐
X509_VERIFY_PARAM_new(), X509_VERIFY_PARAM_inherit(), X509_VERIFY_PARAM_set1(), X509_VERIFY_PARAM_free(), X509_VERIFY_PARAM_add0_table(), X509_VERIFY_PARAM_lookup(), and X509_VERIFY_PARAM_table_cleanup() first appeared in OpenSSL 0.9.8 and have been available since OpenBSD 4.5. vintage icon behavior โจ
X509_VERIFY_PARAM_get_count() and X509_VERIFY_PARAM_get0() first appeared in OpenSSL 1.0.2 and have been available since OpenBSD 6.3. the newer babies of the family ๐
and that's the whole page, bestie ๐ this was the Debian edition, dated May 24, 2023 โ go forth and verify those params responsibly, mwah ๐ง๐
๐ฆ where this page comes from
- opensuse-leap 16.0: libressl-devel-doc 4.1.0-bp160.1.1 ยท OpenSSL
- Copyright (c) 2018, 2021 Ingo Schwarze <schwarze@openbsd.org>
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms