26 Reply by stroebeljc

(47 replies, posted in wolfSSL)

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.

Go to forum: wolfSSL

27 Reply by stroebeljc

(47 replies, posted in wolfSSL)

The client now produces the error: wolfSSL_connect(-406): Bad Certificate Status Message Error

Also, I am unable to build the server with NO_WOLFSSL_CLIENT defined.

Go to forum: wolfSSL

28 Reply by stroebeljc

(47 replies, posted in wolfSSL)

hayden wrote:

Do you get a compilation error when you try to define it, or are we talking runtime behavior where you don't see the client verify the stapled response?

No compilation errors, just incorrect runtime behavior.

Go to forum: wolfSSL

29 Reply by stroebeljc

(47 replies, posted in wolfSSL)

I have been using version 4.5.0 (full download), but did a git pull of the master branch and am having the problems with master.  On 4.5.0, I call cmake from git bash and am using the ARC_Q_2020_06 cross-compiler (MetaWare by Synopsys).  My cmake call is:

cmake -G"Eclipse CDT4 - Unix Makefiles" -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE -DCMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES=TRUE -DCMAKE_ECLIPSE_VERSION=4.6 -DCONFIG_TARGET_BOARD=EV210_B0 -DCONFIG_TARGET_CORE=CORE_C0 -DCMAKE_BUILD_TYPE=Debug -DBUILD_TESTS=NO  $@ ../source

After that, I modify the options.h to configure things the way I want to.  It is attached to this post.

Go to forum: wolfSSL

30 Reply by stroebeljc

(47 replies, posted in wolfSSL)

hayden wrote:

When you build wolfSSL, it generates a header file wolfssl/options.h. This contains the defines that the library was built with. Are you including that in your client application? That would ensure that everything matches up between your client app and the built wolfSSL library. Based on your description of the latest issues, I think that might help, but let me know if you're already doing that, or if it doesn't fix anything.

I am already using options.h.

Also, since I am basing things off of the 4.5.0 release, the CMakeLists.txt changes have messed me up.  I am currently updating the options.h file directly.  I am a bit confused about the changes to the build process.  Currently, I can't build with the current CMakeLists.txt file because it forces the use of pthread.h, which I don't have in my build.

Go to forum: wolfSSL

31 Reply by stroebeljc

(47 replies, posted in wolfSSL)

Ok, I now have it working.  I am able define NO_RSA, so it does not appear that RSA is required.

However, I also found that I need to undefine NO_SHA and NO_WOLFSSL_SERVER on my client application.  SHA1 is required to verify Issuer Name and Issuer Key hashes. OCSP stapling verification seemed to disappear when I defined NO_WOLFSSL_SERVER.

Is this expected?  Why do I need to include all of the server stuff on my client application?

Go to forum: wolfSSL

32 Reply by stroebeljc

(47 replies, posted in wolfSSL)

I now see the server sending an OCSP Request and getting an OCSP Response.  However, the client does not reject the connection if a revoked certificate response is returned.  Any ideas?  What message is the client expecting to receive and process when the server  sends the stapled response?
Note that I am using ECDSA certificates instead of RSA.  Are ECDSA certificates supported for OCSP Stapling? (NO_RSA is defined in my application.)

Go to forum: wolfSSL

33 Reply by stroebeljc

(47 replies, posted in wolfSSL)

No problem.  I'm also attaching the failed test run that occurs after making this change and running 'make test'.

Go to forum: wolfSSL

34 Reply by stroebeljc

(47 replies, posted in wolfSSL)

and finally...

Go to forum: wolfSSL

35 Reply by stroebeljc

(47 replies, posted in wolfSSL)

2nd file

Go to forum: wolfSSL

36 Reply by stroebeljc

(47 replies, posted in wolfSSL)

When I add the following line after line 2873 in the client.c file I get the error "wolfSSL_connect error -407, Invalid OCSP Status Error":

wolfSSL_CTX_SetOCSP_Cb(ctx, NULL, NULL, NULL);

I have three bash windows open, each running one of the following commands:

openssl ocsp -port 22221 -index certs/ocsp/index-intermediate1-ca-issued-certs.txt -rsigner certs/ocsp/ocsp-responder-cert.pem  -rkey certs/ocsp/ocsp-responder-key.pem -CA certs/ocsp/intermediate1-ca-cert.pem
examples/server/server.exe -c certs/ocsp/server1-cert.pem -k certs/ocsp/server1-key.pem -v 4

(and lastly)

examples/client/client.exe -A certs/ocsp/root-ca-cert.pem -v 4 -W 1

I've attached a couple of pcapng files from Wireshark, one with the above line (failed) and one without.

The upshot is that the above line prevents the client from requesting the response from the OCSP Responder.  I would expect the stapled response to be provided by the server, like happens when I use an openSSL server instead of a wolfSSL server, using the following:

openssl s_server -status -port 11111 -cert certs/ocsp/server1-cert.pem -key certs/ocsp/server1-key.pem -CAfile certs/ocsp/intermediate1-ca-cert.pem

I will provide a pcapng file for this session, also. (I am unable to attach more that one file to this post.)

Go to forum: wolfSSL

37 Reply by stroebeljc

(47 replies, posted in wolfSSL)

hayden wrote:

You'll need an OCSP responder server to act in concert with the wolfSSL server. We have an example of this, if you take a look at scripts/ocsp-stapling.test in the wolfSSL repository. This script sets up an OpenSSL server as an OCSP responder, which a wolfSSL server then contacts to get a certificate status that it then staples and passes along to a wolfSSL client.

I created an OCSP Responder using openssl.  The problem is that I do not see the wolfSSL server application attempting to pull its OCSP Status from the responder.  Since it doesn't do this, it never responds to the stapling request from the client.  Am I configuring the wolfSSL server application incorrectly?  Note, as mentioned previously, I am not using the -o or -O options with the server because they seem to cause it to want to verify the client, when it connects, instead of pulling its own OCSP Response and holding it for a client stapling request.

Go to forum: wolfSSL

38 Reply by stroebeljc

(47 replies, posted in wolfSSL)

hayden wrote:

If I configure wolfSSL 4.5.0 with --enable-ocspstapling2 and build, I'm able to use our example client to make a certificate status request using OCSP stapling:

examples/client/client -h example.com -p 443 -W 2 -A <path to cert>

Since I am using TLS1.3 I can't use OCSP Stapling V2, correct?  I believe I need to use the -W 1 option for the client.

I did get the client to work with an openSSL server that was configured to support the stapling request, so I believe my issue is with the server side of wolfSSL.

The problem is that the example server.c only seems to want to do peer status checks and does not perform a self status check that can be used to formulate an OCSP Response to a client OCSP Status Request.  Am I correct?  Do I need to implement this myself?

Go to forum: wolfSSL

39 Topic by stroebeljc

(47 replies, posted in wolfSSL)

It appears that the out-of-the-box version of wolfSSL (4.5.0) has the client sending an http request to an OCSP Responder, even when OCSP Stapling is enabled.  In my application, I only want OCSP Stapling to get this information from the server it is attempting to contact (actual OCSP Stapling), NOT attempt to contact the OCSP Responder.

Is there an example or information available on how such a client should be configured?  Also, how about the server side of this?  Is there an example of how the server should grab the OCSP Response for itself and make it available during handshaking (TLS 1.3)?

Go to forum: wolfSSL