Since we have flash memory limitations, we would like to fit the code into as small a space as possible, while still maintaining adequate timing performance.  I am just trying to turn off things that we know we don't need.  NO_WOLFSSL_SERVER is one of them.  However, we haven't determined that the size is too large.  I would just like to be able to quantify how much turning off the server buys us.

@hayden,
One thing that seems to be missing in the wolfSSL tests is verification of the WOLFSSL_OCSP_CHECKALL option for OCSP stapling.  How will I be able to verify that this is working?  If I use this option in the tests, I get:
verify error:num=19:self signed certificate in certificate chain

First, I am using certificates in certs/ocsp.  I am creating 4 OCSP Responders, one for the root CA cert and one each for the 3 intermediate CA certs.  Then I am launching the server app (unmodified) and the client app (initially unmodified).  I first test with the -o option on the client and get an error -367, OCSP Responder lookup fail.  In Wireshark (trace attached) I see 3 OCSP Requests, one for the root CA cert, one for the intermediate CA cert, and one for the server cert.  Here are the commands for this test, each in its own command window:

C:\...\wolfSSL\certs\ocsp>openssl ocsp -port 22220 -index index-ca-and-intermediate-cas.txt -rsigner ocsp-responder-cert.pem -rkey ocsp-responder-key.pem -CA root-ca-cert.pem -nmin 11
C:\...\wolfSSL\certs\ocsp>openssl ocsp -port 22221 -index index-intermediate1-ca-issued-certs.txt -rsigner ocsp-responder-cert.pem -rkey ocsp-responder-key.pem -CA intermediate1-ca-cert.pem -nmin 5
C:\...\wolfSSL\certs\ocsp>openssl ocsp -port 22222 -index index-intermediate2-ca-issued-certs.txt -rsigner ocsp-responder-cert.pem -rkey ocsp-responder-key.pem -CA intermediate2-ca-cert.pem -nmin 6
C:\...\wolfSSL\certs\ocsp>openssl ocsp -port 22223 -index index-intermediate3-ca-issued-certs.txt -rsigner ocsp-responder-cert.pem -rkey ocsp-responder-key.pem -CA intermediate3-ca-cert.pem -nmin 4
C:\...\wolfSSL>Debug\server.exe -v 4 -c certs\ocsp\server1-cert.pem -k certs\ocsp\server1-key.pem
C:\...\wolfSSL>Debug\client.exe -v 4 -A certs\ocsp\root-ca-cert.pem -o

I am thinking the error is due to the root cert being self-signed.

OCSP Stapling works differently.  When I change the client code around line 3037 to this:

        //wolfSSL_CTX_EnableOCSP(ctx, 0);
        wolfSSL_CTX_EnableOCSP(ctx, WOLFSSL_OCSP_CHECKALL);
        wolfSSL_CTX_SetOCSP_Cb(ctx, NULL, NULL, NULL);

and run the same as above but change the client to this:

C:\...\wolfSSL>Debug\client.exe -v 4 -A certs\ocsp\root-ca-cert.pem -W 1

I get error -407, Invalid OCSP Status Error.  I also see only one OCSP request in the WireShark trace (attached to next post).

Finally, changing the code at line 3037 to this:

        wolfSSL_CTX_EnableOCSP(ctx, 0);
        //wolfSSL_CTX_EnableOCSP(ctx, WOLFSSL_OCSP_CHECKALL);
        wolfSSL_CTX_SetOCSP_Cb(ctx, NULL, NULL, NULL);

and rerunning the last commands results in success.  (Wireshark trace attached to last post.)

Wireshark trace without WOLFSSL_OCSP_CHECKALL and forcing OCSP Stapling attached.

After spending some time looking at your captures and doing similar experiments of my own, here's what I've found.

