<div dir="ltr"><div>Hi Viktor,</div><div><br></div><div>Thanks for the response. I should have phrased it better. What I meant to say was to "construct x509_store_ctx from the data  in the SSL received in the OCSP response callback". <br></div><div>Regarding this<span style="color:rgb(0,0,0)"> "
What real problem are you actually trying to solve.  How does doing<br>
something with OCSP solve it?" -> its a business decision. So don't have a choice there.</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">I went through parts of openssl code related to this. <br></span></div><div><span style="color:rgb(0,0,0)">a]"</span>
Has the validated chain already been constructed<br>
by the time your callback runs" -> The idea is to call the certificate chain verification callback as a normal function within the OCSP callback. By callback I mean a custom verification function which ends up calling X509_verify_cert down the line by setting up certs and crls. So at this point, we would have access only to the unvalidated peer cert stack. The certificate verification chain callback though anyway expects the unvalidated chain itself and is supposed to validate the chain itself. So it should be as expected. But on the course of checking it, I see when the callback is invoked by openssl, it does a bunch of pre and post setups. For example as part of post setup I see it is setting the verification result and verification chain. I see a problem here if we try to do this at the application level (We receive precompiled openssl and can't modify that). Some parts are not exposed at application level, for example verified chain parameter. There's no way to set it from the application(openssl 1.1.1q), and the structure itself is opaque and members cant be accessed directly. And there's a bunch of stuff related to danetls and suiteb algorithms as part of pre-setup which are again static. <br></div><div>Please correct me if any of the above understanding is incorrect. Being unable to do these pre and post setups looks to be a bad idea both from security perspective and keeping it compatible with new openssl versions. So I felt this wouldnt work. If there's any other way around it, your inputs would be helpful</div><div><br></div><div>b]As an alternative approach, I thought of moving the revocation check outside the openssl provided X509_verify_cert. We are currently fetching and setting up the CRL and use the openssl provided X509_verify_cert which seems to be doing the revocation check with "check_revocation()" function. If the functionality done by this routing has to be simulated at application level, again I see they're not exposed to applications. I did some search to see if there's an openssl api that provides revocation checking against a cert chain as a standalone routine(that is, excluding chain building, signature checking, timestamp checking etc). But I wasn't able to find any. If you have any suggestions on this please let me know</div><div><br></div><div>Any inputs on these would be very helpful</div><div><br></div><div>Thanks</div><div>Akshath<br></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><font color="#888888"><br></font>

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 21, 2023 at 9:02 PM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Mar 21, 2023 at 07:07:42PM +0530, Akshath Hegde wrote:<br>
<br>
> My intention is to call the certificate verification function callback as a<br>
> normal function inside the OCSP callback (the reason why this is done is<br>
> due to a separate issue with callback ordering)<br>
> The certificate verification function is set through<br>
> SSL_CTX_set_cert_verify_cb(), and the callback is of the form<br>
> int (*cert_verify_cb) (X509_STORE_CTX *, void *)<br>
> <br>
> So to be able to call this inside the OCSP callback, I'd need to<br>
> reconstruct the X509_STORE_CTX argument. I'm not very familiar with<br>
> openssl internals, so forgive me if this is silly.<br>
<br>
There's nothing to "reconstruct" the X509_STORE_CTX in question is an<br>
ephemeral object, that lives just long enough to perform the certificate<br>
chain construction, validation and subject identity checks.<br>
<br>
The related persistent objects are the X509_STORE, which is loaded with<br>
the trusted certificates, and X509_VERIFY_PARAM structure which holds<br>
the identity to check, the "purpose" (sslserver vs. sslclient), and<br>
various flags.<br>
<br>
The X509_STORE_CTX is then initialised with the EE certificate to<br>
validate, any related untrusted certificates that may help to build the<br>
chain, the X509_STORE to find trusted issuers and the X509_VERIFY_PARAM<br>
to tweak the process.<br>
<br>
If you want to verify some certificate chain other than the one that<br>
is verlfied automatically as part of the TLS handshake, you'll need<br>
to assemble your own X509_STORE_CTX.<br>
<br>
> 1)Is it conceptually right to do so?<br>
<br>
Hard to say.  Ideally OCSP would be handled automatically internally in<br>
OpenSSL, once you configure OpenSSL to do so.  If not, perhaps someone<br>
could be persuaded to contribute better built-in OCSP support.  I am not<br>
a fan of OCSP (lots of ceremony for little gain IMHO), so I'm not<br>
volunteering.<br>
<br>
> 2)Is it possible to construct x509_store_ctx from ssl?<br>
<br>
Wrong question.  You can construct it from a STORE and verification<br>
parameters and a set of certificates to check.  The SSL handle can<br>
be queried for the store and the verification paramters.<br>
<br>
> 3)I could extract the peer cert chain from SSL through<br>
> SSL_get_peer_cert_stack() and create a x509_store_ctx.<br>
<br>
Timing is everything. Has the validated chain already been constructed<br>
by the time your callback runs?  Are certificates other than the EE cert<br>
relevant for OCSP? ... Are you looking at the chain as sent by the peer<br>
or as validated by OpenSSL, the two may not be the same.<br>
<br>
> But this wouldn't be identical to how it's created originally and<br>
> might lack information. If it's correct to do so and possible, what's<br>
> the right method to create it?<br>
<br>
It sounds to me like you're lost in the concepts.  Which will almost<br>
certainly mean that whatever you concoct, even if it appears to work may<br>
not achieve any productive security goals.  Perhaps the best answer is<br>
to not bother OCSP until you've a better grasp of the fundamentals.<br>
<br>
> Do you see any alternative to overall approach?  (For the original<br>
> problem, please have a look at thread named "Stapled OCSP<br>
> Response")<br>
<br>
What real problem are you actually trying to solve.  How does doing<br>
something with OCSP solve it?<br>
<br>
-- <br>
    Viktor.<br>
</blockquote></div>