SSL_CTX_SET_...IFY_CALLBACK(3ossl)

📦
version 3.5.9 · 8 versions
, in fedora 43, fedora 44

💖 SSL_CTX_set_cert_verify_callback — the "who even checks these certs" page 💖

okay bestie, this is an OpenSSL manpage (manual section 3ossl, so it's a library function, not a command you type). buckle up 🎀

✨ NAME ✨

SSL_CTX_set_cert_verify_callback — set peer certificate verification procedure

like... you get to decide who's allowed in. main character behaviour, honestly. 👑

🌸 SYNOPSIS 🌸

#include <openssl/ssl.h>

void SSL_CTX_set_cert_verify_callback(SSL_CTX *ctx,
                                      int (*callback)(X509_STORE_CTX *, void *),
                                      void *arg);

🦋 DESCRIPTION 🦋

so SSL_CTX_set_cert_verify_callback() sets the verification callback function for ctx. that's it, that's the whole thing. 💅

and here's the inheritance lore: SSL objects that get created from ctx inherit the setting that was valid at the time when SSL_new(3) is called. so whatever was set then is what they get — not whatever you set later. timing is everything, fr fr. ⏰

🌈 NOTES 🌈

okay this is the big section, hydrate first 🍓

When a peer certificate has been received during an SSL/TLS handshake, a verification function is called — regardless of the verification mode. like, it's happening no matter what, periodt.

If the application does not explicitly specify a verification callback function, the built-in verification function is used. the OG, the default, the factory setting ✨

If a verification callback callback is specified via SSL_CTX_set_cert_verify_callback(), the supplied callback function is called instead, with the arguments:

callback(X509_STORE_CTX *x509_store_ctx, void *arg)

The argument arg is specified by the application when setting callback. And by setting callback to NULL, the default behaviour is restored. undo button, we love her 🙈

callback should return 1 to indicate verification success and 0 to indicate verification failure. simple as that.

  • server mode: a return value of 0 leads to handshake failure. bye bestie 💀
  • client mode: okay this one's a whole vibe, here's how it goes down:
    • All values, including 0, are ignored if the verification mode is SSL_VERIFY_NONE.
    • Otherwise, when the return value is less than or equal to 0, the handshake will fail.

Now, in client mode, callback may also call the SSL_set_retry_verify(3) function on the SSL object set in the x509_store_ctx ex data (see SSL_get_ex_data_X509_STORE_CTX_idx(3)) and return 1. this would be typically done in case the certificate verification was not yet able to succeed. 🔥

what happens then is genuinely iconic: this makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect(3) again resumes the connection attempt by retrying the server certificate verification step. and this process may even be repeated if need be. it's giving persistence. 💪

In any case a viable verification result value must be reflected in the error member of x509_store_ctx, which can be done using X509_STORE_CTX_set_error(3). This is particularly important in case the callback allows the connection to continue (by returning 1).

⚠️ Note that the verification status in the store context is a possibly durable indication of the chain's validity! This gets recorded in the SSL session (and thus also in session tickets) and the validity of the originally presented chain is then visible on resumption, even though no chain is presented int that case. Moreover, the calling application will be informed about the detailed result of the verification procedure and may elect to base further decisions on it.

(yeah the original says "int that case" — typo is canon, keeping it exactly 💜)

callback may call X509_verify_cert(3) to run the built-in verification function. This may be useful if application wishes to dynamically reconfigure x509_store_ctx before verification, or postprocess the result. In this case, X509_verify_cert(3) will set the error member as described above. 🫶

Within x509_store_ctx, callback has access to the verify_callback function set using SSL_CTX_set_verify(3).

⭐ RETURN VALUES ⭐

SSL_CTX_set_cert_verify_callback() does not return a value.

not a single crumb. void. nothing to check, nothing to obsess over. 🎀

🚨 WARNINGS 🚨

Do not mix the verification callback described in this function with the verify_callback function called during the verification process. The latter is set using the SSL_CTX_set_verify(3) family of functions.

two different callbacks, two different jobs, do NOT let them get tangled. that's a situationship you do not want. 😭

Providing a complete verification procedure including certificate purpose settings etc is a complex task. The built-in procedure is quite powerful and in most cases it should be sufficient to modify its behaviour using the verify_callback function. like bestie, just use the built-in one and tweak it, trust. 🙏

💀 BUGS 💀

SSL_CTX_set_cert_verify_callback() does not provide diagnostic information.

so when it goes wrong, it goes wrong quietly. no receipts, no explanation, nothing. 💀

👑 SEE ALSO 👑

Copyright 2001-2022 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>.

okay that's the whole page, you ate it, no crumbs left 🌈💅

this was OpenSSL 3.5.9, dated 2026-09-29, and it's the SSL_CTX_SET_...IFY_CALLBACK(3ossl) page from the OpenSSL manual. go forth and verify those certs, bestie 🦋✨💖

📦 where this page comes from