Hi,

By default wolfSSL does all certificate verification internally.  The user can inspect and do custom verification using the wolfSSL verify callback.  The callback can be registered by passing it as the third argument to the wolfSSL_CTX_set_verify() function.  Ex:

void wolfSSL_CTX_set_verify(WOLFSSL_CTX* ctx, int mode, VerifyCallback vc);
typedef int (*VerifyCallback)(int preverify, WOLFSSL_X509_STORE_CTX* store);

Normally, the verify callback is only called upon verification failure.  If you define WOLFSSL_ALWAYS_VERIFY_CB, the callback will always be called.  In this case, if "preverify" is equal to "1", wolfSSL has already successfully verified the peer certificate.  We provide this option for those users who wish to do custom inspection of certificate elements past normal certificate verification measures.

We have an example verify callback that overrides date errors.  It is called "myDateCb()", located in <wolfssl/test.h>.

Best Regards,
Chris

Hi,

Can you send me the output of your wolfSSL debug log for the case you think is odd/incorrect?  wolfSSL debugging can be enabled by compiling wolfSSL with DEBUG_WOLFSSL, then calling wolfSSL_Debugging_ON() as the first wolfSSL function call in your application code.

Thanks,
Chris

wolfSSL Entering WOLFSSL_CTX_new
wolfSSL Entering wolfSSL_CertManagerNew
wolfSSL Leaving WOLFSSL_CTX_new, return 0
wolfSSL Entering wolfSSL_CTX_set_verify
wolfSSL Entering wolfSSL_CTX_load_verify_locations
Getting dynamic buffer
Processing CA PEM file
wolfSSL Entering PemToDer
Adding a CA
wolfSSL Entering GetExplicitVersion
wolfSSL Entering GetMyVersion
Got Cert Header
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
Got Algo ID
Getting Cert Name
Getting Cert Name
Got Subject Name
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
Got Key
Parsed Past Key
wolfSSL Entering DecodeCertExtensions
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeKeyUsage
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeBasicCaConstraint
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeSubjKeyId
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeAuthKeyId
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
    Parsed new CA
    Freeing Parsed CA
    Freeing der CA
        OK Freeing der CA
wolfSSL Leaving AddCA, return -150
wolfSSL error occurred, error = -150
CA Parse failed, with progress in file.
Search for other certs in file
wolfSSL Entering ERR_error_string
error loading up CA cert: ASN date error, current date before
wolfSSL Entering SSL_CTX_free
CTX ref count down to 0, doing full free
wolfSSL Entering wolfSSL_CertManagerFree
wolfSSL Leaving SSL_CTX_free, return 0
wolfSSL Entering wolfSSL_Cleanup

Thanks for the reply. Is there any way to override this behavior?

This doesn't quite make sense to me. Isn't the certificate chain updated during the handshake? Would this callback be able to override data errors there??

Also, what about OCSP checks? Does this callback override those, or does it not?

I did a test where I added a date override callback, rolled back my clock, and tried to connect.

About to verify certificate signature
No CA signer to verify with
Failed to verify Peer's cert
    Callback override available, will continue
wolfSSL Entering InitOcspRequest
----------- date_override_cb -------------
wolfSSL Entering ERR_error_string
In verification callback, error = -188, ASN no signer error to confirm failure
Subject's domain name is officeapps.live.com
Cert error is not date error, not overriding
growing output buffer

Now, I know for a fact that I have the right CA cert loaded up, coz when I pull the clock to real time, this works. Looks like the error reporting here is incorrect. I looked at the code, there is indeed, a call to ParseCertRelative, which does a date check...

So it seems like this override callback is not really doing what it claims, or I am doing something wrong. Not sure which is the case.