• I don't think turning on stapling and WOLFSSL_OCSP_CHECKALL in the client will have the desired effect of having the server get the statuses of the certs in the chain on behalf of the client. I built the client with WOLFSSL_OCSP_CHECKALL turned on, as you did, and ran the server with ./examples/server/server -v 3 -d -c ./certs/ocsp/server1-cert.pem -k ./certs/ocsp/server1-key.pem and client with examples/client/client -v 3 -W 1m -A ./certs/ocsp/root-ca-cert.pem. In Wireshark, I do see 3 OCSP requests, but only one is coming from the server. The other two (for the "non-leaf" certificates) are coming from the client. Hence, I think WOLFSSL_OCSP_CHECKALL is only relevant if you're doing vanilla OCSP, not OCSP stapling. That doesn't answer why the experiment fails, though. I'm pretty sure it's because the OCSP request for the root CA cert (serial number 99) has an issuerKeyHash of all zeros, for some reason. That's why the responder returns a cert status of "unknown" for this cert.

• As a separate experiment, I set up one machine to run the server and the responders, and a separate machine to run the client. I downgraded to TLS 1.2 and enabled OCSP stapling v2 (./configure --enable-ocspstapling2). From RFC 6961 for OCSP stapling v2: "Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain." That seems like the behavior you want. I ran the server with the same command as shown above but with -v 4 changed to -v 3, and the client (on the other machine) with ./client -h <server IP> -A ./certs/ocsp/root-ca-cert.pem -W 3m -v 3. This still fails because the OCSP request for the root CA cert has zeros for the issuerKeyHash, but it does correctly have the server reach out to the responders with 3 OCSP requests, and bundle the responses in a Certificate Status message that it sends back to the client.

To chart a path forward, I think I need to know more about your requirements. Is TLS 1.3 a must? If so, I don't believe that you can get multiple stapled OCSP responses from the server, per what I've shown above. You could use regular, non-stapling OCSP, though, if you need to check all certs in the chain and not just the peer's. If TLS 1.3 isn't required, then downgrading to TLS 1.2 and using -W 3m should do the trick. If you need both TLS 1.3 and the ability to check all certs with OCSP stapling (stapling v2), then I don't think we support that. For reasons unknown to me, stapling v2 is disallowed in TLS 1.3. See RFC 8446: https://tools.ietf.org/html/rfc8446#section-4.4.2.1. I'm asking my colleagues if there's another way outside of downgrading to TLS 1.2 to get what you want; I'll let you know if there is.

EDIT: After talking with some colleagues, we agree that it's possible with TLS 1.3 to get multiple stapled cert statuses (i.e. for the server's whole cert chain) from the server to the client in a single Certificate Status message. However, we don't currently support that with TLS 1.3. Right now, the server will only request its own cert status. If you are interested in us building support for this functionality, let us know.

Sure thing! Happy to help. And, just to be clear, I do think we can make this work for TLS 1.3, it would just be outside of OCSP stapling v2 and would be something we'd have to build out. I edited my last reply to reflect this, but I may not have gotten that bit in before you replied.

Regarding the zeros in the isserKeyHash, I do want to look into that and figure out what the root cause is. It could have something to do with self-signing, but I'm not sure, yet. I'm about to head out and won't be back in the office until next week, but I'll get back to you hopefully sometime next week with an explanation for that.

This fixes the unknown status of self-signed certs.

Thanks!

My use case does require checking the status of all certificates in a chain, so I would very much like this functionality as part of TLS 1.3.  Can you make this happen?

Also, my use case is such that my server may not always have an internet connection.  This means that there may not be an OCSP Response when an OCSP Request is made.  I would, when there is a connection, like to force sending an OCSP Request so that I can get and store an updated OCSP Response well before the currently stored OCSP Status expires.  I do not see how to do that in the current implementation.  How is this possible?

Yes, but I also want the server to force retrieval of an updated response without having a client first request it.  Therefore, when the internet becomes available, the server can generate its own OCSP Request and store the response.

I think the function wolfSSL_CertManagerCheckOCSP *almost* does what you want. The documentation appears to be a bit outdated, though. This results in calls to CheckCertOCSP --> CheckCertOCSP_ex --> CheckOcspRequest, which ultimately sends out the OCSP request to the OCSP responder. However, in CheckOcspRequest, if the status is already cached, no request will be made:

ret = GetOcspStatus(ocsp, ocspRequest, entry, &status, responseBuffer);
if (ret != OCSP_INVALID_STATUS)
    return ret;
...
...
/* code that reaches out to OCSP responder */

So I think we'd need to change this function to accept a new parameter, force, which reaches out to the OCSP responder regardless of whether or not a cached response status for the cert exists.

Any update on the status of this addition?