As an update, I've been able to triage this a bit further.
It's definitely that last noted change (erroring out on expired self-signed
root) that broke it. OpenSSL 1.1.1{g,h} are fine, but {i,-stable} are
not. Reverting just x509_vfy.c to what is in 1.1.1h causes the test to
pass.
In this test case, Serf receives 2 verify callbacks in test_ssl_handshake.
The first failing test case is to not have a known CA - so, we are
intentionally trying to trigger a verify failure. One of the app
callback received has the expected failure, the other doesn't. Serf
basically flags the second (success) as an unexpected pass.
2020-12-28T16:51:34.045142-05 test/test_ssl.c: Cert failure received: 4 ;
expected failure mask: 4
2020-12-28T16:51:34.045159-05 test/test_ssl.c: Cert failure received: 0 ;
expected failure mask: 4
The upstream issues/commits appear to be:
https://github.com/openssl/openssl/issues/13427
https://github.com/openssl/openssl/commit/3bed88a3970605a2ff817065f93b08e965d89e5f#diff-2a76d0a7ddc5ae2646a6c183270a7b4d5302d8491acb0af0dfbd70643efdf431
The key difference is almost certainly this change:
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1h/crypto/x509/x509_vfy.c#L1754
---
return verify_cb_cert(ctx, xi, 0,
X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE);
---
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/x509/x509_vfy.c#L1755
---
if (!verify_cb_cert(ctx, xi, 0,
X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE))
return 0;
xs = xi;
goto check_cert_time;
---
Up to 1.1.1h, OpenSSL would stop processing the certificate after sending
along the leaf error to the app callback. In -stable (1.1.1i+ and master),
if the app's callback doesn't return a failure, it will then proceed to the
date check portion (check_cert_time) - which then receives a successful
verification callback.
It's not clear to me if OpenSSL authors intended to make this breaking
change. On the serf side, we would need to think through what it would
mean to have our app callback return false upon failure in order to
short-circuit the check.
I probably won't get a chance to open an upstream OpenSSL issue today (or
even tomorrow)...
Cheers. -- justin
Index: test/test_ssl.c
===================================================================
--- test/test_ssl.c (revision 1884847)
+++ test/test_ssl.c (working copy)
@@ -465,6 +465,7 @@
tb->result_flags |= TEST_RESULT_SERVERCERTCB_CALLED;
+ test__log(TEST_VERBOSE, __FILE__, "Cert failure received: %d ;
expected failure mask: %d\n", failures, expected_failures);
/* We expect an error from the certificate validation function. */
if (failures & expected_failures)
return APR_SUCCESS;
On Sun, Dec 27, 2020 at 11:22 AM James McCoy <james...@debian.org> wrote:
> On Sun, Dec 27, 2020 at 10:46:24AM -0500, Justin Erenkrantz wrote:
> > Thanks. I expect that this might be due to the last change - erroring
> out on
> > an expired self-signed root cert. Though I thought we didn’t check in a
> root
> > cert for our test chain...could Debian’s packaging be including a cert
> for
> > testing?
>
> I use create_certs.py from trunk to re-generate the test certificates
> every build, otherwise I was running into time bombs with the certs
> expiring. Other than that, I don't do anything different than the
> normal test process.
>
> The Debian packaging does have some local patches[0] applied to address
> issues that have been fixed upstream but not yet released.
>
> [0]: https://sources.debian.org/patches/serf/1.3.9-8/
>
> > I will try to take a look this week with Debian sid...I assume it has
> 1.1.1i
> > already? — justin
>
> Yes, it does.
>
> Cheers,
> --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
>
