<div dir="ltr"><div>Hi Benjamin,</div><div>Thanks a lot for the information. I'm trying out  
SSL_CTX_set_msg_callback() now. Are there any parsers available for extracting contents of Certificate message?. I have been searching and I could see them for ClientHello but not the others. </div><div><br></div><div>Thanks</div><div>Akshath<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 3, 2023 at 6:08 AM Benjamin Kaduk <<a href="mailto:bkaduk@akamai.com">bkaduk@akamai.com</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">I don't know about (1) offhand, but (inline)<br>
<br>
On Thu, Mar 02, 2023 at 05:25:48PM +0530, Akshath Hegde wrote:<br>
>    Hi,<br>
>    I had few questions about OCSP stapling for intermediate certificates.<br>
>    On the client side I'm adding  "certificate status request" extension to<br>
>    ClientHello message. For server, Im using an apache httpd server which has<br>
>    OCSP responder details configured in ssl module. THe negotiated TLS<br>
>    version is 1.3<br>
>    1)The server has a multi tier cert chain. But it seems to be sending the<br>
>    OCSP response for only the end entity certificate. Apache documentation<br>
>    seems to suggest this is expected and multi-stapling is not supported. Is<br>
>    anyone aware of a http server that supports multi-stapling?<br>
>    2)On the client side, I'm registering for the OCSP response callback with<br>
>    SSL_CTX_set_tlsext_status_cb.<br>
>    In case of a multi tiered cert chain and OCSP response for each cert, is<br>
>    this callback called once for each response?, or only one time?<br>
>    If its called only only one time, how are the responses accessed?<br>
>    SSL_get_tlsext_status_ocsp_response -> seems to return only one OCSP<br>
>    response.<br>
>    And I haven't been able to try tis for the lack of multi-stapling support<br>
>    in http server<br>
<br>
It looks like it is just called once at the end of processing the server's first flight.<br>
The API was clearly designed prior to TLS 1.3 and not modernized as part of the TLS 1.3 implementation;<br>
the updates were pretty minimal (see commit 7776a36cfa5853175a858fa32983f22f36513171 that just generalizes<br>
from "process ServerDone" to "process server's first flight").<br>
<br>
For TLS 1.3 you only get the response for the end-entity certificate; we specifically ignore the extension for other certificates in the chain.<br>
<br>
>    3)The OCSP response callback seems to be called after the cert chain<br>
>    verification callback has ended. Is there any reason for this?. The<br>
>    authenticity of OCSP response is established by a different chain  (OCSP<br>
>    response -> CA that signed cert), and doesn't need to wait for the server<br>
>    end entity verification?. So instead of CRL, OCSP could have been used<br>
>    during cert chain verification<br>
<br>
I did not specifically go dig into the VCS history, but in general OpenSSL's<br>
callback interfaces are not part of a intentional wholistic design; most were<br>
added as one-offs to meet a specific purpose and they often can interact with<br>
each other in quite unfortunate ways.  On the server side, many of the<br>
callbacks are mostly superseded by the "client hello callback" that runs very<br>
early and has well-defined interactions with other callbacks (and can act<br>
before libssl has started processing anything), at the cost of needing to do<br>
more parsing of the data by hand.  That doesn't help you here, of course; if<br>
you need to see all the OCSP responses you will probably need to use a message<br>
callback (SSL_CTX_set_msg_callback()) in order to get access to the<br>
multi-staple.<br>
<br>
-Ben<br>
</blockquote></div>