1 Reply by elsevers

(36 replies, posted in wolfSSL)

Hello,

I just want to let you know that I also struggled with this issue and the fix described here worked for me. I am compiling for an ARM using Keil MDK.

Go to forum: wolfSSL

2 Reply by elsevers

(2 replies, posted in wolfSSL)

Thank you!

Go to forum: wolfSSL

3 Topic by elsevers

(2 replies, posted in wolfSSL)

I have noticed that wolfSSL only performs OCSP checks on the leaf certificate, and not the entire chain. However, to really evaluate trust, doesn't the entire chain need to be checked? Are there plans to implement this?

My understanding of OCSP is that an OCSP responder will only vouch for the status of an individual certificate, regardless of the revocation status of each certificate in the signing chain. For example, suppose I am connecting to a server which has a certificate that has not been revoked but the certificate of the intermediate CA which signed the server's certificate has been revoked, if I ask an OCSP responder about the server's certificate, the responder may indicate that the server's certificate is valid when in fact that certificate should no longer be trusted because its signer was revoked. Or worse yet, if the signer's private key was stolen, the server's certificate could have been issued from the stolen private key with the OSCP responder information pointing to an OSCP responder run by the thief.

So it seems necessary to perform an OCSP check on the entire chain? The logic for how best to implement this is a bit hazy to me, since providing OSCP services is not mandatory and it is conceivable that  it may not exist for some certificates in the chain.

Thanks

Go to forum: wolfSSL

4 Reply by elsevers

(5 replies, posted in wolfSSL)

Hi Todd,

Have you decided about adding this less constrained certificate chain verification policy to a future release of CyaSSL?

I took a quick peak at version 1.9 and it did not look like it had been added -- but maybe I am wrong?

Thanks

Go to forum: wolfSSL

5 Topic by elsevers

(1 replies, posted in wolfSSL)

Hi,

Any chance you could allow users to subscribe to an entire topic forum for email alerts (as Sourceforge allowed). ie I would like to have the option to receive an email whenever someone posts to your wolfSSL forum.

Thanks.

Go to forum: wolfSSL

6 Reply by elsevers

(2 replies, posted in wolfSSL)

Okay, thanks.

After hearing what you have to say here, I agree that adding unsigned certificate generation is probably not worth the effort and code space required -- especially if it isn't even x.509 standard.

-Eric

Go to forum: wolfSSL

7 Topic by elsevers

(2 replies, posted in wolfSSL)

This is in response to a thread started on the old wolfSSL forums -- now moved here:

What system are you on?

Do you think we should add a bug report category to the new forums?  Go ahead and post to whichever one you like though we'd prefer the new forums I guess just to show it's being used smile

The next release will allow CA signed cert generation but there won't be an intermediate output where certs can be sent to other signers (just wolfSSL CA signing).  Do you think another tool that provides intermediate certs would be useful?  Is there anything wrong with the tools people are currently using or things you'd like to see improved?


My application:
I am experimenting with using wolfSSL to encrypt data traffic between two ARM microcontrollers (over TCP/IP as well as RS232, USB, etc) -- so one MCU acts as the server and the other as the client (both using certificates). As my system is memory constrained, I keep my bio transmit buffers small (since SSL already has sufficient buffer space for TX messages).

Actually, this brings up a question: is there anything wrong with leaving a single SSL session running for days, weeks, or months on end without closing it and reopening?  (Should the encryption keys be refreshed every so often?)

Signing Certs:
If I am understanding you right, it sounds like the only option for a wolfSSL client to use a signed certificate will be for another device (running a CA or wolfSSL) to generate the public/private certificate pair, sign the public certificate, and then transmit the certificate pair to the wolfSSL client.

In the context of embedded devices, I think it would be nice to have the ability to have your embedded device generate its own public and private certificate pair and then present only its public key to a CA for signing (thereby eliminating the possibility of the private key being exposed).

I have been experimenting with OpenSSL's command line interface for certificate signing -- I guess that I am not overly impressed with the way they keep their database (in a text file, with a second text file keeping track of the current index number) -- but I don't have any real suggestions for how to improve this either...

Forums:
For now it seems nice to keep your new forum structure (bugs and questions in one section) as it is easy to see what other wolfSSL are up to. If the # of posts start to get over whelming it might be a good idea to separate bugs from questions.

Go to forum: wolfSSL