error:140A90F1:SSL routines:SSL_CTX_new:unable to load ssl2 md5 routines

Find the following information:

http://comments.gmane.org/gmane.comp.lib.boost.asio.user/2099

Well I think I have figured out what the issue is, or at least narrowed
it down. I have been able to provide a work around for our needs but I
wanted to post this in case someone came across this same issue.

It appears to be an issue with some type of static member initialization
inside the openssl library. I have 2 libraries, both of them use the
openssl library, let's call them A and B. When the application starts up
both A & B are able to successfully create a security context. Later,
when library B tries to create another security context it fails. Both
library A and B are module plugins to our application so they both will
load but if one is not needed it is unloaded. So once I realized that, I
ran some experiments.

If just A is loaded then things work fine.
If just B is loaded then things work fine.
If A and B are loaded, then A is unloaded, B fails
If A and B are loaded, then B is unloaded, A fails
If A is loaded, then unloaded, then B is loaded, B works fine
If B is loaded, then unloaded, then A is loaded, A works fine

So, my belief is that when openssl is loaded it initializes some static
members. Once a library that uses openssl is unloaded openssl clears
some needed state that prevents anyone else from creating a security
context.

Our temporary, and probably very bad, solution to this problem was to eliminate the call to EVP_Cleanup() in the digestOfBytes() method.

What apparently was happening is something like this: the Perl libraries that we were importing use openSSL, and load tables through something like OpenSSL_add_all_x. Because EVP_Cleanup()is global, the Perl libraries (probably LWP::Protocol::https) couldn't find the tables of algorithms when they went to look them up.

While this works, I'd really prefer to do something safer... not cleaning up seems like a sloppy solution.