Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...


Daniel Nashed


OpenSSL past and present -- what you need to know about standards and conversions

Daniel Nashed  10 April 2024 23:01:17

OpenSSL is the open source project, which is part of most software today.
It is an integral component of Linux and the foundation software is built on.

There are three major streams you should know about:

- 1.0.2 LTS

- 1.1.1. LTS

- 3.0.x LTS

The jump in the version number to version 3.0 is an indication of a major change.

- OpenSSL 1.0.2 should be avoided for quite some time and I would personally also move off 1.x in general.
- OpenSSL 3.0 is modularized and supports loading different providers like the FIPS provider.

But it also deprecates some older functionality, which must be loaded explicitly from a legacy module.
On the other side it uses some defaults which older software does not support.

Not all software has made the jump to at least OpenSSL 3.0.

Therefore it is important to understand some new defaults and some removed standards.

OpenSSL development changes

If you are a OpenSSL developer you know a lot more changed under the covers and a lot of functionality needs to be changed to be fully OpenSSL 3.x compatible.
The first functions you run into are the RSA/EC keys, which should be replaced with EVP keys in OpenSSL 3.0.
But also using the Fetch functionality is important. You can find the a good starting point in the documentation here -->

When looking in Milan's post today about an issue he ran into I took a look into the old format he was using.

The problem is already escalated to development and there is a SPR and a fix going into the next release and fixpacks.
But reading the old standard with out the MAC is problematic in general. But it should not crash.
Below is a command-line to convert the PKCS12 file even with modern OpenSSL 3.0.x.


Export/Import/Conversion challenges

I created some test PKCS12 files without a MAC and noticed the -nomac option is only available in older OpenSSL versions.
Version 3.0 and above does not have this functionality any more.

Windows still uses this old version and creates encrypted PKCS12 files and also encrypted PEM files with a quite old standard.

I tried to open the PKCS12 file with my own certificate command-line tool, which statically links with the latest OpenSSL 3.x versions and ran into an error message importing the very old format.
The same happens when you try to open it with a OpenSSL 3.0 command line:

openssl pkcs12 -in mac.pfx -out export.pem -nodes

Error outputting keys and certificates

40672F2A027F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:349:
Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()

If you want to convert a legacy PKCS12 file, you need to specify the -legacy option.

Modern encryption standard used

Here is a text from OpenSSL, which describes the new standard and the legacy option.

The default encryption algorithm is AES-256-CBC with PBKDF2 for key derivation.

When encountering problems loading legacy PKCS#12 files that involve, for example, RC2-40-CBC, try using the -legacy option and, if needed, the -provider-path option.


Use legacy mode of operation and automatically load the legacy provider.
If OpenSSL is not installed system-wide, it is necessary to also use, for example, -provider-path ./providers or to set the environment variable OPENSSL_MODULES to point to the directory where the providers can be found.

In the legacy mode, the default algorithm for certificate encryption is RC2_CBC or 3DES_CBC depending on whether the RC2 cipher is enabled in the build.
The default algorithm for private key encryption is 3DES_CBC. If the legacy option is not specified, then the legacy provider is not loaded and the default encryption algorithm for both certificates and private keys is AES_256_CBC with PBKDF2 for key derivation.


Use the -legacy option if you really need it to read old format. But make sure you use the new default, more modern and secure standards whenever you can.

New versions might have the challenge to not being able to read older formats at some point.

The CertStore functionality isn't directly built on OpenSSL code. But it uses the same modern standard for export.
Import/Export are client code. The encryption is always performed on the client.

In case you need an older encryption standard for Java and other applications, there is a client side notes.ini settings to lower the standard to 3DES.


But again this is also just a fallback intended for compatibility.

Importing PKCS12 and PEM encrypted files will still work with older formats without a setting.
Only the missing MAC is a problem, which can be avoided with the OpenSSL command line shown above.



    • [HCL Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]