X509_VERIFY_PARAM_SET_FLAGS(3SSL)

๐Ÿ’– NAME ๐Ÿ’–

Okay bestie, this is the X509_VERIFY_PARAM_SET_FLAGS(3SSL) page from OpenSSL, and it's basically the group chat for a whole squad of functions that deal with X509 verification parameters. Here's everyone on the roster:

  • X509_VERIFY_PARAM_set_flags
  • X509_VERIFY_PARAM_clear_flags
  • X509_VERIFY_PARAM_get_flags
  • X509_VERIFY_PARAM_set_purpose
  • X509_VERIFY_PARAM_get_purpose
  • X509_VERIFY_PARAM_get_inh_flags
  • X509_VERIFY_PARAM_set_inh_flags
  • X509_VERIFY_PARAM_set_trust
  • X509_VERIFY_PARAM_set_depth
  • X509_VERIFY_PARAM_get_depth
  • X509_VERIFY_PARAM_set_auth_level
  • X509_VERIFY_PARAM_get_auth_level
  • X509_VERIFY_PARAM_set_time
  • X509_VERIFY_PARAM_get_time
  • X509_VERIFY_PARAM_add0_policy
  • X509_VERIFY_PARAM_set1_policies
  • X509_VERIFY_PARAM_get0_host
  • X509_VERIFY_PARAM_set1_host
  • X509_VERIFY_PARAM_add1_host
  • X509_VERIFY_PARAM_set_hostflags
  • X509_VERIFY_PARAM_get_hostflags
  • X509_VERIFY_PARAM_get0_peername
  • X509_VERIFY_PARAM_get0_email
  • X509_VERIFY_PARAM_set1_email
  • X509_VERIFY_PARAM_set1_rfc822
  • X509_VERIFY_PARAM_add1_rfc822
  • X509_VERIFY_PARAM_set1_smtputf8
  • X509_VERIFY_PARAM_add1_smtputf8
  • X509_VERIFY_PARAM_set1_ip
  • X509_VERIFY_PARAM_add1_ip
  • X509_VERIFY_PARAM_set1_ip_asc
  • X509_VERIFY_PARAM_add1_ip_asc
  • X509_VERIFY_PARAM_get1_ip_asc
  • X509_VERIFY_PARAM_set1_host_input_validation
  • X509_VERIFY_PARAM_set1_rfc822_input_validation
  • X509_VERIFY_PARAM_set1_smtputf8_input_validation
  • X509_VERIFY_PARAM_set1_ip_input_validation

And that whole list? It's 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);
        int X509_VERIFY_PARAM_set1_rfc822(X509_VERIFY_PARAM *param,
                                         const char *email, size_t emaillen);
        int X509_VERIFY_PARAM_add1_rfc822(X509_VERIFY_PARAM *param,
                                        const char *email, size_t emaillen);
        int X509_VERIFY_PARAM_set1_smtputf8(X509_VERIFY_PARAM *param,
                                         const char *email, size_t emaillen);
        int X509_VERIFY_PARAM_add1_smtputf8(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_add1_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 *ip_asc);
        int X509_VERIFY_PARAM_add1_ip_asc(X509_VERIFY_PARAM *param, const char *ip_asc);
        void X509_VERIFY_PARAM_set1_ip_input_validation(X509_VERIFY_PARAM *param,
           int (*validate_ip)(const uint8_t *name, size_t len));
        void X509_VERIFY_PARAM_set1_host_input_validation(X509_VERIFY_PARAM *param,
           int (*validate_host)(const char *name, size_t len));
        void X509_VERIFY_PARAM_set1_rfc822_input_validation(X509_VERIFY_PARAM *param,
           int (*validate_rfc822)(const char *name, size_t len));
        void X509_VERIFY_PARAM_set1_smtputf8_input_validation(X509_VERIFY_PARAM *param,
           int (*validate_smtputf8)(const char *name, size_t len));

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

