We got a report of an incompatibility with OpenSSL 3.6 at https://crbug.com/454485898. There was an error-reporting issue that makes the output a little confusing, but the root cause was a regression in OpenSSL 3.6. OpenSSL 3.6 servers with stapled OCSP responses are unable to complete a handshake with BoringSSL clients, including Chrome, due to this malformed message.

The CertificateStatus structure, carried in the status_request extension in TLS 1.3, is defined as follows:

  enum { ocsp(1), (255) } CertificateStatusType;

  struct {
      CertificateStatusType status_type;
      select (status_type) {
          case ocsp: OCSPResponse;
      } response;
  } CertificateStatus;

  opaque OCSPResponse<1..2^24-1>;

https://www.rfc-editor.org/rfc/rfc6066.html#section-8
https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2.1

Notice that OCSPResponse cannot be empty. This is because you're expected to omit the message (or extension) when you do not have an OCSP response to staple. However, it seems that #20945 regressed this. When there is a stapled OCSP response available for one certificate, it seems OpenSSL 3.6 will include the status_request extension for all certificates, putting an empty response for the missing ones.

I believe the bug is that tls_construct_stoc_status_request only returns EXT_RETURN_NOT_SENT based on s->ext.status_expected, but after that PR, that only tells you if any certificate needs the extension, not this particular certificate.