You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by stroebeljc
The issue has returned for me in version 5.6.4 because the unix version of the command does not include the prior fix.
I am running a cross-compiler in a Git Bash window and get an error with wolfSSL version 5.5.4 during CMake. The problem is with the execute_process command in CMakeLists.txt, which indicates that "user_settings_asm.sh is not a valid Win32 application". This makes sense because of how execute_process works. This looks like newer functionality because this was not a problem with wolfSSL version 5.4.0.
Does anyone have any guidance on how to address this issue?
Also, I had to do some tricks to see the actual error message because the doesn't display the result of the call to execute_process. It would be nice if it provided the results when an error occurs.
Thanks David.
In reviewing your examples I do not see a direct way to set the Basic Constraints extension and to set the SAN to critical. Those are the two issues I still have remaining. I tried using the Custom Extensions example to set the Basic Constraints extension but it broke other things in my code because of --enable-asn=template.
Any update on my questions?
DN means Distinguished Name.
Here is an example:
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Alternative Name: critical
DirName:/CN=10112233445566778899aabbccddeeff, DirName:/CN=20112233445566778899aabbccddeeff
I also need to set the Basic Constraint extension, but am not clear on how to do that. Can you provide guidance on this?
Finally, is there a way to set the Subject Alternative Name to critical?
Thanks for the reference to the example.
Is there an easy way to create a Common Name field that's part of a Distinguished Name that I can then use to generate my SANs? As per the example, it's pretty easy to create the DNS names and IP addresses, but creating a DN inside a Directory Name seems a bit more complicated.
Is there an example of how to create a certificate that has information in the SAN extension that does not require that the data come from another cert? I need to be able to generate the SAN data in real time and add to a cert.
Also, does wolfSSL support the Directory Names SAN extension?
Is there a plan to update the online (and PDF) manual? The current version seems to go back quite a few releases.
Thanks, I used the callback approach, which does the job I need.
When I load a self-signed certificate onto my client, and then attempt to connect to it with a server that is configured with WOLFSSL_VERIFY_PEER passed to wolfSSL_CTX_set_verify(), I always get the error "ASN no signer error to confirm failure".
Is peer verification of a self-signed client not supported?
Awesome, thanks!
It's interesting that the methods wc_AesCcmEncrypt and wc_AesCcmDecrypt use hard coded values rather than the enumerations for the nonce size checking.
Regards,
John
It appears that the maximum nonce size for AES-CCM is 13. Why is this limit in place? Can it be increased to at least 16?
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.
Any update on the status of this addition?
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.
It seems like that would be a nice feature addition.
Thanks, @hayden. That does work.
I found an issue with a missing define in my user_settings.h file that accounted for the compile problems. However, the switch you added provides us with more confidence that the build configuration is as expected.
As for the second part, if I understand correctly, you essentially want a way to extract the OCSP response from wolfSSL so that you can cache it in your application and check that in the event the internet connection isn't available, right?
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.
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.
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?
I still see -DHAVE_CONFIG_H in my compile command line, which is causing build errors. How do I remove it?
This fixes the unknown status of self-signed certs.
Thanks!
Would it be possible to provide an easy way to disable all default settings and only enable the compiler define
-DWOLFSSL_USER_SETTINGS?
This would make it easier to make quick changes to features and settings without having to use a complicated cmake command every time.
Regards,
John
Hayden,
Thanks for the thorough analysis. I think you provided the information I am looking for. If I want to use TLS 1.3, I can't traverse the chain. I can only verify the server cert. With TLS 1.2, I am able to traverse the chain. I agree that this behavior seems to be driven by the standards.
Regarding the all zero issuer key hash, is there a way to address that, or is this baked into x509 self-signing?
Thanks for all of your help!
Wireshark trace without WOLFSSL_OCSP_CHECKALL and forcing OCSP Stapling attached.
Wireshark trace with WOLFSSL_OCSP_CHECKALL and forcing OCSP Stapling attached.
Could you let me know what tests specifically you're referring to? If you could also attach the full log of the failing test(s), that would be helpful, too, as well as any changes I need to make to the source code to trigger the failure you describe.
I'm also curious about your use case for this option. Are you looking to check every certificate in the chain up to and including the peer's, using stapling for each?
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 -oI 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 1I 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.)
@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
wolfSSL - Embedded SSL Library → Posts by stroebeljc
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.016 seconds (94% PHP - 6% DB) with 5 queries