These functions are all about manipulating the X509_VERIFY_PARAM structure that's tied to a certificate verification operation. Think of it as the control panel for how certs get checked. Let's break it down, bestie. ๐Ÿ’–

  • X509_VERIFY_PARAM_set_flags() โ€” sets the flags in param by ORing it with flags. Wanna know all the values flags can take? Run to the "VERIFICATION FLAGS" section. It's giving very important. โœจ
  • X509_VERIFY_PARAM_get_flags() โ€” returns the flags in param. Simple. Iconic. ๐Ÿ’…
  • X509_VERIFY_PARAM_get_inh_flags() โ€” returns the inheritance flags in param, which specify how verification flags are copied from one structure to another. X509_VERIFY_PARAM_set_inh_flags() sets those inheritance flags. The "INHERITANCE FLAGS" section has the full description of what those bits mean. ๐ŸŽ€
  • X509_VERIFY_PARAM_clear_flags() โ€” clears the flags in param. Bye bye, flags. ๐Ÿ‘‹
  • X509_VERIFY_PARAM_set_purpose() โ€” sets the verification purpose in param to purpose. This decides the acceptable purpose of the cert chain, for example X509_PURPOSE_SSL_CLIENT. The purpose requirement gets cleared if purpose is X509_PURPOSE_DEFAULT_ANY. So if you're like "any is fine," that's the move. ๐Ÿฆ‹
  • X509_VERIFY_PARAM_get_purpose() โ€” returns the purpose in param. Slay. ๐Ÿ’…
  • X509_VERIFY_PARAM_set_trust() โ€” sets the trust setting in param to trust. That's it. Trust issues solved? Maybe. ๐Ÿ˜ญ
  • X509_VERIFY_PARAM_set_time() โ€” sets the verification time in param to t. Normally the current time is used, but sometimes you gotta time travel. โฐ
  • X509_VERIFY_PARAM_add0_policy() โ€” adds policy to the acceptable policy set. > Contrary to preexisting documentation of this function it does not enable policy checking. Not me finding out the hard way. ๐Ÿ’€
  • X509_VERIFY_PARAM_set1_policies() โ€” enables policy checking (it's disabled by default) and sets the acceptable policy set to policies. Any existing policy set is cleared. The policies parameter can be NULL to clear an existing policy set. So yeah, it's the one that actually turns policy checking on. ๐Ÿ”ฅ
  • 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 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. The math is mathing. ๐Ÿงฎ
  • 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 cert 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 maybe don't use MD5, bestie. ๐Ÿ˜ญ
  • X509_VERIFY_PARAM_get0_host() โ€” returns the nth 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. Collect them all. โœจ
  • X509_VERIFY_PARAM_set1_host() โ€” sets in param the expected DNS hostname to name, clearing any previously specified hostname. If name is NULL or the empty string, the list of hostnames is cleared and hostname checks are not performed on the peer certificate. If namelen is zero, name must be NUL-terminated, otherwise namelen must be set to the length of name. Details matter, okay? ๐Ÿ’…

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), 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. It's giving main character energy. ๐Ÿ‘‘

When the subject CommonName will not be ignored, whether as a result 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.

When the subject CommonName will be ignored, whether as a result 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. 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. So NEVER beats ALWAYS, periodt. โœจ

  • X509_VERIFY_PARAM_get_hostflags() โ€” returns any host flags previously set via a call to X509_VERIFY_PARAM_set_hostflags(). Got it? Got it. ๐Ÿ’–
  • 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, no change is made if name is NULL or the empty string. When multiple names are configured, the peer is considered verified when any name matches. So it's like, any one of them can be the one. ๐Ÿ’…

okay so the peername one?? X509_VERIFY_PARAM_get0_peername() hands you back the DNS hostname or the subject CommonName from the peer certificate that matched one of your reference identifiers ๐ŸŒธ. When wildcard matching isn't disabled, or when a reference identifier specifies a parent domain (ykw, it starts with .) instead of an actual hostname, the peer name can come back as a wildcard name or as a sub-domain of the reference identifier respectively. Important bestie: the return string is allocated by the library, so the second the associated param argument gets freed, that string is no longer valid ๐Ÿ’€. Applications must not free the return value. Not yours to free, periodt.

