Git Product home page Git Product logo

wolfssljni's Introduction

wolfSSL JSSE Provider and JNI Wrapper

This package provides Java support for the wolfSSL embedded SSL/TLS library, giving applications support for SSL/TLS up to the current TLS 1.3 protocol level. It contains both a wolfSSL JSSE (Java Secure Socket Extension) provider, called wolfJSSE, and a thin JNI-based interface that wraps the native C library.

wolfSSL also provides a JCE (Java Cryptography Extension) provider that wraps native wolfCrypt. This can be found in a separate repository, located here.

Why use wolfJSSE?

This interface gives Java applications access to all the benefits of using wolfSSL, including current SSL/TLS standards up to TLS 1.3, FIPS 140-2 and 140-3 support, performance optimizations, hardware cryptography support, commercial support, and more!

User Manual

The wolfSSL JNI/JSSE Manual is available on the wolfSSL website: wolfSSL JNI Manual.

For additional build instructions and more detailed comments, please reference the manual.

Building

wolfJSSE currently supports compilation on the following platforms:

To build wolfJSSE on Windows using Visual Studio, please reference the Windows README.md.

Building Native wolfSSL (Dependency)

To compile the wolfSSL JNI wrapper and JSSE provider, first the native (C) wolfSSL library must be compiled and installed.

To build wolfJSSE in Linux/Unix environments, first download, compile, and install wolfSSL. wolfSSL can be downloaded from the wolfSSL download page or cloned from GitHub.

$ unzip wolfssl-X.X.X.zip
$ cd wolfssl-X.X.X
$ ./configure --enable-jni
$ make check
$ sudo make install

If building a wolfSSL FIPS or FIPS Ready release bundle, additional configure options may be required. Reference the wolfSSL Manual and build documentation for exact build instructions.

Building with ant

wolfSSL JNI/JSSE's ant build is the most stable and well-tested. Newer support for building with Maven has also been added. See section below for instructions on building with Maven.

Note 1) The java.sh script uses a common location for the Java install location. If your Java install location is different, this could lead to an error when running java.sh. In this case, you should modify java.sh to match your environment.

Build targets for ant are :

  • ant build (ant) (only builds the jar necessary for an app to use)
  • ant test (builds the jar and tests then runs the tests, requires JUNIT setup)
  • ant examples (builds the jar and example cases)
  • ant clean (cleans all Java artifacts)
  • ant cleanjni (cleans native artifacts)

To build wolfJSSE:

$ cd wolfssljni
$ ./java.sh
$ ant
$ export JUNIT_HOME=/path/to/junit/jars
$ ant test

To compile and run the examples, use the ant examples target:

$ ant examples

Then, run the examples from the root directory using the provided wrapper scripts:

$ ./examples/provider/ServerJSSE.sh
$ ./examples/provider/ClientJSSE.sh

Building with Maven

wolfJSSE supports building and packaging with Maven, for those projects that are already set up to use and consume Maven packages.

wolfJSSE's Maven build configuration is defined in the included pom.xml.

First, compile the native JNI shared library (libwolfssljni.so/dylib) same as above. This will create the native JNI shared library under the ./lib directory:

$ ./java.sh

Compile the Java sources, where Maven will place the compiled .class files under the ./target/classes directory:

$ mvn compile

Compile and run JUnit tests using:

$ mvn test

Package up the wolfSSL JNI/JSSE JAR file using the following command. This will run the JUnit tests then create a .jar file located under the ./target directory, similar to target/wolfssl-jsse-X.X.X-SNAPSHOT.jar:

$ mvn package

To build the Javadoc API reference for wolfSSL JNI/JSSE run the following. This will generate Javadoc HTML under the ./docs/apidocs directory:

$ mvn javadoc:javadoc

To install the wolfSSL JNI/JSSE JAR file, run the following. This will install the JAR into the local Maven repository:

$ mvn install

The local Maven repository installation location will be similar to:

