NAME¶

X509_STORE_CTX_verify_cb, X509_STORE_CTX_set_verify_cb, X509_STORE_CTX_get_verify_cb — set and retrieve verification callback

SYNOPSIS¶

#include <openssl/x509_vfy.h>

typedef int
(*X509_STORE_CTX_verify_cb)(int ok, X509_STORE_CTX *ctx);

void
X509_STORE_CTX_set_verify_cb(X509_STORE_CTX *ctx, X509_STORE_CTX_verify_cb verify_cb);

X509_STORE_CTX_verify_cb
X509_STORE_CTX_get_verify_cb(X509_STORE_CTX *ctx);

DESCRIPTION¶

X509_STORE_CTX_set_verify_cb() sets the verification callback of ctx to verify_cb overwriting any existing callback.

The verification callback can be used to modify the operation of certificate verification, either by overriding error conditions or logging errors for debugging purposes. The use of a verification callback is not essential, and should not be used in security sensitive programs.

Do not use this function. It is extremely fragile and unpredictable. This callback exposes implementation details of certificate verification, which change as the library evolves. Attempting to use it for security checks can introduce vulnerabilities if making incorrect assumptions about when the callback is called. Additionally, overriding ok may leave ctx in an inconsistent state and break invariants.

Instead, customize certificate verification by configuring options on the X509_STORE_CTX before verification, or applying additional checks after X509_verify_cert(3) completes successfully.

The ok parameter to the callback indicates the value the callback should return to retain the default behaviour. If it is zero then an error condition is indicated. If it is 1 then no error occurred. As the default behaviour is internal to the verifier, and possibly unknown to the caller, changing this parameter is inherently dangerous and should not normally be done except for debugging purposes, and should not be expected to be consistent if the verifier changes. If the flag X509_V_FLAG_NOTIFY_POLICY is set, then ok is set to 2 to indicate the policy checking is complete.

The ctx parameter to the callback is the X509_STORE_CTX structure that is performing the verification operation. A callback can examine this structure and receive additional information about the error, for example by calling X509_STORE_CTX_get_current_cert(3). Additional application data can be passed to the callback via the ex_data mechanism.

The verification callback can be set and inherited from the parent structure performing the operation. In some cases (such as S/MIME verification) the X509_STORE_CTX structure is created and destroyed internally and the only way to set a custom verification callback is by inheriting it from the associated X509_STORE.

RETURN VALUES¶

X509_STORE_CTX_get_verify_cb() returns a pointer to the current callback function used by the specified ctx. If no callback was set using X509_STORE_CTX_set_verify_cb(), that is a pointer to a built-in static function which does nothing except returning the ok argument passed to it.

EXAMPLES¶

Default callback operation:

int
verify_callback(int ok, X509_STORE_CTX *ctx)
{
	return ok;
}

This is likely the only safe callback to use.

Simple and terrible example that should not be used. Suppose a certificate in the chain is expired and we wish to continue after this error:

int
verify_callback(int ok, X509_STORE_CTX *ctx)
{
	/* Tolerate certificate expiration */
	if (X509_STORE_CTX_get_error(ctx) == X509_V_ERR_CERT_HAS_EXPIRED)
		return 1;
	/* Otherwise don't override */
	return ok;
}

While this example is presented for historical purposes, this is not the correct way to accomplish this. The verification flag X509_V_FLAG_NO_CHECK_TIME should be set on the STORE_CTX using X509_VERIFY_PARAM_set_flags(3) instead.

Full featured debugging logging callback - note that the output and order that things happen from this can change over time and should not be parsed or expected to be consistent. In this case the bio_err is assumed to be a global logging BIO, an alternative would to store a BIO in ctx using ex_data.

int
verify_callback(int ok, X509_STORE_CTX *ctx)
{
	X509 *err_cert;
	int err,depth;

	err_cert = X509_STORE_CTX_get_current_cert(ctx);
	err =	X509_STORE_CTX_get_error(ctx);
	depth =	X509_STORE_CTX_get_error_depth(ctx);

	BIO_printf(bio_err,"depth=%d ",depth);
	if (err_cert) {
		X509_NAME_print_ex(bio_err,
		    X509_get_subject_name(err_cert), 0,
		    XN_FLAG_ONELINE);
		BIO_puts(bio_err, "\n");
	} else
		BIO_puts(bio_err, "<no cert>\n");
	if (!ok)
		BIO_printf(bio_err, "verify error:num=%d:%s\n",
		    err, X509_verify_cert_error_string(err));
	switch (err) {
	case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT:
		BIO_puts(bio_err, "issuer= ");
		X509_NAME_print_ex(bio_err,
		    X509_get_issuer_name(err_cert), 0,
		    XN_FLAG_ONELINE);
		BIO_puts(bio_err, "\n");
		break;
	case X509_V_ERR_CERT_NOT_YET_VALID:
	case X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD:
		BIO_printf(bio_err, "notBefore=");
		ASN1_TIME_print(bio_err,
		    X509_get_notBefore(err_cert));
		BIO_printf(bio_err, "\n");
		break;
	case X509_V_ERR_CERT_HAS_EXPIRED:
	case X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD:
		BIO_printf(bio_err, "notAfter=");
		ASN1_TIME_print(bio_err, X509_get_notAfter(err_cert));
		BIO_printf(bio_err, "\n");
		break;
	case X509_V_ERR_NO_EXPLICIT_POLICY:
		policies_print(bio_err, ctx);
		break;
	}
	if (err == X509_V_OK && ok == 2)
		/* print out policies */

	BIO_printf(bio_err,"verify return:%d\n",ok);
	return(ok);
}

SEE ALSO¶

X509_STORE_CTX_get_error(3), X509_STORE_CTX_get_ex_new_index(3), X509_STORE_CTX_new(3), X509_STORE_CTX_set_error(3), X509_STORE_CTX_set_flags(3), X509_STORE_CTX_set_verify(3), X509_STORE_set_verify_cb(3), X509_verify_cert(3), X509_VERIFY_PARAM_set_flags(3)

HISTORY¶

X509_STORE_CTX_set_verify_cb() first appeared in OpenSSL 0.9.6c and has been available since OpenBSD 3.2.

X509_STORE_CTX_get_verify_cb() first appeared in OpenSSL 1.1.0 and has been available since OpenBSD 7.1.

X509_STORE_CTX_verify_cb() first appeared in OpenSSL 1.1.0 and has been available since OpenBSD 7.2.

CAVEATS¶

In general a verification callback should NOT return a changed value of ok because this can allow the verification to appear to succeed in an unpredictable way. This can effectively remove all security from the application because untrusted or invalid certificates may be accepted. Doing this can possibly make X509_verify_cert(3) return what appears to be a validated chain of certificates that has not been validated or even had the signatures checked.