X509_VERIFY_PARAM_get0_email() returns the expected RFC822 email address ๐Ÿ’Œ.

The _rfc822() family of functions is for email names that have ASCII localpart addresses โ€” and in that case the domain part of the address has to be represented in A-label form โœจ. You use these to specify the list of values to match against the SAN Email names in certificates.

X509_VERIFY_PARAM_set1_rfc822() clears all expected RFC822 email addresses and sets the expected RFC822 email address to email. If email is NULL, no expected address is set. Otherwise, if emaillen is zero, email must be NUL-terminated; if emaillen is nonzero, emaillen must be set to the length of email. And whenever any email address is specified, certificate verification automatically invokes X509_check_email(3) ๐Ÿ”ฅ.

X509_VERIFY_PARAM_add1_rfc822() adds email as an additional reference identifier that can match RFC822 email addresses in the peer's certificate ๐ŸŽ€. Anything previously set via X509_VERIFY_PARAM_set1_rfc822(), X509_VERIFY_PARAM_add1_rfc822(), or X509_VERIFY_PARAM_set1_email() stays retained on success, and literally nothing changes on failure. It is a failure if email is NULL or the empty string. The peer counts as verified when any one of the specified RFC822 or SMTPUTF8 names matches a corresponding email address SAN in the certificate ๐Ÿ‘‘.

The _smtputf8() family of functions is for email names that have non-ASCII localpart addresses, in which case the domain part of the address must be in U-label form ๐ŸŒˆ. They specify the list of values to match against the OTHERNAME SMTPUTF8 names in certificates.

X509_VERIFY_PARAM_set1_smtputf8() sets the expected SMTPUTF8 email address to email. If email is NULL, SMTPUTF8 email checking is disabled. Otherwise, if emaillen is zero, email must be NUL-terminated; if emaillen is nonzero, emaillen must be set to the length of email. When any email address is specified, certificate verification automatically invokes X509_check_email(3) ๐Ÿ’–.

X509_VERIFY_PARAM_add1_smtputf8() adds email as an additional reference identifier that can match SMTPUTF8 email addresses in the peer's certificate ๐Ÿฆ‹. Any previous names set via X509_VERIFY_PARAM_set1_smtputf8(), X509_VERIFY_PARAM_add1_smtputf8(), or X509_VERIFY_PARAM_set1_email() are retained on success, no change is made on failure. It is a failure if email is NULL or the empty string. The peer is considered verified when any one of the specified RFC822 or SMTPUTF8 names matches a corresponding email address SAN in the certificate โœจ.

X509_VERIFY_PARAM_set1_email() calls X509_VERIFY_PARAM_set_rfc822(), and X509_VERIFY_PARAM_set_smtputf8(), and succeeds if either call succeeds ๐Ÿซถ.


X509_VERIFY_PARAM_get1_ip_asc() returns the expected IP address as a string. The caller is responsible for freeing it โ€” that one's on you, bestie ๐Ÿ™ˆ.

X509_VERIFY_PARAM_set1_ip() sets the expected IP address to ip. If ip is NULL, IP address checking is disabled. Otherwise, the ip argument must be 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).

X509_VERIFY_PARAM_add1_ip() adds ip as an additional reference identifier that can match the peer's certificate on success ๐ŸŽฏ. Any previous addresses set via X509_VERIFY_PARAM_set1_ip(), X509_VERIFY_PARAM_add1_ip(), X509_VERIFY_PARAM_set1_ip_asc(), or X509_VERIFY_PARAM_add1_ip_asc() are retained. No change is made on failure. It is a failure if ip is NULL or the value iplen is neither 4 nor 16 bytes. When multiple names are configured, the peer is considered verified when any name matches ๐Ÿ’….

X509_VERIFY_PARAM_set1_ip_asc() sets the expected IP address to ip_asc. The ip_asc argument must be a NUL-terminated ASCII string: dotted decimal quad for IPv4 and colon-separated hexadecimal for IPv6 ๐Ÿงš. The condensed "::" notation is supported for IPv6 addresses โ€” yes, the shortcut works, slay.

X509_VERIFY_PARAM_add1_ip_asc() adds ip_asc as an additional reference identifier that can match the peer's certificate on success ๐ŸŒŸ. The ip_asc argument must be a NUL-terminated ASCII string: dotted decimal quad for IPv4 and colon-separated hexadecimal for IPv6. The condensed "::" notation is supported for IPv6 addresses. Any previous names set via X509_VERIFY_PARAM_set1_ip(), X509_VERIFY_PARAM_add1_ip(), X509_VERIFY_PARAM_set1_ip_asc(), or X509_VERIFY_PARAM_add1_ip_asc() are retained. No change is made on failure. It is a failure if ip_asc is NULL or the empty string. When multiple addresses are configured, the peer is considered verified when any one of the specified addresses matches a corresponding IP address SAN in the certificate ๐ŸŽ€.

X509_VERIFY_PARAM_set1_host_input_validation(), X509_VERIFY_PARAM_set1_rfc822_input_validation(), X509_VERIFY_PARAM_set1_smtputf8_input_validation(), and X509_VERIFY_PARAM_set1_ip_input_validation() set a verification function to validate the input on setting the corresponding validation parameter expected values โœจ. These functions make it possible to override OpenSSL's built-in input validation of the corresponding verification parameters. If the provided function succeeds, the corresponding input will be accepted for use in certificate verification ๐Ÿ‘‘.


โœจ RETURN VALUES โœจ

Okay so here's the vibe check on what each one gives back ๐Ÿ’–:

  • 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(), X509_VERIFY_PARAM_add1_ip(), X509_VERIFY_PARAM_set1_ip_asc(), X509_VERIFY_PARAM_add1_ip_asc() โ€” all of these return 1 for success and 0 for failure ๐Ÿซถ.
  • X509_VERIFY_PARAM_get0_host(), X509_VERIFY_PARAM_get0_email(), and X509_VERIFY_PARAM_get1_ip_asc() return the string pointers specified above, or NULL if the respective value has not been set or on error ๐Ÿ™ˆ.
  • X509_VERIFY_PARAM_get_flags() returns the current verification flags ๐Ÿšฉ.
  • X509_VERIFY_PARAM_get_hostflags() returns any current host flags โœจ.
  • X509_VERIFY_PARAM_get_inh_flags() returns the current inheritance flags ๐ŸŒˆ.
  • X509_VERIFY_PARAM_set_time() and X509_VERIFY_PARAM_set_depth() do not return values ๐Ÿซฅ. Nothing. Nada. Not even a little something.
  • 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 be X509_PURPOSE_DEFAULT_ANY if unset ๐ŸŽ€.

๐Ÿ”ฅ VERIFICATION FLAGS ๐Ÿ”ฅ