~/.m2/repository/com/wolfssl/wolfssl-jsse/X.X.X-SNAPSHOT/wolfssl-jsse-X.X.X-SNAPSHOT.jar

The wolfSSL JNI shared library (libwolfssljni.so/dylib) created with the java.sh script will need to be "installed" by being placed on your native library search path. For example, copied into /usr/local/lib, /usr/lib, or other location. Alternatively, append the ./libs directory to your native library search path by exporting LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (OSX):

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/wolfssljni/lib

After wolfSSL JNI/JSSE has been installed into the local Maven repository, an application can include this as a dependency in the application's pom.xml file, similar to:

<project ...>
    ...
    <dependencies>
        <dependency>
            <groupId>com.wolfssl</groupId>
            <artifactId>wolfssl-jsse</artifactId>
            <version>1.13.0-SNAPSHOT</version>
        </dependency>
    </dependencies>
    ...
</project>

Examples

Examples of using wolfssljni can be found in the ./examples subdirectory. See examples/README.md for more details.

Examples of using the wolfJSSE provider can be found in the ./examples/provider subdirectory. See examples/provider/README.md for more details.

Example certificates and keys are included in this bundle. These should only be used for testing and prototyping. Example certificates included here are duplicates of the ones that ship with standard wolfSSL. If needed, certificates can be easily updated from an existing wolfSSL directory by using the script examples/certs/update-certs.sh. This should be run from the examples/certs directory and given one argument which is the path to a wolfSSL certs directory.

Debugging

wolfSSL JNI/JSSE supports several System properties for enabling debug logging. The table below describes the currently-supported debug properties and what each enables.

System Property Default To Enable Description
wolfssl.debug "false" "true" Enables native wolfSSL debug logging
wolfjsse.debug "false" "true Enables wolfJSSE debug logging
wolfsslengine.debug "false" "true" Enables SSLEngine debug logging
wolfsslengine.io.debug "false" "true" Enables SSLEngine I/O bytes log

Native wolfSSL logging (wolfssl.debug) will only output messages if native wolfSSL has been configured with --enable-debug.

These System properties can be defined at runtime, ie:

java -Dwolfjsse.debug=true App

Or these system properties can also be set programmatically at runtime, ie:

