Hi Akshath, I don't know of any APIs provided by OpenSSL for parsing the Certificate message (the ones I think you found for the ClientHello are specific to the context of the client_hello callback I mentioned, and even they leave a fair amount of parsing to the caller). The internal parser code is roughly at https://github.com/openssl/openssl/blob/master/ssl/statem/statem_clnt.c#L1853 but extracting it for standalone use would require a fair bit of effort and understanding of the wire protocol. I do recommend using an abstraction for counted byte buffers akin to the PACKET_* APIs here (or boringssl's CBB APIs) to avoid buffer overflow attacks when parsing. -Ben On Mon, Mar 06, 2023 at 10:05:15PM +0530, Akshath Hegde wrote: > Hi Benjamin, > 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. > Thanks > Akshath > On Fri, Mar 3, 2023 at 6:08 AM Benjamin Kaduk <[1]bkaduk@xxxxxxxxxx> > wrote: > > I don't know about (1) offhand, but (inline) > > On Thu, Mar 02, 2023 at 05:25:48PM +0530, Akshath Hegde wrote: > > Hi, > > I had few questions about OCSP stapling for intermediate > certificates. > > On the client side I'm adding "certificate status request" > extension to > > ClientHello message. For server, Im using an apache httpd server > which has > > OCSP responder details configured in ssl module. THe negotiated TLS > > version is 1.3 > > 1)The server has a multi tier cert chain. But it seems to be > sending the > > OCSP response for only the end entity certificate. Apache > documentation > > seems to suggest this is expected and multi-stapling is not > supported. Is > > anyone aware of a http server that supports multi-stapling? > > 2)On the client side, I'm registering for the OCSP response > callback with > > SSL_CTX_set_tlsext_status_cb. > > In case of a multi tiered cert chain and OCSP response for each > cert, is > > this callback called once for each response?, or only one time? > > If its called only only one time, how are the responses accessed? > > SSL_get_tlsext_status_ocsp_response -> seems to return only one > OCSP > > response. > > And I haven't been able to try tis for the lack of multi-stapling > support > > in http server > > It looks like it is just called once at the end of processing the > server's first flight. > The API was clearly designed prior to TLS 1.3 and not modernized as part > of the TLS 1.3 implementation; > the updates were pretty minimal (see commit > 7776a36cfa5853175a858fa32983f22f36513171 that just generalizes > from "process ServerDone" to "process server's first flight"). > > 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. > > > 3)The OCSP response callback seems to be called after the cert > chain > > verification callback has ended. Is there any reason for this?. The > > authenticity of OCSP response is established by a different chain > (OCSP > > response -> CA that signed cert), and doesn't need to wait for the > server > > end entity verification?. So instead of CRL, OCSP could have been > used > > during cert chain verification > > I did not specifically go dig into the VCS history, but in general > OpenSSL's > callback interfaces are not part of a intentional wholistic design; most > were > added as one-offs to meet a specific purpose and they often can interact > with > each other in quite unfortunate ways. On the server side, many of the > callbacks are mostly superseded by the "client hello callback" that runs > very > early and has well-defined interactions with other callbacks (and can > act > before libssl has started processing anything), at the cost of needing > to do > more parsing of the data by hand. That doesn't help you here, of > course; if > you need to see all the OCSP responses you will probably need to use a > message > callback (SSL_CTX_set_msg_callback()) in order to get access to the > multi-staple. > > -Ben > > Links: > 1. mailto:bkaduk@xxxxxxxxxx/
