SSL_get_verify_result() doesn't actually do any verification; it returns (part of) the result of the cert verification (if any) done during the most recent full handshake (if any) on the given
SSL object. Assuming you really want to know what that verification did, it depends a good bit on the application code.
If the code sets a callback with
SSL_CTX_set_cert_verify_callback before creating the
SSL object, then the verification during handshake consists entirely of calling that callback -- whatever the callback does is what it does. If this callback is not set, as the man page says, a 'built-in verification function' is used, which is actually
X509_verify_cert() (which has its own not very helpful man page) and what that does is roughly what is described on the verify(1) man page as referenced by John, plus some things that have been added over time but didn't always make it into the doc (e.g. NameConstraints and DANE, not to mention some revocation checking), but this checking can be altered and 'tweaked' by numerous options and parameters, not all of which are usable for verify(1), and most settable at either the
SSL level, including an optional 'verify_callback' which is separate and quite different from the 'cert_verify_callback' mentioned above. See the man pages for
SSL_[CTX_]load_verify_locations et rel,
X509_STORE_CTX_* functions including
X509_STORE_CTX_set0_param and related
X509_VERIFY_PARAM* functions especially
And if that's not exact enough, and it may well not be, check the source -- for the version you are (or will be) running, since there have been some changes in this (quite complex) area over time. Explaining exactly everything it does, even in a particular version, would (almost certainly) exceed the Stack answer limit and would take me about a week, as well as likely becoming obsolete soon, so I won't do that. If you have one or a very few specific issues, that could be answerable in a practical amount of time.