X509_VERIFY_PARAM_SET_FLAGS(3ossl)
π X509_VERIFY_PARAM_SET_FLAGS(3ossl) π
okay bestie, welcome to the OpenSSL man page for X509 verification parameters. This is part 1 of 2 and it's a whole journey, but we're gonna get through it together. π
β¨ NAME β¨
bestie, this page is the whole girlband of functions:
X509_VERIFY_PARAM_set_flagsX509_VERIFY_PARAM_clear_flagsX509_VERIFY_PARAM_get_flagsX509_VERIFY_PARAM_set_purposeX509_VERIFY_PARAM_get_purposeX509_VERIFY_PARAM_get_inh_flagsX509_VERIFY_PARAM_set_inh_flagsX509_VERIFY_PARAM_set_trustX509_VERIFY_PARAM_set_depthX509_VERIFY_PARAM_get_depthX509_VERIFY_PARAM_set_auth_levelX509_VERIFY_PARAM_get_auth_levelX509_VERIFY_PARAM_set_timeX509_VERIFY_PARAM_get_timeX509_VERIFY_PARAM_add0_policyX509_VERIFY_PARAM_set1_policiesX509_VERIFY_PARAM_get0_hostX509_VERIFY_PARAM_set1_hostX509_VERIFY_PARAM_add1_hostX509_VERIFY_PARAM_set_hostflagsX509_VERIFY_PARAM_get_hostflagsX509_VERIFY_PARAM_get0_peernameX509_VERIFY_PARAM_get0_emailX509_VERIFY_PARAM_set1_emailX509_VERIFY_PARAM_set1_ipX509_VERIFY_PARAM_get1_ip_ascX509_VERIFY_PARAM_set1_ip_asc
β and together they're all about X509 verification parameters. periodt. π
πΈ SYNOPSIS πΈ
#include <openssl/x509_vfy.h>
int X509_VERIFY_PARAM_set_flags(X509_VERIFY_PARAM *param,
unsigned long flags);
int X509_VERIFY_PARAM_clear_flags(X509_VERIFY_PARAM *param,
unsigned long flags);
unsigned long X509_VERIFY_PARAM_get_flags(const X509_VERIFY_PARAM *param);
int X509_VERIFY_PARAM_set_inh_flags(X509_VERIFY_PARAM *param,
uint32_t flags);
uint32_t X509_VERIFY_PARAM_get_inh_flags(const X509_VERIFY_PARAM *param);
int X509_VERIFY_PARAM_set_purpose(X509_VERIFY_PARAM *param, int purpose);
int X509_VERIFY_PARAM_get_purpose(X509_VERIFY_PARAM *param);
int X509_VERIFY_PARAM_set_trust(X509_VERIFY_PARAM *param, int trust);
void X509_VERIFY_PARAM_set_time(X509_VERIFY_PARAM *param, time_t t);
time_t X509_VERIFY_PARAM_get_time(const X509_VERIFY_PARAM *param);
int X509_VERIFY_PARAM_add0_policy(X509_VERIFY_PARAM *param,
ASN1_OBJECT *policy);
int X509_VERIFY_PARAM_set1_policies(X509_VERIFY_PARAM *param,
STACK_OF(ASN1_OBJECT) *policies);
void X509_VERIFY_PARAM_set_depth(X509_VERIFY_PARAM *param, int depth);
int X509_VERIFY_PARAM_get_depth(const X509_VERIFY_PARAM *param);
void X509_VERIFY_PARAM_set_auth_level(X509_VERIFY_PARAM *param,
int auth_level);
int X509_VERIFY_PARAM_get_auth_level(const X509_VERIFY_PARAM *param);
char *X509_VERIFY_PARAM_get0_host(X509_VERIFY_PARAM *param, int n);
int X509_VERIFY_PARAM_set1_host(X509_VERIFY_PARAM *param,
const char *name, size_t namelen);
int X509_VERIFY_PARAM_add1_host(X509_VERIFY_PARAM *param,
const char *name, size_t namelen);
void X509_VERIFY_PARAM_set_hostflags(X509_VERIFY_PARAM *param,
unsigned int flags);
unsigned int X509_VERIFY_PARAM_get_hostflags(const X509_VERIFY_PARAM *param);
char *X509_VERIFY_PARAM_get0_peername(const X509_VERIFY_PARAM *param);
char *X509_VERIFY_PARAM_get0_email(X509_VERIFY_PARAM *param);
int X509_VERIFY_PARAM_set1_email(X509_VERIFY_PARAM *param,
const char *email, size_t emaillen);
char *X509_VERIFY_PARAM_get1_ip_asc(X509_VERIFY_PARAM *param);
int X509_VERIFY_PARAM_set1_ip(X509_VERIFY_PARAM *param,
const unsigned char *ip, size_t iplen);
int X509_VERIFY_PARAM_set1_ip_asc(X509_VERIFY_PARAM *param, const char *ipasc);
π¦ DESCRIPTION π¦
okay so real talk β all these functions are out here manipulating the X509_VERIFY_PARAM structure, and that struct is literally the vibe controller for a certificate verification operation. π
X509_VERIFY_PARAM_set_flags() sets the flags in param by oring it with flags. Bestie, if you wanna know every single value that flags can take, go look at the "VERIFICATION FLAGS" section β it's all there, no cap.
X509_VERIFY_PARAM_get_flags() just hands you back the flags that are chillin' in param. β¨
X509_VERIFY_PARAM_get_inh_flags() returns the inheritance flags in param, which specify how verification flags get copied from one structure to another. X509_VERIFY_PARAM_set_inh_flags() sets those inheritance flags. Wanna know what all those bits mean? The INHERITANCE FLAGS section has the tea. π«
X509_VERIFY_PARAM_clear_flags() clears the flags specified by flags in param. bye bye, flags. π
X509_VERIFY_PARAM_set_purpose() sets the verification purpose in param to purpose. This is what decides the acceptable purpose of the certificate chain β like X509_PURPOSE_SSL_CLIENT, for example. And if purpose is X509_PURPOSE_DEFAULT_ANY, the purpose requirement gets cleared. periodt.
X509_VERIFY_PARAM_get_purpose() returns the purpose in param.
X509_VERIFY_PARAM_set_trust() sets the trust setting in param to trust. simple as that.
X509_VERIFY_PARAM_set_time() sets the verification time in param to t. Normally the current time is what's used, but you can override it if you need to. β°
X509_VERIFY_PARAM_add0_policy() adds policy to the acceptable policy set. And okay, important note: contrary to preexisting documentation of this function, it does not enable policy checking. Don't let the old docs gaslight you. π
X509_VERIFY_PARAM_set1_policies() enables policy checking (it's disabled by default, bestie) and sets the acceptable policy set to policies. Any existing policy set gets cleared. And the policies parameter can be NULL if you just wanna clear an existing policy set. π§Ή
X509_VERIFY_PARAM_set_depth() sets the maximum verification depth to depth. That's the maximum number of intermediate CA certificates that can appear in a chain. A maximal depth chain contains 2 more certificates than the limit, since neither the end-entity certificate nor the trust-anchor count against this limit. So like, a depth limit of 0 only allows the end-entity certificate to be signed directly by the trust anchor, while with a depth limit of 1 there can be one intermediate CA certificate between the trust anchor and the end-entity certificate. math girlies rise up. π’
X509_VERIFY_PARAM_set_auth_level() sets the authentication security level to auth_level. This level determines the acceptable signature and public key strength when verifying certificate chains. For a certificate chain to validate, the public keys of all the certificates must meet the specified security level. The signature algorithm security level is not enforced for the chain's trust anchor certificate, which is either directly trusted or validated by means other than its signature. See SSL_CTX_set_security_level(3) for the definitions of the available levels. The default security level is -1, or "not set". At security level 0 or lower, all algorithms are acceptable. Security level 1 requires at least 80-bit-equivalent security and is broadly interoperable, though it will, for example, reject MD5 signatures or RSA keys shorter than 1024 bits. so like, level 1 is giving secure but not extra. π
X509_VERIFY_PARAM_get0_host() returns the *n*th expected DNS hostname that has been set using X509_VERIFY_PARAM_set1_host() or X509_VERIFY_PARAM_add1_host(). To obtain all names, start with n = 0 and increment n as long as no NULL pointer is returned. it's a little loop, bestie. π
X509_VERIFY_PARAM_set1_host() sets the expected DNS hostname to name, clearing any previously specified hostname. If name is NULL, or empty, the list of hostnames is cleared, and name checks are not performed on the peer certificate. If name is NUL-terminated, namelen may be zero, otherwise namelen must be set to the length of name. got it? π
When a hostname is specified, certificate verification automatically invokes X509_check_host(3) with flags equal to the flags argument given to X509_VERIFY_PARAM_set_hostflags() (default zero). Applications are strongly advised to use this interface in preference to explicitly calling X509_check_host(3). Why? Because hostname checks may be out of scope with the DANE-EE(3) certificate usage, and the internal check will be suppressed as appropriate when DANE verification is enabled. so like, let the library do its thing. π¦
When the subject CommonName will not be ignored β whether that's because of the X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT host flag, or because no DNS subject alternative names are present in the certificate β any DNS name constraints in issuer certificates apply to the subject CommonName as well as the subject alternative name extension. okay? π
When the subject CommonName will be ignored β whether that's because of the X509_CHECK_FLAG_NEVER_CHECK_SUBJECT host flag, or because some DNS subject alternative names are present in the certificate β DNS name constraints in issuer certificates will not be applied to the subject DN. And as described in X509_check_host(3), the X509_CHECK_FLAG_NEVER_CHECK_SUBJECT flag takes precedence over the X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT flag. precedence, bestie. βοΈ
X509_VERIFY_PARAM_get_hostflags() returns any host flags previously set via a call to X509_VERIFY_PARAM_set_hostflags(). that's it, that's the function. β¨
X509_VERIFY_PARAM_add1_host() adds name as an additional reference identifier that can match the peer's certificate. Any previous names set via X509_VERIFY_PARAM_set1_host() or X509_VERIFY_PARAM_add1_host() are retained, and no change is made if name is NULL or empty. When multiple names are configured, the peer is considered verified when any name matches. multiple options, one yes. π
X509_VERIFY_PARAM_get0_peername() returns the DNS hostname or subject CommonName from the peer certificate that matched one of the reference identifiers. When wildcard matching is not disabled, or when a reference identifier specifies a parent domain (starts with ".") rather than a hostname, the peer name may be a wildcard name or a sub-domain of the reference identifier respectively. The return string is allocated by the library and is no longer valid once the associated param argument is freed. Applications must not free the return value. not me warning you twice about freeing it. π
X509_VERIFY_PARAM_get0_email() returns the expected RFC822 email address. π§
X509_VERIFY_PARAM_set1_email() sets the expected RFC822 email address to email. If email is NUL-terminated, emaillen may be zero, otherwise emaillen must be set to the length of email. When an email address is specified, certificate verification automatically invokes X509_check_email(3). slay. π
X509_VERIFY_PARAM_get1_ip_asc() returns the expected IP address as a string. The caller is responsible for freeing it. yes, you free it. π«Ά
X509_VERIFY_PARAM_set1_ip() sets the expected IP address to ip. The ip argument is in binary format, in network byte-order, and iplen must be set to 4 for IPv4 and 16 for IPv6. When an IP address is specified, certificate verification automatically invokes X509_check_ip(3). binary girlies know. π’
X509_VERIFY_PARAM_set1_ip_asc() sets the expected IP address to ipasc. The ipasc argument is a NUL-terminal ASCII string: dotted decimal quad for IPv4 and colon-separated hexadecimal for IPv6. The condensed "::" notation is supported for IPv6 addresses. cute and compact. π
π RETURN VALUES π
Okay bestie, here's the scoreboard:
X509_VERIFY_PARAM_set_flags(),X509_VERIFY_PARAM_clear_flags(),X509_VERIFY_PARAM_set_inh_flags(),X509_VERIFY_PARAM_set_purpose(),X509_VERIFY_PARAM_set_trust(),X509_VERIFY_PARAM_add0_policy(),X509_VERIFY_PARAM_set1_policies(),X509_VERIFY_PARAM_set1_host(),X509_VERIFY_PARAM_add1_host(),X509_VERIFY_PARAM_set1_email(),X509_VERIFY_PARAM_set1_ip()andX509_VERIFY_PARAM_set1_ip_asc()β these all return 1 for success and 0 for failure. no in-between, it's giving binary πX509_VERIFY_PARAM_get0_host(),X509_VERIFY_PARAM_get0_email(), andX509_VERIFY_PARAM_get1_ip_asc()β they hand you back the string pointers we talked about above, orNULLif that value was never set, or if something went wrong. NULL is the "idk her" of return values fr.X509_VERIFY_PARAM_get_flags()β returns the current verification flags. β¨X509_VERIFY_PARAM_get_hostflags()β returns whatever host flags are currently set.X509_VERIFY_PARAM_get_inh_flags()β returns the current inheritance flags.X509_VERIFY_PARAM_set_time()andX509_VERIFY_PARAM_set_depth()β these ones return nothing. no value, no drama, just vibes.X509_VERIFY_PARAM_get_depth()β returns the current verification depth.X509_VERIFY_PARAM_get_auth_level()β returns the current authentication security level.X509_VERIFY_PARAM_get_purpose()β returns the current purpose, which may beX509_PURPOSE_DEFAULT_ANYif it was never set. she's flexible like that π¦
π₯ VERIFICATION FLAGS π₯
So the verification flags are literally just zero or more of these flags OR-ed together. mix and match, pick your fighter:
X509_V_FLAG_CRL_CHECKβ turns on CRL checking for the certificate chain's leaf certificate. If a suitable CRL can't be found, boom, error. πX509_V_FLAG_CRL_CHECK_ALLβ expands CRL checking to the entire certificate chain, but only ifX509_V_FLAG_CRL_CHECKis also enabled. Otherwise? Ignored. she doesn't work solo, periodt.X509_V_FLAG_IGNORE_CRITICALβ disables critical extension checking. By default, any unhandled critical extensions in certificates or (if checked) CRLs cause a fatal error. Flip this flag on and those unhandled critical extensions just get ignored.
β οΈ WARNING: setting this option for anything other than debugging purposes can be a security risk. Finer control over which extensions are supported can be done in the verification callback. bestie pls do not ship this to prod π
X509_V_FLAG_X509_STRICTβ disables workarounds for some broken certificates, and makes verification strictly apply the X509 rules. no more coddling those messy certs πX509_V_FLAG_ALLOW_PROXY_CERTSβ enables proxy certificate verification.X509_V_FLAG_POLICY_CHECKβ enables certificate policy checking. by default no policy checking happens at all. Extra info gets sent to the verification callback relating to policy checking. π¬X509_V_FLAG_EXPLICIT_POLICY,X509_V_FLAG_INHIBIT_ANYandX509_V_FLAG_INHIBIT_MAPβ these set the require explicit policy, inhibit any policy, and inhibit policy mapping flags respectively, as defined in RFC3280. Policy checking is automatically enabled if any of these flags are set. slay, she turns herself on.X509_V_FLAG_NOTIFY_POLICYβ if this is set and the policy checking succeeds, a special status code gets set to the verification callback. That lets it examine the valid policy tree and do extra checks, or just log it for debugging purposes. π- By default some extra features like indirect CRLs and CRLs signed by different keys are disabled. Set
X509_V_FLAG_EXTENDED_CRL_SUPPORTand they're enabled. unlock the deluxe edition β¨ X509_V_FLAG_USE_DELTASβ if set, delta CRLs (if present) are used to determine certificate status. If not set, deltas are ignored. simple as.X509_V_FLAG_CHECK_SS_SIGNATUREβ requests checking the signature of the last certificate in a chain if that certificate is supposedly self-signed. This is prohibited and will result in an error if it's a non-conforming CA certificate with key usage restrictions that don't include thekeyCertSignbit. By default this check is disabled because it doesn't add any additional security, but in some cases applications might want to check the signature anyway. A side effect of not checking the self-signature of such a certificate is that disabled or unsupported message digests used for the signature are not treated as fatal errors.X509_V_FLAG_TRUSTED_FIRSTβ when set, construction of the certificate chain inX509_verify_cert(3)searches the trust store for issuer certificates before searching the provided untrusted certificates. And ngl, this is always the case since OpenSSL 1.1.0. Local issuer certificates are often more likely to satisfy local security requirements and lead to a locally trusted root. This is especially important when some certificates in the trust store have explicit trust settings (see "TRUST SETTINGS" inopenssl-x509(1)).X509_V_FLAG_NO_ALT_CHAINSβ this one could have been used before OpenSSL 1.1.0 to suppress checking for alternative chains. By default, unlessX509_V_FLAG_TRUSTED_FIRSTis set, when building a certificate chain, if the first certificate chain found isn't trusted, then OpenSSL will attempt to replace untrusted certificates supplied by the peer with certificates from the trust store, to see if an alternative chain can be found that is trusted. As of OpenSSL 1.1.0, withX509_V_FLAG_TRUSTED_FIRSTalways set, this option has no effect. she's retired, let her rest πX509_V_FLAG_PARTIAL_CHAINβ causes non-self-signed certificates in the trust store to be treated as trust anchors, the same way as self-signed root CA certificates. This makes it possible to trust self-issued certificates as well as certificates issued by an intermediate CA, without having to trust their ancestor root CA. With OpenSSL 1.1.0 and later andX509_V_FLAG_PARTIAL_CHAINset, chain construction stops as soon as the first certificate contained in the trust store is added to the chain β whether that certificate is a self-signed "root" certificate or a not self-signed "intermediate" or self-issued certificate. So, when an intermediate certificate is found in the trust store, the verified chain passed to callbacks may be shorter than it otherwise would be without theX509_V_FLAG_PARTIAL_CHAINflag. she cuts the line short, and honestly? iconic.X509_V_FLAG_NO_CHECK_TIMEβ suppresses checking the validity period of certificates and CRLs against the current time. But wait β ifX509_VERIFY_PARAM_set_time()is used to specify a verification time, the check is not suppressed. the exception is real π
π¦ INHERITANCE FLAGS π¦
These flags specify how parameters get "inherited" from one structure to another. like family traits but for crypto config, iykyk.
X509_VP_FLAG_ONCEβ if set, then the current setting is zeroed after the next call. one and done, she's out βοΈX509_VP_FLAG_LOCKEDβ if set, then no values are copied. This overrides all of the following flags. the ultimate veto, honestly.X509_VP_FLAG_DEFAULTβ if set, then anything set in the source is copied to the destination. Effectively the values in "to" become default values, which will be used only if nothing new is set in "from". This is the default. β¨X509_VP_FLAG_OVERWRITEβ if set, then all values are copied across whether they are set or not. Flags is still OR-ed though. no skipping, everything comes through πX509_VP_FLAG_RESET_FLAGSβ if set, then the flags value is copied instead of OR-ed.
πΈ NOTES πΈ
The above functions should be used to manipulate verification parameters, instead of functions which work in specific structures like X509_STORE_CTX_set_flags() β those are likely to be deprecated in a future release. bestie, use the good ones, the future is now π«Ά
π BUGS π
okay so, full transparency:
- Delta CRL checking is currently primitive. Only a single delta can be used, and (partly due to limitations of
X509_STORE) constructed CRLs are not maintained. it's giving beta energy fr. - If CRL checking is enabled, CRLs are expected to be available in the corresponding
X509_STOREstructure. No attempt is made to download CRLs from the CRL distribution points extension. she does not go shopping for them, they must come to her.
β¨ EXAMPLES β¨
Enable CRL checking when performing certificate verification during SSL connections associated with an SSL_CTX structure ctx:
X509_VERIFY_PARAM *param;
param = X509_VERIFY_PARAM_new();
X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK);
SSL_CTX_set1_param(ctx, param);
X509_VERIFY_PARAM_free(param);
look at you go, setting up your own verification params π₯Ή so proud.
π SEE ALSO π
X509_verify_cert(3), X509_check_host(3), X509_check_email(3), X509_check_ip(3), openssl-x509(1)
go read those too, the lore is deep π
π HISTORY π
- The
X509_V_FLAG_NO_ALT_CHAINSflag was added in OpenSSL 1.1.0. The flagX509_V_FLAG_CB_ISSUER_CHECKwas deprecated in OpenSSL 1.1.0 and has no effect. - The
X509_VERIFY_PARAM_get_hostflags()function was added in OpenSSL 1.1.0i. - The
X509_VERIFY_PARAM_get0_host(),X509_VERIFY_PARAM_get0_email(), andX509_VERIFY_PARAM_get1_ip_asc()functions were added in OpenSSL 3.0. - The function
X509_VERIFY_PARAM_add0_policy()was historically documented as enabling policy checking β however, the implementation has never done this. The documentation was changed to align with the implementation. gaslight gatekeep girlboss, but make it docs π - The
X509_VERIFY_PARAM_get_purpose()function was added in OpenSSL 3.5.
π COPYRIGHT π
Copyright 2009-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!! π this one's from OpenSSL 3.5.9, dated 2026-09-29, and it's the X509_VERIFY_PARAM_SET_FLAGS(3ossl) manual page. you read the entire thing, which is genuinely iconic of you. go forth and verify those certs responsibly πβ¨π¦
π¦ where this page comes from
- fedora 43: openssl-devel 1:3.5.9-1.fc43 Β· Apache-2.0
- fedora 43: openssl-devel 1:3.5.9-1.fc43 Β· Apache-2.0
- fedora 44: openssl-devel 1:3.5.9-1.fc44 Β· Apache-2.0
- fedora 44: openssl-devel 1:3.5.9-1.fc44 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms