Closed job closed 5 months ago
The comment about error checking and OpenSSL 3 API is in relationship to https://github.com/openssl/openssl/issues/24575
We cannot rely on "return codes <= 0 indicate error", because "2" also could be an error. So we need to explicitly check whether it's 1 or not
I'm angsting over this note:
X509_verify_cert()
doesn't check the purported root certificate itself unlessX509_V_FLAG_CHECK_SS_SIGNATURE
is set.
I take it the reason why you're verifying the signature manually (as opposed to adding X509_V_FLAG_CHECK_SS_SIGNATURE
) is because Fort skips X509_verify_cert()
on trust anchors?
That short circuit is looking quite naive now that you've introduced me to X509_V_FLAG_CHECK_SS_SIGNATURE
.
You could add the X509_V_FLAG_CHECK_SS_SIGNATURE
if you prefer that. That's more expensive since then you check the TA's signature each time you call X509_verify_cert()
. This isn't necessary if you only add trust anchors and other certs that you verified to your verified_certstack()
.
Not doing the 'naive' short-circuit wouldn't have helped without that CHEC_SS
flag.
Thank you
X509_verify_cert()
doesn't check the purported root certificate itself unlessX509_V_FLAG_CHECK_SS_SIGNATURE
is set.The pubkey was compared against the TAL, so check that the signature is right as required by RFC 6487, section 7.2, additional condition 1, applied to self-issued certs.
The error check looks weird, but OpenSSL 3 broke yet another API.
With help from Theo Buehler and Claudio Jeker