Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Like these properties:

-Djavax.net.ssl.keyStore=keystore_path
-Djavax.net.ssl.keyStorePassword=password
-Djavax.net.ssl.trustStore=truststore_path
-Djavax.net.ssl.trustStorePassword=trustword
                What if you actually want to use OpenSSL though, for none of the above reasons.... is there a way to do it?
– Erik Aronesty
                Jul 25, 2018 at 17:07
Everyone talks about BouncyCastle, but in our use case Gnu Crypto library won the day. Native java.
Our database ( aerospike ) spends at least 10% of its time computing hashes in java, for some customers, simply because these implementations are slow. I welcome when there's a native implementation of the crypto libraries available on every Linux machine. I thought some of the Java7 VMs were going to include more algorithms, but I haven't seen them yet.
https://github.com/apache/tomcat-native

It uses OpenSSL for TLS/SSL capabilities. You can use it as standalone library (as I did) or connect your Tomcat. It is open source project with well documented Java code. 
Why tomcat native?
JSSE is slow and hard to use.
In my project to get best performance we've decided to find/write JNI wrapper for OpenSSL as possibility for upgrading certificates on-the-fly is a question mark and Key Stores are too complex. 
As Bouncy Castle Crypto APIs is written in Java you cannot expect best efficiency.
Tomcat Native is a wrapper so you are limited only to capabilities of your OpenSSL version.
                I'd like to use OpenSSL to build a PKI in my java project , would it be advisable to build a PKI using tomcat native ?
– kimathie
                Dec 20, 2020 at 14:25
Best solution: Use Java's built-in security for simple tasks or use BouncyCastle for more advanced ones.
If you HAVE TO use OpenSSL from Java you have 2 choices: 
Call openssl as a process from Java.
Make a JNI layer to OpenSSL, but that seems like a complete waste of time to me.
None of those are really good ways of doing it.
                Another thing to consider if you need to use it with an HSM and it only supports OpenSSL Engine. But nowadays most HSM comes with JAR files for adapting to JCE/JCA
– Miyagi
                May 4, 2018 at 7:38
There are lots of Java native libraries for crypto.   However they are generally not fully interoperable with OpenSSL, are sometimes significantly slower (see the metrics on the site below), and aren't supported on all platforms.  OpenSSL is definitely supported on nearly every platform and is, generally, performant.
That being said, there are some security advantages to using VM-based crypto.  This should also be a consideration.
The Apache group has built a library for Java that uses JNI to access openssl for AES encryption.  I think it's the best public example of using JNI to access openssl, and you can reference it easily using maven.
https://github.com/apache/commons-crypto
If you want, you can pull out the JNI binding portion of the libary and implement the functions you need.  
This makefile shows how to use javah to get what you need from the .class to build the .c code:
https://github.com/apache/commons-crypto/blob/master/Makefile
Specifically, this line in the Makefile calls javah:  $(JAVAH) -force -classpath $(TARGET)/classes -o $@ org.apache.commons.crypto.cipher.OpenSslNative to produce the correct "OpenSslNative.h" file based on the OpenSslNative.class.
https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/cipher/OpenSslNative.java
Note how import java.nio.ByteBuffer; is used to allow for C output buffers.
The associated .c program is here:
https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c
It's written with cross-platform support in mind, and is a good example.   Every exported function must begin with JNIEXPORT, and you can see how the full class path is in each function name.
I've seen a lot of bad JNI bindings, passing strings around, etc.  Starting with a solid base goes a long way toward building good OpenSSL integration in Java.
You need to answer a few important questions before any suggestions
1) Do you really want to call C(native) implementation form JAVA?
2) What are the features in OpenSSL which cannot be solved by JCE and BouncyCastle
3) Is the scope just limited to using certificates generated by OpenSSL, decrypting files generated by OpenSSL? 
                Answer to Q2: BC does not support HELLO for DTLS (so you will lose the first message in any communcation
– osundblad
                Nov 21, 2017 at 13:55
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.