[Bug]: Failed validation against the CAs loaded into WolfSSL doesn't trigger validation using Apple's API

[arekmula]

Contact Details

arekmula97@gmail.com

Version

5.8.4

Description

Configure flags:

./configure flags: --disable-shared --enable-static --prefix=/ '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' --disable-examples --disable-crypttests --enable-harden --enable-debug=yes --enable-opensslall=yes --enable-opensslextra=yes --enable-sslv3=no --enable-alpn=no --enable-des3=no --enable-tls13=yes --enable-certgen=no --enable-dsa=no --enable-ripemd=no --enable-sessioncerts=no --enable-sni=no --enable-testcert=no --enable-shared=no --enable-static=yes --enable-asio --enable-altcertchains --enable-sys-ca-certs CC=/opt/homebrew/opt/llvm@20/bin/clang 'CFLAGS= -fPIC -g -mmacosx-version-min=15.0 -DWOLFSSL_APPLE_NATIVE_CERT_VALIDATION -framework CoreFoundation -framework Security' 'LDFLAGS= -mmacosx-version-min=15.0' CPPFLAGS=

Hey,

When the support for System Certificate Store is enabled on Apple platforms, and the validation of the peer cert chain against the CAs loaded into wolfSSL fails, wolfSSL wants to validate it against the system certificates using Apple's native trust APIs:

#if defined(__APPLE__) && defined(WOLFSSL_SYS_CA_CERTS)
    /* If we can't validate the peer cert chain against the CAs loaded
     * into wolfSSL, try to validate against the system certificates
     * using Apple's native trust APIs */
    if ((ret == WC_NO_ERR_TRACE(ASN_NO_SIGNER_E)) &&
        (ssl->ctx->doAppleNativeCertValidationFlag)) {
        if (DoAppleNativeCertValidation(ssl, args->certs,
                                             args->totalCerts)) {
            WOLFSSL_MSG("Apple native cert chain validation SUCCESS");
            ret = 0;
        }
        else {
            WOLFSSL_MSG("Apple native cert chain validation FAIL");
        }
    }
#endif /* defined(__APPLE__) && defined(WOLFSSL_SYS_CA_CERTS) */

    /* Do leaf verify callback when it wasn't called yet */
    if (ret == 0 || ret != args->leafVerifyErr)
        ret = DoVerifyCallback(SSL_CM(ssl), ssl, ret, args);

To make it happen, the ret must be equal to ASN_NO_SIGNER_E. However, the value will never be equal to ASN_NO_SIGNER_E if the verify callback is set and returns true because it will be overwritten here:

/* Do verify callback. */
  args->leafVerifyErr = ret =
          DoVerifyCallback(SSL_CM(ssl), ssl, ret, args);

  #if defined(__APPLE__) && defined(WOLFSSL_SYS_CA_CERTS)
  /* Disregard failure to verify peer cert, as we will verify
   * the whole chain with the native API later */
  if (ssl->ctx->doAppleNativeCertValidationFlag) {
      WOLFSSL_MSG("\tApple native CA validation override"
                  " available, will continue");
      /* check if fatal error */
      args->fatal = (args->verifyErr) ? 1 : 0;
      if (args->fatal)
          DoCertFatalAlert(ssl, ret);
  }

and the native cert validation will never be called.

The value of ret may be retained only if the verify callback fails, but then args->verifyErr is set and we end up here:

  args->fatal = (args->verifyErr) ? 1 : 0;
  if (args->fatal)
      DoCertFatalAlert(ssl, ret);

The ret can also be retained if the verify callback is not set at all.

Is it intended behaviour? It was introduced within this #9144.

I believe it can be fixed like this:

  /* Do verify callback. */
  args->leafVerifyErr = ret =
          DoVerifyCallback(SSL_CM(ssl), ssl, ret, args);

  #if defined(__APPLE__) && defined(WOLFSSL_SYS_CA_CERTS)
  /* Disregard failure to verify peer cert, as we will verify
   * the whole chain with the native API later */
  if (ssl->ctx->doAppleNativeCertValidationFlag) {
      WOLFSSL_MSG("\tApple native CA validation override"
                  " available, will continue");

      /* check if fatal error */
      if (ret != 0 && ret != WC_NO_ERR_TRACE(ASN_NO_SIGNER_E)) {
          args->fatal = (args->verifyErr) ? 1 : 0;
          if (args->fatal)
              DoCertFatalAlert(ssl, ret);
      }
  }

