SSL_CTX_SET_C...RIFY_CALLBACK(3SSL)

📦
version 4.0.3 · 14 versions
, in ubuntu stonking

💖 NAME 💖

SSL_CTX_set_cert_verify_callback — bestie, this is how you set your own peer certificate verification procedure. Slay.

✨ SYNOPSIS ✨

#include <openssl/ssl.h>

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

🌸 DESCRIPTION 🌸

Okay so SSL_CTX_set_cert_verify_callback() sets the verification callback function for ctx. And here's the tea: every SSL object that gets created from ctx inherits whatever setting was valid at the exact time SSL_new(3) was called. So set it up before you spawn your SSLs, mkay? 👑

🎀 NOTES 🎀

So when a peer certificate shows up during an SSL/TLS handshake, a verification function gets called — regardless of the verification mode. Like, always. No skips.

If the application doesn't explicitly specify a verification callback function, the built-in verification function gets used. That's the default bestie. But if a verification callback callback is specified via SSL_CTX_set_cert_verify_callback(), then your supplied callback gets called instead, with the args callback(X509_STORE_CTX *x509_store_ctx, void *arg). The argument arg is the one the application specified when it set callback. And if you set callback to NULL? The default behaviour comes right back. Restored. ✨

callback should return 1 to say "verification success 💅" and 0 to say "verification failure 💀". Now here's the nuance:

  • In server mode, a return value of 0 leads to handshake failure.
  • In client mode, the behaviour is as follows. 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.

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 typically be done in case the certificate verification wasn't yet able to succeed — like a "hold on, not done yet 💅" moment. 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. Then calling SSL_connect(3) again resumes the connection attempt by retrying the server certificate verification step. And this whole process may even be repeated if need be. Iconic, honestly.

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! It 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 in 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. So like, no cap, that error member matters. 🫶

callback may call X509_verify_cert(3) to run the built-in verification function. This may be useful if the 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. Convenient!

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. Nothing. Void. It's giving minimalism. 💅

⚠️ WARNINGS ⚠️

Do not mix the verification callback described in this function with the verify_callback function called during the verification process. They are NOT the same thing, bestie, and mixing them up will ruin your whole day. The latter is set using the SSL_CTX_set_verify(3) family of functions. 🚨

Providing a complete verification procedure including certificate purpose settings etc. is a complex task. Like, genuinely hard. The built-in procedure is quite powerful and in most cases it should be sufficient to modify its behaviour using the verify_callback function. Don't reinvent the wheel unless you truly have to, fr fr.

💀 BUGS 💀

SSL_CTX_set_cert_verify_callback() does not provide diagnostic information. That's it. That's the bug. No clues, no hints, just vibes. 😭

👑 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>.

and that's the whole page, bestie!! this one's from OpenSSL version 4.0.3, dated 2026-09-2 — go verify some certs, you absolute main character 💖✨🎀🦋🌸💅🫶

📦 where this page comes from