chain_build(): Call verify_cb_cert() if a preliminary error has become final #14157
Conversation
|
I'm not sure how useful this really is to applications. One of the problem is, as you say yourself, it will likely turn into a real error, but it might also just work. It's also not obvious what an application can do with it. |
|
|
|
No, the adapted idea as implemented in this PR invokes the callback only after the error has become final. |
|
24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually. |
openssl-machine
pushed a commit
that referenced
this pull request
Feb 18, 2021
…e final Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #14157)
|
Merged - thanks @t8m |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
In the context of #14094 the idea came up that it might be interesting to call the verification callback function (if provided) already during the chain construction phase of certificate verification when something is likely to go wrong.
A typical example is
check_issued()inx509_vfy.c, which meanwhile can produce preliminary errors during chain building, such asX509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH. At this pointverify_cb_cert(ctx, x, ctx->error_depth, err)might be called, which not only would give an application the chance to learn about this specific problem but even to influence the chain building. Even without the callback being involved, the error may become final, may get overridden by some other error, or maybe the chain building succeeds on some other way such that in the end no error is thrown.@t8m wrote about this:
This sounds reasonable, but note that we already have the situation that the verification callback may be used to waive errors regarding certificate validity period restrictions:
X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD
X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD
X509_V_ERR_CERT_NOT_YET_VALID
X509_V_ERR_CERT_HAS_EXPIRED
I tend to agree that any other errors such as the one mentioned above likely better should not be given to the verification callback. So I've modified my original proposal such that the callback is called only after chain building has failed and some preliminary error (except for the four ones regarding the certificate validity period restrictions) was thrown and has become final at this point. So the application can learn about the specific reason why chain building failed while so far this was possible only for the more general chain building errors:
X509_V_ERR_CERT_CHAIN_TOO_LONG
X509_V_ERR_DANE_NO_MATCH
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT
X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY
This modified idea is implemented in this PR.