Reproduction steps

No response

Relevant log output

[bigbrett]

Hi @arekmula, Thanks for the detailed write-up.

Although admittedly odd, what you are seeing is the expected behavior, given the conceptual role of verify callbacks and how the code is currently architected. The two features are essentially mutually exclusive.

A verify callback is intended as a per‑cert trust override that is invoked on each (failed) cert in the chain and is expected to make a go/no‑go trust decision immediately for that cert. So if the callback returns success on a failing cert, it is implicitly saying “trust this cert,” which prevents the fallback from ever being triggered in the first place. If a callback returns fail on a cert then it is saying "abort the handshake now". This is incompatible with how the apple native cert validation is implemented, which seeks to defer intermediate trust errors to the end of the chain processing, at which point we "fall back" to the opaque system trust evaluation routine.

To make it happen, the ret must be equal to ASN_NO_SIGNER_E. However, the value will never be equal to ASN_NO_SIGNER_E if the verify callback is set and returns true because it will be overwritten here ... and the native cert validation will never be called.

I think this is where the confusion lies... In this case, if your verify callback returns true, you are explicitly saying "I trust this certificate, override the previous error. Conversely, if your verify callback returns false, you are explicitly saying "I agree with the internal trust assessment, the certificate is untrusted, fail immediately and abort the handshake. All of this is functionality is irrespective of the apple native cert chain validation.

I'm not sure I understand why you would want the apple native cert validation to still run at the end of the chain if your verify callback returns true (E.g. you trust the cert).

On the other hand, I could see scenarios where you might want the external apple validation to run and override failures at the end, even when your callbacks return false, especially if your callback doesn't have the trust anchors accessible to make an informed decision.

Can you give me more details on your use case and what you are trying to accomplish?

[arekmula]

I'm not sure I understand why you would want the apple native cert validation to still run at the end of the chain if your verify callback returns true (E.g. you trust the cert).

I encountered this while bumping from 5.7.4 to 5.8.4. My verification callback expects the preverification to succeed. If that's not the case, it returns a failure straightaway. While on 5.7.4, this assumption was correct because if the preverification against CAs loaded into WolfSSL failed, the fallback verification using Apple's API succeeded, and my callback was receiving the successful preverification, meaning it could proceed. After the bump to 5.8.4, my verification callback is called before the fallback preverification using Apple's native trust APIs, meaning it fails straightaway because the preverification against CAs loaded into WolfSSL failed.

My callback has the trust anchors accessible so it seems I need to adjust my callback.

[bigbrett]

@arekmula We are taking a deeper look at this internally to see whether it can be structured more cleanly. It may be possible to make a small change to restore the original behavior without otherwise affecting things. I will let you know.

However I do want to clarify one point:

My callback has the trust anchors accessible so it seems I need to adjust my callback.

If you already have access to the trust anchors, then why are you seeking to use the apple native cert validation to begin with? In this case, there should be no need to use Apple’s native certificate validation at all. That mechanism exists specifically for platforms where system-installed trust anchors are not accessible to the application, which is the case for non-macOS platforms such as iOS and tvOS.

The primary use case for the apple native verification stuff is IT-managed devices where administrators install and rotate root CAs via device management software. On those platforms, applications cannot load those roots directly into wolfSSL, so the only option is to ask the system to perform trust validation. If you do have access to the trust anchors, you can simply load them into wolfSSL (using wolfSSL_CTX_load_verify_*() and rely on the library’s standard internal certificate validation.

Additionally, if your verify callback is only being used to inject additional trust anchors so that Apple’s native validation can see them, then the callback should not be necessary either.

So unless I am missing something, you shouldn't need to use the apple native validation at all, and should be able to just use the normal wolfSSL flow. Unless there is some weird scenario here where your callback has ephemeral access to the trust store but the application that initializes wolfSSL does not?

Please let me know if I am misunderstanding your use case?

[arekmula]

Sorry for not being precise in my previous comment. When I said

My callback has the trust anchors accessible so it seems I need to adjust my callback.

I meant that I have access to the expected pinning hashes for the leaf/intermediates, not the system root CA certificates. My verify callback is doing certificate pinning, and is designed to only check pins on a valid chain. Because 5.8.4 invokes the callback before the Apple Native fallback has a chance to validate the chain, my callback sees the chain as invalid.

[bigbrett]

@arekmula understood, thanks. We should at least be able to revert the behavior to the pre-5.8.4. I will let you know.