Now available in UniVerse 11.3.2. Find out more!



OpenSSL released their latest LTS (Long Term Support) version 1.1.1 on Sep 11, 2018. This major release includes various new features that we are going to use in our upcoming Rocket® UniVerse and Rocket® UniData® releases. Among the many new features, the predominant new feature is TLS v1.3. This new version of the Transport Layer Security (formerly known as SSL) protocol was published by the IETF in August 2018 as RFC8446, which brings faster speeds and improved security compared with TLS 1.2. The first Rocket release that will be equipped with OpenSSL 1.1.1 will be Universe 11.3.2 and later in UniData 8.2.2. Early adopters can expect the following benefits from these two releases:

  • A newer version of OpenSSL library (1.1.1b).
  • Strengthened SSL protocol version support.
  • Support for various new cryptographic algorithms.
  • Ability to upgrade OpenSSL on their own to a minor version in the future.
  • Methods of building OpenSSL on different platforms.

In this article, we will walk through these OpenSSL related enhancements.

A newer version of OpenSSL library (1.1.1b)

Upgrading to OpenSSL v1.1.1b, the latest LTS release, is highly recommended for all users. The previous LTS release (OpenSSL 1.0.2) will continue to receive full support until the end of 2019. It is worth noting that the new version of OpenSSL v1.1.1b does not have a compatible FIPS module.

For more detailed information, please refer to updates from official OpenSSL website below:

OpenSSL 1.1.1 was a huge endeavor with nearly 5000 committed changes to the OpenSSL source code that they posted in GitHub. For our upcoming releases, we changed much of the underlying code (deprecated or replaced) and some internal logic to align with the latest OpenSSL version. The BASIC extensions security APIs will keep their original behavior or include additional support for some new features. We will build and distribute the new OpenSSL library in UniVerse 11.3.2 and UniData 8.2.2.

New version of the Transport Layer Security protocol TLS v1.3.

TLS v1.3 was finalized as RFC8446, it has numerous improvements over its predecessors, including a new handshake and revamped cipher suites. Some of the benefits of TLS v1.3 include:

  1. Reduces number of round trips required between the client and server in the TLS 1.3 handshake versus TLS 1.2.
  2. Offers 1-RTT mode and Zero Round Trip Resumption. This feature allows for near-instantaneous session resumption for visitors who have recently visited your site.
  3. In certain cases, clients can start sending encrypted data to the server immediately without going back and forth with the server.
  4. Enhances security by eliminating various outdated and insecure cryptographic algorithms and encrypting more connection handshakes.

For Universe 11.3.2, TLS v1.3 can be enabled by changing parameter SSL_PROTOCOLS in the uvconfig file.  We also recommend using the strongest protocol supported by both client and server. However, some of our client tools do not include the latest version to support OpenSSL 1.1.1, such as wIntegrate and U2ODBC, so the maximum version used by default is still TLS v1.2. We will be adding support for TLSv1.3 to our tools and clients in future releases.

For example, if you are using the BASIC CallHTTP to verify the new protocol TLS1.3, you need to manually add the TLS v1.3 version to the uvconfig file.

