Hi there.
I am working on a fresh VM install of Rocky 9.5 (blue onyx).
I have an application that is throwing this error at runtime:
/lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0
Through researching this error, I am lead to believe that the md2 algorithm has been deprecated, and that if my application needs it, I need to enable legacy support. I have done so, and verified that the md2 algorithm works from the command line.
After enabling legacy support, I re-built the application in question, but the error is the same.
I have read over and over recently that I should not mess with the version of OpenSSL that ships with the OS because so many things depend on it. So I’m wondering what the solution is to this problem…
Thanks in advance for helping a linux noob.
It looks like EVP_md2 is referenced in /lib64/libldap.so.2, but is not defined yet, maybe it’s looking in dependency OPENSSL_3.0.0.
I’ve verified that all of the dependencies are met, and you can see libcrytpo and libssl are there.
As you’ve likely figured out, md2 is enabled.
[root@router opt]# ldd /lib64/libldap.so.2
linux-vdso.so.1 (0x0000ffffa051a000)
liblber.so.2 => /lib64/liblber.so.2 (0x0000ffffa0449000)
libevent-2.1.so.7 => /lib64/libevent-2.1.so.7 (0x0000ffffa03d8000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x0000ffffa03a7000)
libssl.so.3 => /lib64/libssl.so.3 (0x0000ffffa02c3000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x0000ffff9fe00000)
libc.so.6 => /lib64/libc.so.6 (0x0000ffff9fc52000)
/lib/ld-linux-aarch64.so.1 (0x0000ffffa04dd000)
libcrypt.so.2 => /lib64/libcrypt.so.2 (0x0000ffffa027a000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000ffff9fbf1000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000ffff9fb0f000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000ffffa0249000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000ffff9faee000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000ffff9facb000)
libz.so.1 => /lib64/libz.so.1 (0x0000ffff9fa9a000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000ffff9fa79000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000ffff9fa58000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000ffff9fa15000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x0000ffff9f974000)
[root@router opt]# strings /lib64/libcrypto.so.3 | grep md2
EVP_md2
md2(char)
md2WithRSAEncryption
SPECS/openssl.spec · r9 · staging / rpms / openssl · GitLab - You can see here enable-md2 is indeed on.
This is correct. You do not want to make your own openssl build. The issue is likely going to be in your application. What exactly is this application and what is required to build it? Did you make any other system changes?
Yes, I verified that I can run the md2 algorithm from the command line. I did not know that trick with strings, but it’s good to see that the function definitions are present (I tested on my own machine too). It just makes all of this more mystifying though.
What exactly is this application and what is required to build it?
The application in question is the rti Routing Service using the kafka connection plugin found here: rticonnextdds-gateway/plugins/adapters/kafka at master · rticommunity/rticonnextdds-gateway · GitHub (I built the entire repo and all plugins, but am specifically using the plugin there).
I have not made any system changes. However, I am not the dev who provisioned this particular VM that our shop is using. I’ve reached out to that person to ask about any changes to OpenSSL they might have made… I doubt he did, as he is very experienced on Linux.
I reached out to RTI via their help forums, and was immediately told it must be an issue on my end. They gave me the same information that I’d already googled, which is to make sure md2 is enabled, which of course I’d already verified.
The only other thing I can think of is perhaps something was installed that is providing another version of libcrypto.so.3. Something like that could lead to an issue like this. For example, on physical servers where users may install dell’s utilities. Dell is notorious for packaging their own libcrypto which can cause some problems (usually in /opt). That could be something the dev may know.
The ldd program should show what libs the ‘program’ does use, just like the ldd /lib64/libldap.so.2 did show for the ‘libldap.so.2’.
Is the actual program executable called from a script? Does that script set environment variables before calling the program?
Actually, it is called from a script provided by the company who developed the application. They also just suggested that I use the executable directly, so that’s my next step to try! I’ll report back when I figure it out!
Indeed, the issue is that the script that sets the environment for the service and then runs it changes LD_LIBRARY_PATH to point to a vendor provided version of libcrypto.so.3, which DOES NOT contain the EVP_md2 symbol.
Moving the crypto lib out of the vendor’s application directory and onto my desktop got me past the error.