okay so these flags are literally the main character of this whole page ๐Ÿ’… you build a verification flag set by ORing together zero or more of the following. mix 'em, stack 'em, go feral (responsibly).

  • X509_V_FLAG_CRL_CHECK โ€” turns on CRL checking for the leaf certificate of the certificate chain. if a suitable CRL can't be found, you get an error. no CRL, no vibes. ๐Ÿšซ
  • X509_V_FLAG_CRL_CHECK_ALL โ€” expands CRL checking out to the entire certificate chain... but only if X509_V_FLAG_CRL_CHECK is also enabled. otherwise it's just ignored, sitting there, doing nothing, kind of embarrassing for it honestly. ๐Ÿ™ˆ
  • X509_V_FLAG_OCSP_RESP_CHECK โ€” enables Online Certificate Status Protocol (OCSP) checking for the leaf certificate of the certificate chain. if a suitable OCSP response can't be found, that's an error. ๐Ÿ’€
  • X509_V_FLAG_OCSP_RESP_CHECK_ALL โ€” expands OCSP checking to the entire chain, but again only if X509_V_FLAG_OCSP_RESP_CHECK is also enabled. otherwise: ignored. bestie said nothing, bestie gets nothing.
  • X509_V_FLAG_IGNORE_CRITICAL โ€” disables critical extension checking. by default, any unhandled critical extensions in certificates (or in CRLs, if those are being checked) are a fatal error. flip this on and unhandled critical extensions get ignored instead. WARNING: setting this for anything that isn't debugging can be a security risk. if you want finer control over which extensions are supported, do that in the verification callback instead. ๐Ÿšจ
  • X509_V_FLAG_X509_STRICT โ€” kills the workarounds for janky broken certificates and makes verification strictly apply X509 rules. no more being nice. periodt.
  • 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. when you turn it on, extra info relating to policy checking gets sent to the verification callback. ๐Ÿ“ฌ
  • X509_V_FLAG_EXPLICIT_POLICY, X509_V_FLAG_INHIBIT_ANY, X509_V_FLAG_INHIBIT_MAP โ€” these set the "require explicit policy", "inhibit any policy" and "inhibit policy mapping" flags respectively, exactly as defined in RFC 5280. plot twist: policy checking turns itself on automatically if any of these three are set. ๐Ÿ˜ฎ
  • X509_V_FLAG_NOTIFY_POLICY โ€” if this is set and the policy checking went well, a special status code gets set to the verification callback. that lets the callback examine the valid policy tree and run extra checks, or honestly just log it for debugging. either way, slay.
  • X509_V_FLAG_EXTENDED_CRL_SUPPORT โ€” by default some extra features are disabled, like indirect CRLs and CRLs signed by different keys. set this and they're enabled. ๐Ÿ”“
  • X509_V_FLAG_USE_DELTAS โ€” if set, delta CRLs (when present) are used to determine certificate status. if it's not set, deltas are just ignored.
  • X509_V_FLAG_CHECK_SS_SIGNATURE โ€” asks for the signature of the last certificate in a chain to be checked, if that certificate is supposedly self-signed. here's the catch: this is prohibited and errors out if it's a non-conforming CA certificate whose key usage restrictions don't include the keyCertSign bit. by default this check is disabled, because it doesn't add any extra security โ€” but some applications still want to check the signature anyway, and honestly, respect. a side effect of not checking the self-signature of such a certificate: disabled or unsupported message digests used for the signature don't get treated as fatal errors. ๐Ÿ‘€
  • X509_V_FLAG_TRUSTED_FIRST โ€” when this is set, chain construction in X509_verify_cert(3) searches the trust store for issuer certificates before searching the provided untrusted certificates. this is the default since OpenSSL 1.1.0, so it's the vibe now. why does it matter? because 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" in openssl-x509(1)). ๐Ÿ‘‘
  • X509_V_FLAG_NO_ALT_CHAINS โ€” suppresses checking for alternative chains. nope, not doing that, moving on. ๐Ÿ™…
  • X509_V_FLAG_PARTIAL_CHAIN โ€” this one is spicy. it makes non-self-signed certificates in the trust store get treated as trust anchors, the same way self-signed root CA certificates are. so you can trust self-issued certificates, and certificates issued by an intermediate CA, without having to trust their ancestor root CA at all. with X509_V_FLAG_PARTIAL_CHAIN set, chain construction stops as soon as the first certificate contained in the trust store gets added to the chain โ€” whether that certificate is a self-signed "root" certificate, or a not-self-signed "intermediate" or self-issued certificate. which means: when an intermediate certificate is found in the trust store, the verified chain passed to callbacks can be shorter than it otherwise would be without this flag. yes, shorter. it's giving efficiency. โšก
  • X509_V_FLAG_NO_CHECK_TIME โ€” suppresses checking the validity period of certificates and CRLs against the current time. exception: if X509_VERIFY_PARAM_set_time() is used to specify a verification time, then the check is not suppressed. ๐Ÿ•ฐ๏ธ

