Hi,

Indeed, the BC server was sending a bad ca certificate to the wolfssl jni client, and that was causing the no signer error (the error is mine made during a previous test).

Now, with the server sending the correct cert, I ran into a different issue.  During the handshake, in response to the initial  "client_hello", the server sends "server_hello," "certificate", "server_key_exchange," "certificate_request", and "server_hello_done."  Then the server receives from the client another "client_hello" message, at which point the server quits the handshake.

Is this a correct client behavior?  It seems the BC server is implementing a different handshake protocol than the client...

Thanks again,
--Hyong

Hi,

Kaleb J. Himes wrote:

Hi hyongsop,

The attachment did not make it through, could you re-send or copy into a "code" block here?

A key length of 2432 is a non-standard key length. Typically RSA keys are evenly divisible by 1024 (1024, 2048, 3072, 4096... etc). I would be curious to see it regardless.

I added the content of the x509-ca.pem file at the end.

Kaleb J. Himes wrote:

Have you tested against the BC server using the client example that ships with wolfSSL?

This is the scenario that I've been trying to get it going without success.

I've just tried the wolfssl client with the wolfssl server using the BC's certs, and they worked (after disabling the CRL check in the Server first).  Below show how I ran the server and client:

./examples/server.sh -u -v 2 -c ../certs/bc/x509-server.pem -k ../certs/bc/x509-server-key.pem -A ../certs/bc/x509-ca.pem
./examples/client.sh -u -v 2 -c ../certs/bc/x509-client.pem -k ../certs/bc/x509-client-key.pem -A ../certs/bc/x509-ca.pem

So I doubt that the problem is with the certs themselves.  Since the client didn't generate the no signer error either in the above, the only other source of the problem is the cert sent by the BC server, but so far, I don't see how that can be...

Any other suggestions?  Is there a way to see the log messages generated by the Client and Server?

Thanks again,
--Hyong

cat examples/certs/bc/x509-ca.pem

-----BEGIN CERTIFICATE-----
MIIDZzCCAh+gAwIBAgIEUqKcyzANBgkqhkiG9w0BAQsFADAjMSEwHwYDVQQDExhC
b3VuY3lDYXN0bGUgVExTIFRlc3QgQ0EwHhcNMTMxMjA3MDM1ODAzWhcNMzMxMjAy
MDM1ODAzWjAjMSEwHwYDVQQDExhCb3VuY3lDYXN0bGUgVExTIFRlc3QgQ0EwggFS
MA0GCSqGSIb3DQEBAQUAA4IBPwAwggE6AoIBMQDMhzecH5G7Hux5I8B4ftDYKQfB
EpGBlFB2Yvbn3JIbtEpnY3utJokWGdbTY5oXn8amSRZFP9ZJlBDPrAyop//UfuJ0
A1n2wDiFHUcPMc1Dg67uH44fGib59tnOV4a0w4xF18FVgPH++2Vy/ZY/VjSAIfMd
U3nznh1p744dsEjTqj4euJjcy9CCvpW7A0i0ZuXztkkNZvcVnskCrvuHKshAZoPo
dtIW1G66evZQCGQIJHLyASAifQFe1c8VlJ8U4Z5zQeJe26DjMRF5IrYJWl43IFYr
DfFC4x+9EnVKdE2g95D9mTkWAwX8/y5eWzPBj7uauLdc36CPfJcn6Q0shGxMbn+O
j2/mrF8cq9hXBe0cuRLH8F7k6wGxzVzx4wizMysCKJoXYVnEw9AP3uSZqXNDAgMB
AAGjQzBBMA8GA1UdEwEB/wQFMAMBAf8wDwYDVR0PAQH/BAUDAwcEADAdBgNVHQ4E
FgQU9mOvr6Pi7+4O5bKxRihqeCkyHukwDQYJKoZIhvcNAQELBQADggExAKyMiFmj
YxzjXpQBD5dvRI7xZn79vH3lo13XRBXj/sbPXDXWIv21iLfutXn/RGGsq8piPXHG
5UY3cpZR6gOq6QO1dJ91K0ViAJBFQdkhhtfbhqGY4jvj0vGO6zenG/WrjH26nCT7
8S4L6ZoF6Y0EfQXluP50vEitTaZ6x/rung9h2JQ8rYKiRRVCA+tgBWK/CNhQ9LXy
k3GU0mKLik0AkEFS17C0NWePIPEs/Kxv9iTEFacAN9wVHjZcMYnYtWaPNX0LWV8s
2V2DMJxrmgCEcoXgJxlyEmvyqwpjB+2AiIQVIuWcwPqgBQoKHThT2zJcXV+bMhMs
6cGvaIdvPxttduQsP349GcmUIlV6zFJq+HcMjfa8hZNIkuGBpUzdRQnu1+vYTkwz
eVOPEIBZLzg9e2k=
-----END CERTIFICATE-----