System.setProperty("wolfjsse.debug", "true");
System.setProperty("wolfsslengine.debug", "true);

JDK debug logging can be enabled using the -Djavax.net.debug=all option.

Building for Android

wolfSSL JNI and JSSE can be built and used on the Android platform, either at the application-level or installed inside a modified version of the Android AOSP at the system-level.

Android Application Level Usage

An example Android Studio application is included in this package, to show users how they could include the wolfSSL native and wolfSSL JNI/JSSE sources in an Android Studio application. For more details, see the Android Studio project and README.md located in the ./IDE/Android directory.

Using wolfJSSE at the application level will allow developers to register wolfJSSE as a Security provider at the application scope. The application can use the Java Security API for SSL/TLS operations which will then use the underlying wolfJSSE provider (and subsequently native wolfSSL).

Applications can register the wolfJSSE provider using:

import com.wolfssl.provider.jsse.WolfSSLProvider;
...
Security.addProvider(new WolfSSLProvider());

To instead insert the WolfSSLProvider as the top priority provider, or at a specified index (note: indexing starts at 1):

import com.wolfssl.provider.jsse.WolfSSLProvider;
...
Security.insertProviderAt(new WolfSSLProvider(), 1);

There are also additional Android examples using wolfSSL JNI in the wolfssl-examples repository.

Android AOSP System Level Installation

wolfJSSE can be installed inside an Android AOSP build and registered at the OS/system level. This will allow wolfJSSE to be registered as the highest priority JSSE provider on Android, thus allowing any application using the Java Security API to automatically use wolfJSSE and wolfSSL.

For details on how to install wolfJSSE in Android AOSP, see the README located in the ./platform/android_aosp directory.

Additional instructions can be found on the wolfSSL.com website: Installing a JSSE Provider in Android OSP.

Behavior and Functionality Notes

JSSE Class Implementation Support

wolfJSSE extends or implements the following JSSE classes:

  • javax.net.ssl.SSLContextSpi
    • SSL, TLS, DEFAULT, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3
  • javax.net.ssl.KeyManagerFactorySpi
    • PKIX, X509, SunX509
  • javax.net.ssl.TrustManagerFactorySpi
    • PKIX, X509, SunX509
  • javax.net.ssl.SSLEngine
  • javax.net.ssl.SSLSession / ExtendedSSLSession
  • javax.net.ssl.X509KeyManager / X509ExtendedKeyManager
  • javax.net.ssl.X509TrustManager / X509ExtendedTrustManager
  • javax.net.ssl.SSLServerSocket
  • javax.net.ssl.SSLServerSocketFactory
  • javax.net.ssl.SSLSocket
  • javax.net.ssl.SSLSocketFactory
  • javax.net.ssl.SSLSessionContext
  • java.security.cert.X509Certificate
  • javax.security.cert.X509Certificate

Secure Renegotiation Support

wolfSSL JNI and JSSE provider wrap native wolfSSL APIs to enable and conduct secure renegotiation. For secure renegotiation functionality to be available in wolfSSL JNI, and enabled for use in wolfJSSE, native wolfSSL must be compiled with secure renegotiation support:

$ ./configure --enable-secure-renegotiation

Or by defining -DHAVE_SECURE_RENEGOTIATION.

Release Notes

Release notes can be found in ChangeLog.md.

Support

For support inquiries and feedback please contact [email protected].

wolfssljni's People

Contributors

bandi13 avatar billphipps avatar cconlon avatar dgarske avatar douzzer avatar ejohnstown avatar jacobbarthelmeh avatar julek-wolfssl avatar kaleb-himes avatar kojo1 avatar lchristina26 avatar lealem47 avatar miyazakh avatar philljj avatar shaneisrael avatar toddouska avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wolfssljni's Issues

In Java 17, look for the "delegate" in setFd() in com_wolfssl_WolfSSLSession.c

When testing wolfssljni with Corretto JDK 17, I see that the impl-object we get in Java_com_wolfssl_WolfSSLSession_setFd() has a delegate-object that has the "real" data. It looks like we need to use that as the object to fetch the fd object from.

One way of doing this is simply to move the impl-pointer to the delegate object, if the delegate-object can be found.

no getApplicationProtocol() method in WolfSSLEngine

Hi, I am trying to use wolfssljni with our undertow server with HTTP2 on TLSv1.2 on my MAC (dev env) Java 11.
I am getting the below exception:

2021-12-23 22:44:51.043 [ERROR] [XNIO-1 I/O-2] io.undertow.server.protocol.http.AlpnOpenListener$AlpnConnectionListener:handleEvent(407): UT005090: Unexpected failure
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
	at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:124) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
	at io.undertow.server.protocol.http.AlpnOpenListener$AlpnConnectionListener.handleEvent(AlpnOpenListener.java:365) [undertow-core-2.2.14.Final.jar:2.2.14.Final]
	at io.undertow.server.protocol.http.AlpnOpenListener.handleEvent(AlpnOpenListener.java:313) [undertow-core-2.2.14.Final.jar:2.2.14.Final]
	at io.undertow.server.protocol.http.AlpnOpenListener.handleEvent(AlpnOpenListener.java:67) [undertow-core-2.2.14.Final.jar:2.2.14.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
	at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
	at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178) [xnio-nio-3.8.4.Final.jar:3.8.4.Final]
	at org.xnio.nio.QueuedNioTcpServer2$$Lambda$131/0x0000000000000000.run(Unknown Source) [xnio-nio-3.8.4.Final.jar:3.8.4.Final]
	at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) [xnio-nio-3.8.4.Final.jar:3.8.4.Final]
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:479) [xnio-nio-3.8.4.Final.jar:3.8.4.Final]
Caused by: java.lang.reflect.InvocationTargetException
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:122) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
	... 13 more
