SSL_GET_VERIFY_RESULT(3ossl)

πŸ“¦ version 3.5.0, in opensuse-leap 16.0

πŸ’… SSL_GET_VERIFY_RESULT πŸ’…

okay bestie, quick context: this is an OpenSSL manpage, section 3ossl β€” so like, the library-function part of the manual, not some random command you type. and this one? it's a little one-function wonder that answers the question "so… did the peer's certificate actually check out or not??" πŸŽ€


🌸 NAME 🌸

SSL_get_verify_result β€” get the result of the peer certificate verification πŸ¦‹


✨ SYNOPSIS ✨

#include <openssl/ssl.h>

long SSL_get_verify_result(const SSL *ssl);

that's it. one include, one function, one long coming back atcha. iconic behavior honestly. πŸ’…


πŸ”₯ DESCRIPTION πŸ”₯

SSL_get_verify_result() returns the result of the verification of the X509 certificate that the peer presented β€” if, like, any was presented at all. πŸ’β€β™€οΈ

⚠️ ok crucial thing, do not skip this: ssl MUST NOT be NULL. literally must not. no cap. if you pass NULL you're on your own and it's giving chaos. 😭

🌈 NOTES 🌈

so here's the tea, and it's a little bit of a bummer: SSL_get_verify_result() can only ever return one error code β€” but certificate verification can fail for many reasons all at the same time. πŸ’€ only the last verification error that occurred during processing is the one you can actually get out of SSL_get_verify_result().

sometimes there's a whole sequence of errors that led up to the verification failure that SSL_get_verify_result() reports. so if you want the full lore πŸ•΅οΈβ€β™€οΈ, you gotta set up a verify callback via SSL_CTX_set_verify(3) or SSL_set_verify(3) and pull the errors off the error stack in there β€” because once SSL_connect(3) returns, those errors may no longer be available. gone. poof. bestie where did they go. πŸ™ˆ

and good news for the reuse girlies: ✨ the verification result is part of the established session, and it gets restored when a session is reused. slay, consistency.


πŸ’€ BUGS πŸ’€

ok this is the trap and it is a real one:

if no peer certificate was presented, the returned result code is X509_V_OK β€” and that's lowkey the opposite of reassuring, because it's X509_V_OK simply because no verification error ever occurred. it does NOT indicate success. fr fr, read that again. 😳

so bottom line: SSL_get_verify_result() is only actually useful in connection with SSL_get_peer_certificate(3). use them together or the answer you get is basically a vibe, not a fact. 🫢


πŸŽ€ RETURN VALUES πŸŽ€

the following return values can currently occur:

  • X509_V_OK β€” the verification succeeded or no peer certificate was presented. (yes, both. see BUGS above. we been knew. 😭)
  • Any other value β€” documented in openssl-verify(1). go check there for the full alphabet of problems. πŸ“–

πŸ¦‹ SEE ALSO πŸ¦‹

ssl(7), SSL_set_verify_result(3), SSL_get_peer_certificate(3), openssl-verify(1) β€” the whole friend group, go say hi πŸ’–


Copyright 2000-2023 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 version 3.5.0, dated 2026-09-25 β€” go forth and always check SSL_get_peer_certificate(3) alongside your result, mwah πŸ’‹πŸŒΈβœ¨

πŸ“¦ where this page comes from