Hi,

Thanks for the response.

In the attached is 'x509-ca.pem.'  I did verify that the ca's cert is self signed (both the issuer and subject are "CN=BouncyCastle TLS Test CA") and that the server's cert, x509-server.pem, has the "CN=BouncyCastle TLS Test CA" as its issuer. 

As per your suggestion, I tried the client with "-A ../certs/bc/x509-server.pem".  I also combined the ca and server certs into a single pem file and used that for the '-A' argument.  Both produced the same no signer error...

I also checked that the wolfssl's ca cert is also self-signed.  The main difference between the wolfssl's ca cert and BC's ca cert seems to be the key length (wolfssl = 2048 bits, BC = 2432 bits).  Would it make a difference?  I don't think so; when I tried the same test with the wolfssl's certs, I was getting the same error.

Thanks again for your support.
--Hyong

Hi,

I commented out the lines in Client.java to disable the CRL check.  Now I'm back to getting the same error (err = -188):

=== begin ===
./examples/client.sh -u -v 2 -c ../certs/bc/x509-client.pem -k ../certs/bc/x509-client-key.pem -A ../certs/bc/x509-ca.pem -h windows_ip_addr -p 5556
Registered I/O callbacks
Hello from Java verify callback!
peer cert verification failed
wolfSSL_connect failed. err = -188, ASN no signer error to confirm failure
=== end ===

So the situation is that the "ASN no signer to confirm failure" error occurs with both the BC certs and wolfssl certs when the wolfssl jni client tries to establish the DTLS connection with the BC server.  Obviously, the DTLS handshake doesn't even start. 

Thanks again and look forward to getting your input on this.
--Hyong

Hi,

Thanks for the response.

Actually, I copied the wolfssl example certificates to the Windows and modified the BC client to use them (without the "-d" option) successfully to establish connection with the wolfssl jni server and exchange data with it. 

The above problem occurred when I tried to use the BC server (modified to use the wolfssl certs) with the wolfssl jni client.

I just copied the BC's example certs over to where the wolfssl jni is installed and tried to run the wolfssl jni client with the BC server (using the BC certs).  This time, I get a different error (err = -362, CRL misssing):

=== begin ===
~/wolfssl/wolfssljni$ ./examples/client.sh -u -v 2 -c ../certs/bc/x509-client.pem -k ../certs/bc/x509-client-key.pem -A ../certs/bc/x509-ca.pem -h windows_ip_addr -p 5556
Registered I/O callbacks
Entered MyMissingCRLCallback, url =
Hello from Java verify callback!
peer cert verification failed
wolfSSL_connect failed. err = -362, CRL missing, not loaded
=== end ===

Thanks again for your response and look forward to any thoughts you have on this.

--Hyong

Hi,

I'm getting the above error when running the example client in the JNI package to connect to a DTLS server (by BouncyCastle).  Specifically:
- wolfssl configured with "--enable-jni" and "--enable-dtls" and built on a linux platform (all the tests pass)
- the example certificates in the wolfssljni pakcage used by both the wolfssl client and BC server (on the Windows platform)
- "server-cert.pem', "server-key.pem" and "ca-cert.pem" are used as server credentials
- the client is run with "-u -v 2"

FYI, the wolfssl jni server works with the BC client using the same set of the example certificates in the wolfssl jni package. 

Any help would be greatly appreciated.

Thanks,
--Hyong

Hi,

I've run into a number of issues trying to build the JNI package on Windows 7.  The wolfssl source I've cloned is the latest version (3.10.0). 

First, I tried the cygwin route:
$ ./confgure --enable-jni
$ make

The 'make' generates the following error messages:
...
src/crl.c:48:9: error: #error "CRL monitor only currently supported on linux or mach"
        #error "CRL monitor only currently supported on linux or mach"
         ^
src/crl.c: In function ‘FreeCRL’:
src/crl.c:143:13: error: implicit declaration of function ‘StopMonitor’ [-Werror=implicit-function-declaration]
         if (StopMonitor(crl->mfd) == 0)
             ^
src/crl.c:143:9: error: nested extern declaration of ‘StopMonitor’ [-Werror=nested-externs]
         if (StopMonitor(crl->mfd) == 0)
         ^