Caused by: java.lang.UnsupportedOperationException
	at javax.net.ssl.SSLEngine.getApplicationProtocol(SSLEngine.java:1328) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:122) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
	... 13 more

While I debugged the code, the ALPN listener of undertow is calling getApplicationProtocol() method of SSLEngine which in this case is WolfSSLEngine and it doesn't implement it. I tried to implement the method with return values as null but the h2 upgrade is not working properly.

@Override
    public String getApplicationProtocol() {
        return null;
    }

I found a similar Implementation here: https://github.com/wildfly-security/wildfly-openssl/blob/master/java/src/main/java/org/wildfly/openssl/OpenSSLEngine.java#L1566 but couldn't port it in WolfSSLEngine properly.
I would appreciate it if someone here can help me.
Before implementing getApplicationProtocol()

curl -vk https://localhost:8081/?exchange=test  --data 'msg'
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8081 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:8081
* Closing connection 0
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:8081

After

curl -vk https://localhost:8081/?exchange=test --data 'msg'
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8081 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: OU=Domain Control Validated; CN=*.server.test.io
*  start date: Jun  1 03:49:53 2021 GMT
*  expire date: Jul  3 03:49:53 2022 GMT
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.
> POST /?exchange=mopub HTTP/1.1
> Host:bids-ams.server.test.io
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Length: 1535
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server
* Closing connection 0

WolfSSLSessionTest junit failure with wolfSSL --enable-all

wolfSSL JNI encounters two junit test failures in WolfSSLSessionTest.java when linking against a native wolfSSL library compiled with "./configure --enable-all". Steps to reproduce:

$ cd wolfssl
$ ./configure --enable-all
$ make check
$ sudo make install
$ cd wolfssljni
$ ./java.sh
$ ant
$ ant test

Error log shows the following:

Testcase: testBinding took 0.165 sec
	Caused an ERROR
null
java.lang.NullPointerException
	at com.wolfssl.provider.jsse.test.WolfSSLSessionTest$listner.checkID(WolfSSLSessionTest.java:425)
	at com.wolfssl.provider.jsse.test.WolfSSLSessionTest.testBinding(WolfSSLSessionTest.java:255)

Testcase: testSessionTimeAndCerts took 0.163 sec
Testcase: testSessionContext took 0.163 sec
	Caused an ERROR
null
java.lang.IllegalArgumentException
	at com.wolfssl.provider.jsse.WolfSSLImplementSSLSession$WolfSSLSessionContext.setSessionTimeout(WolfSSLImplementSSLSession.java:369)
	at com.wolfssl.provider.jsse.test.WolfSSLSessionTest.testSessionContext(WolfSSLSessionTest.java:385)

better way to find java on mac

why don't we use /usr/libexec/java_home to fetch the java install dir?

moisesguimaraes@phyrexia: ~$ /usr/libexec/java_home -h
Usage: java_home [options...]
    Returns the path to a Java home directory from the current user's settings.

Options:
    [-v/--version   <version>]       Filter Java versions in the "JVMVersion" form 1.X(+ or *).
    [-a/--arch      <architecture>]  Filter JVMs matching architecture (i386, x86_64, etc).
    [-d/--datamodel <datamodel>]     Filter JVMs capable of -d32 or -d64
    [-t/--task      <task>]          Use the JVM list for a specific task (Applets, WebStart, BundledApp, JNI, or CommandLine)
    [-F/--failfast]                  Fail when filters return no JVMs, do not continue with default.
    [   --exec      <command> ...]   Execute the $JAVA_HOME/bin/<command> with the remaining arguments.
    [-R/--request]                   Request installation of a Java Runtime if not installed.
    [-X/--xml]                       Print full JVM list and additional data as XML plist.
    [-V/--verbose]                   Print full JVM list with architectures.
    [-h/--help]                      This usage information.

moisesguimaraes@phyrexia: ~$ /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home

this change on java.sh worked for me:

javaHome=`/usr/libexec/java_home`
javaIncludes="-I$javaHome/include -I$javaHome/include/darwin"

Add support for Java 9+ cacerts location

In WolfSSLTrustManager.java we look for cacerts in a couple of known locations.
It's currently missing the default Java9+ location:
${JAVA_HOME}/lib/security/cacerts

JAVA Application + WolfSSL (Library Loading) java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "wolfSSL_memsave_session_cache"

Hi folks,

We are integrating wolfJNI with wolfSSL(FIPS enabled).

Working case:
https://github.com/wolfSSL/wolfssl-examples/tree/master/android

Using above link .SO were generated and able to load as below and invoke wolfssl via wolfssljni.

System.loadLibrary("wolfssl");
System.loadLibrary("wolfssljni");
System.loadLibrary("jnitest");

Not working Case:

System.loadLibrary("wolfssl");// Was generated using FIPS mode separately using v3.6.0.

On loading below lib, we see below error.

System.loadLibrary("wolfssljni");

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "wolfSSL_memsave_session_cache" referenced by "libwolfssljni.so"...
                                                 at java.lang.Runtime.loadLibrary(Runtime.java:372)
                                                 at java.lang.System.loadLibrary(System.java:988)

System.loadLibrary("jnitest");

https://github.com/wolfSSL/wolfssl/blob/190d30f336c0ff32aecbf198bd0603b42dcac46a/cyassl/ssl.h

https://github.com/search?q=org%3AwolfSSL+wolfSSL_memsave_session_cache&type=Code

https://github.com/wolfSSL/wolfssljni/blob/ced9f742286c2847d3d0e72c4fb925903575a15d/native/com_wolfssl_WolfSSL.c

How do we link this API with our FIPS enabled wolfSSL v3.6.0?

Pls share your thoughts..

Thanks
Nithin

Add module Support for Java 9+

I'm working on getting a Java 17 FIPS test environment working with WolfSSL as the JSSE and JCA.
One of the build steps is to get a FIPS JDK compiled with the JSSE and JCA modules.
If I put the JNI and JSSE jars in the /fips and run

jlink --no-header-files --no-man-pages \
    --compress=2 \
    --module-path /fips/ \
    --add-modules ${mods},wolfcrypt.jni,wolfssl.jsse \
    --output /usr/java/fips --ignore-signing-information

I get errors that indicate that the module-info class is missing. I can patch the jar-files with:

jdeps --ignore-missing-deps --generate-module-info patch /fips/wolfcrypt-jni.jar \
  && javac --patch-module wolfcrypt.jni=/fips/wolfcrypt-jni.jar patch/wolfcrypt.jni/module-info.java \
  && jar uf /fips/wolfcrypt-jni.jar -C patch/wolfcrypt.jni module-info.class

But when I do this and retry with the previous command, I get a conflict in the exported packages.

What I think needs to be done is:

  1. In wolfssljni, move the classes in com.wolfssl.wolfcrypt to com.wolfssl.wolfcrypt.jsse or somewhere non-conflicting
  2. Add a module-info.java to each jar, to ease the integration in java 9+

Unable to Build JNI shared library

Hi,

I am trying to build the jni interface but encountered some issues locally, wondering if anyone could help me take a look? Bascially I am able to build and instance the wolfssl library but when I tried to execute ./java.sh it failed to complete and some of the compilation errors are as following:

./native/com_wolfssl_WolfSSL.c:1417:14: error: ‘SSL_CIPHER’ undeclared (first use in this function); did you mean ‘WOLFSSL_CIPHER’?
 1417 |     STACK_OF(SSL_CIPHER) *supportedCiphers = NULL;

The include paths is following -I/usr/lib/jvm/java-21-zulu-openjdk-ca/include -I/usr/lib/jvm/java-21-zulu-openjdk-ca/include/linux -I/usr/local/include and I confirmed the wolfssl headers and libraryies are there.

Much thanks for the help and kindly let me know if anything other information should be provided.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.