๐Ÿงฌ INHERITANCE FLAGS ๐Ÿงฌ

these flags specify how parameters get "inherited" from one structure to another. it's giving family tree, but for structs. ๐ŸŒณ

  • X509_VP_FLAG_ONCE โ€” if set, the current setting gets zeroed out after the next call. one and done. โœŒ๏ธ
  • X509_VP_FLAG_LOCKED โ€” if set, no values are copied. this overrides all of the flags below it. it's the final boss of inheritance flags, lowkey.
  • X509_VP_FLAG_DEFAULT โ€” if set, anything set in the source is copied to the destination. effectively, the values in "to" become default values, which only get used if nothing new is set in "from". this one is the default, iconically.
  • X509_VP_FLAG_OVERWRITE โ€” if set, all values get copied across, whether they're set or not. flags is still ORed though, don't get it twisted.
  • X509_VP_FLAG_RESET_FLAGS โ€” if set, the flags value gets copied instead of ORed. ๐Ÿ”„

๐Ÿ“ NOTES ๐Ÿ“

use the functions above to manipulate verification parameters instead of the functions that work on specific structures, like X509_STORE_CTX_set_flags() โ€” those are likely to be deprecated in a future release and you do not want to be caught still using them. ๐Ÿ™ˆ

TLS clients, bestie, please: set up validation of server hostname(s) and/or IP address โ€” either directly with the functions above, or, way more conveniently, using SSL_set1_host(3) or SSL_add1_host(3). and use SSL_set_tlsext_host_name(3) for Server Name Indication (SNI), which may be crucial for correct routing of the connection request too. like, do not skip this. ๐ŸŒธ


๐Ÿ’€ BUGS ๐Ÿ’€

Delta CRL checking is currently primitive. only a single delta can be used, and (partly because of limitations of X509_STORE) constructed CRLs are not maintained. we're doing our best, ok?? ๐Ÿ˜ญ

If CRLs checking is enable, CRLs are expected to be available in the corresponding X509_STORE structure. no attempt is made to download CRLs from the CRL distribution points extension. if they're not already there, they're just... not there. that's the whole bit.

(yes, the original says "If CRLs checking is enable". we are preserving the โœจ lore โœจ exactly as written.)

๐ŸŽ€ 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 that. clean. four lines. ate. ๐Ÿ”ฅ


๐Ÿ‘€ SEE ALSO ๐Ÿ‘€

go read these next, bestie: SSL_CTX_set_security_level(3), X509_verify_cert(3), X509_check_host(3), X509_check_email(3), X509_check_ip(3), SSL_set_tlsext_host_name(3), openssl-x509(1)


๐Ÿ•ฐ๏ธ HISTORY ๐Ÿ•ฐ๏ธ

Until OpenSSL 1.1.0, by default (unless X509_V_FLAG_TRUSTED_FIRST was set), when building a certificate chain, if the first certificate chain found was not trusted, OpenSSL would attempt to replace untrusted certificates supplied by the peer with certificates from the trust store โ€” to see if an alternative chain could be found that is trusted. since OpenSSL 1.1.0, X509_V_FLAG_TRUSTED_FIRST is set by default. glow up. โœจ

  • X509_V_FLAG_NO_ALT_CHAINS was added in OpenSSL 1.1.0.
  • The flag X509_V_FLAG_CB_ISSUER_CHECK was deprecated in OpenSSL 1.1.0 and has no effect. rip, it does nothing now. ๐Ÿ’€
  • 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(), and X509_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. lore correction, no cap.
  • The X509_VERIFY_PARAM_get_purpose() function was added in OpenSSL 3.5.

Copyright 2009-2026 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 was version 4.0.3, dated 2026-09-29, and we did it for X509_VERIFY_PARAM_SET_FLAGS(3SSL). go forth and verify those certs correctly. mwah. ๐Ÿ’…๐ŸŽ€

๐Ÿ“ฆ where this page comes from