src/crl.c: In function ‘StartMonitorCRL’:
src/crl.c:743:41: error: ‘DoMonitor’ undeclared (first use in this function)
     if (pthread_create(&crl->tid, NULL, DoMonitor, crl) != 0) {
                                         ^
src/crl.c:743:41: note: each undeclared identifier is reported only once for each function it appears in
src/crl.c: At top level:
src/crl.c:339:12: error: ‘SignalSetup’ defined but not used [-Werror=unused-function]
static int SignalSetup(WOLFSSL_CRL* crl, int status)
            ^
src/crl.c:362:12: error: ‘SwapLists’ defined but not used [-Werror=unused-function]
static int SwapLists(WOLFSSL_CRL* crl)
            ^
cc1: all warnings being treated as errors
make[1]: *** [Makefile:3253: src/src_libwolfssl_la-crl.lo] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/hshim/wolfssl/wolfssl'
make: *** [Makefile:1985: all] Error 2
...

Fyi, without '--enable-jni' to 'configure,' the source builds and all the tests pass. 

Next, I used the Visual Studio Express 2013 to build the wolfssl dll (Configuration: Release, Platform: Win32).  Then in wolfssl-jni-1.3.0, I modified 'java.sh' for my cygwin environment:

----- start: modified java.sh -----
javaHome=`echo $JAVA_HOME`
javaIncludes="-I$javaHome/include -I$javaHome/include/win32"
javaLibs="-shared"
jniLibName="libwolfSSL.so"
cflags="-DHAVE_ECC -DUSE_FAST_MATH"

# create /lib directory if doesn't exist
if [ ! -d ./lib ]
then
    mkdir ./lib
fi

gcc -DWOLFSSL_DTLS -Wall -c $fpic $cflags ./native/com_wolfssl_WolfSSL.c -o ./native/com_wolfssl_WolfSSL.o $javaIncludes
gcc -DWOLFSSL_DTLS -Wall -c $fpic $cflags ./native/com_wolfssl_WolfSSLSession.c -o ./native/com_wolfssl_WolfSSLSession.o $javaIncludes
gcc -DWOLFSSL_DTLS -Wall -c $fpic $cflags ./native/com_wolfssl_WolfSSLContext.c -o ./native/com_wolfssl_WolfSSLContext.o $javaIncludes
gcc -DWOLFSSL_DTLS -Wall -c $fpic $cflags ./native/com_wolfssl_wolfcrypt_RSA.c -o ./native/com_wolfssl_wolfcrypt_RSA.o $javaIncludes
gcc -DWOLFSSL_DTLS -Wall -c $fpic $cflags ./native/com_wolfssl_wolfcrypt_ECC.c -o ./native/com_wolfssl_wolfcrypt_ECC.o $javaIncludes
gcc -Wall $javaLibs $cflags -o ./lib/$jniLibName ./native/com_wolfssl_WolfSSL.o ./native/com_wolfssl_WolfSSLSession.o ./native/com_wolfssl_WolfSSLContext.o ./native/com_wolfssl_wolfcrypt_RSA.o ./native/com_wolfssl_wolfcrypt_ECC.o -L path_to_folder_with_wolfssl.dll -lwolfssl

----- end: modified java.sh -----

However, the modified script fails; it generates a number of undefined references when linking to the wolfssl dll:
....
./native/com_wolfssl_WolfSSL.o:com_wolfssl_WolfSSL.c:(.text+0x32): undefined reference to `wolfSSL_Init'
./native/com_wolfssl_WolfSSL.o:com_wolfssl_WolfSSL.c:(.text+0x32): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `wolfSSL_Init'
./native/com_wolfssl_WolfSSL.o:com_wolfssl_WolfSSL.c:(.text+0xa7): undefined reference to `wolfTLSv1_server_method'
./native/com_wolfssl_WolfSSL.o:com_wolfssl_WolfSSL.c:(.text+0xa7): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `wolfTLSv1_server_method'
./native/com_wolfssl_WolfSSL.o:com_wolfssl_WolfSSL.c:(.text+0xc2): undefined reference to `wolfTLSv1_client_method'
./native/com_wolfssl_WolfSSL.o:com_wolfssl_WolfSSL.c:(.text+0xc2): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `wolfTLSv1_client_method'
./native/com_wolfssl_WolfSSL.o:com_wolfssl_WolfSSL.c:(.text+0xdd): undefined reference to `wolfTLSv1_1_server_method'
....

Any help in resolving this issue be greatly appreciated.

Thanks,
--Hyong