Here’s how to do that: Connect to a Web site ( using the TLS v1.3 protocol.

Confirm/check the OpenSSL information by enabling protocolLogging.

It is worth emphasizing that, we negotiate the highest protocol available within the allowed range to both SSL client and SSL server, which may not be TLSv1.3 in many cases at this point.

Simplified Cipher Suites

In TLS v1.3, cipher suites no longer include the key exchange and signature algorithms.

With TLS v1.3, the cipher suites only include the bulk cipher and the hashing algorithm. Here are the recommended cipher suites for TLS v1.3:

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_CCM_8_SHA256

To see a full list of the available ciphers, open a command prompt and navigate to the UniData or UniVerse bin directory. Enter the following command:

> openssl ciphers -v

You can use the BASIC security API setCipherSuite/getCipherSuite to manage a cipher suite for TLS v1.3. For example:

Support for various new cryptographic algorithms.

UniVerse supports a variety of new cryptographic algorithms, such as SHA3, SHA512/224 and SHA512/256 and so forth. SHA-3 (Secure Hash Algorithm 3) is the newest member of the Secure Hash Algorithm family of standards. SHA-3 is internally different from the MD5-like structure of SHA-1 and SHA-2. SHA3 includes: SHA3-224, SHA3-256, SHA3-384, SHA3-512. We can use these new algorithms to perform certain operations, such as creating a certificate or generating a message digest by using BASIC security APIs.

Customer can upgrade OpenSSL on their own to a minor version in the future.

Starting at Universe 11.3.2 (and later at UniData 8.2.2), upgrading OpenSSL is more flexible and easier than before. To upgrade to a newer minor version of OpenSSL, for instance, from OpenSSL 1.1.1b to OpenSSL 1.1.1c, we give you several options to upgrade OpenSSL on your own, without needing to change data server code. Specifically:

  1. Option1: Set an environment variable($USE_SSL_PATH) to specify the path.

>setenv USE_SSL_PATH /home/cjiang/custpath_env

  1. Option2: Set the path into a fixed file under $UVHOME.

> cd $UVHOME

  1. Option3: Default settings

If both option1 and option2 are set at the same time, option1 will be used and option2 will be ignored, and if both of option1 and option2 are not set, we will use the default release version.

New command for displaying the version of OpenSSL currently used by UniVerse.

e.g. TCL command “CONFIG ALL” and diagnostic tool “smat -o” or “analyze.shm -o”

NOTE: This new feature supports all the operating systems except AIX, since its shared library supports overhaul. Due to the “natural” way AIX handles shared libraries-collecting shared objects of different versions and bitness in one common archive (i.e. a libcrypto.a containing,, you upgrade the minor version of OpenSSL on AIX, you can directly replace the new version of OpenSSL-three files: libcrypto.a, libssl.a, openssl in the server path $UVHOME/bin or $UDTHOME/bin). We will load the latest OpenSSL libraries from the archive file for server-side use.

Methods of building OpenSSL on different platforms.

Starting at Universe 11.3.2 and UniData 8.2.2, when compared to the previous version of OpenSSL such as 1.0.2/1.0.1, here are the changes to build OpenSSL 1.1.1.

  1. For OpenSSL’s application (the ‘openssl’ command), we use dynamic links instead of static links. We use the OpenSSL default way to dynamically link the executable, making it easy to compile UniVerse and UniData openssl. Because the old way is too complex, we must call our own compilation script, at the same time. In some special cases, we found that there was an issue with the OpenSSL by the static link. On AIX only, if we set the environment variable OPENSSL_FIPS=1, then the OpenSSL executable included with UniData generated an error.
  2. Use the default OpenSSL Shared libraries name. We use the original OpenSSL naming rules and have the major OpenSSL version number as part of the file name i.e., for OpenSSL 1.1.x, shared libraries are named and
  3. Use $ORIGIN to specify the runtime shared library search path for OpenSSL. For OpenSSL’s application (the ‘openssl’ command), it doesn’t set the runtime shared library search path by default. It’s therefore advisable to set it explicitly when we build it. When we do the configuration, we use the special variable “$ORIGIN”. “$ORIGIN” in an rpath specification means the directory contains the application executable. Thus, an application located in somedir/app could be compiled with gcc -Wl,-rpath,\’\$\$ORIGIN\’ so that it finds an associated shared library in somedir/app no matter where somedir is located in the directory hierarchy.

For example:

Windows Platform do configure
> perl Configure VC-WIN64A no-rc5 no-idea no-mdc2 no-asm

Linux Platform do configure
>./config no-mdc2 no-rc5 no-idea no-asm LDFLAGS=-Wl,-rpath,\'\$\$ORIGIN\'
nssl version -a

Solaris Platform do configure
>./Configure -R \'\$\$ORIGIN\' solaris64-sparcv9-cc no-mdc2 no-rc5 no-idea no-asm

HP Platform do configure
>./config -Wl,+b,\'\$\$ORIGIN\' no-mdc2 no-rc5 no-idea no-asm shared

Note: AIX doesn’t support $ORIGIN, so we will set the rpath to /.uvlibs in the same way as other libraries like and Make sure UniVerse/UniData loads our shared libraries.
>./Configure -Wl,-R,/.uvlibs aix64-cc no-mdc2 no-rc5 no-idea no-asm shared

For detailed compilation methods, you can refer to our documentation.


We are continually enhancing the security of UniVerse and UniData. As the software and information system security landscape is constantly evolving, we will keep introducing new security features and enhancements into the product. With the upcoming release of OpenSSL 3.0, we will continue to upgrade the new OpenSSL for UniVerse and UniData. OpenSSL 3.0 is a major release and will be a significant change to the internal architecture of OpenSSL. We will continue to pay close attention to new developments and changes in the security field to ensure the safety of our products.

Cheng Jiang 1 Posts

My name is Cheng Jiang, I'm a software engineer III and work in the Rocket Dalian office. I have been a member of the Rocket MV product development team for over three years. My main skills are C/C++/C# and I've worked on Basic and Security development for UniVerse and UniData.


  • Michael Kavanagh Reply

    January 13, 2020 at 4:07 pm

    Hi Cheng Jiang,

    What is happening with UniVerse 12.1.1 in regards to Open SSL 1.1.1

    Michael Kavanagh

  • Kathy Larson Reply

    January 14, 2020 at 1:04 pm

    Hi Michael, Based on the current roadmap, Unidata 8.2.2 and UniVerse 12.1.2 will include OpenSSL 1.1.1.

  • RB Hughes Reply

    January 20, 2020 at 11:32 am

    Very thorough article. Thank you. I’d be interested to know if Rocket is going to engage Senior engineers for the ‘field test’ of the release; those who have engineered previous versions of the security stack.

    • Kathy Larson Reply

      January 22, 2020 at 4:14 pm

      Hi Baker, great to hear from you and thank you! The author of the blog post, Cheng Jiang, is our senior security engineer and he and the QA team have tested this. Happy to chat with you more about this. Kathy

  • Martha Reply

    May 17, 2020 at 6:07 pm

    This article was awesome 🙂
    I was wondering if there is a way to know the connection history of UNIRPC daemon for users in Red Hat Linux.

Leave a Comment

Your email address will not be published.