# Couldn't load OpenSSL library in 12.1 (Windows)

Update: Finally I found a clumsy way to solve this bug by myself: I created an alternate local kernel to run the code, and it surprisingly works out!

It is ridiculous that two local kernels contain different features/bugs, I still cannot figure out the reason...

Recently when I evaluate

$Version GenerateAsymmetricKeyPair[]  on Windows10 1909 with Mathematica 12.1 in the front-end, it warns me: "12.1.0 for Microsoft Windows (64-bit) (March 14, 2020)" Encrypt::libopenssl: Couldn't load OpenSSL library.$Failed


However, it works perfectly in the Wolfram Kernel 12.1 without errors. And everything is fine on a Linux machine of version 12.1, as well as the Windows in the front-end of version 12.0. Does anybody encounter the same problem with me?

I tried to dig more about the issue, the corresponding OpenSSL file lies in

$InstallationDirectory\SystemFiles\Components\Cryptography\OpenSSLLink.m  or from the paclet $UserBasePacletsDirectory\Repository\Cryptography-12.2.0\OpenSSLLink.m


The warning comes from the command

checkedLibraryFunctionLoad[libraryPath, "scrypt",
{{Integer, 1}, {Integer, 1}, Integer, Integer, Integer, Integer}, {Integer, 1}]


with

LibraryFunction::libload: The function scrypt was not loaded from the file $UserBasePacletsDirectory\Repository\Cryptography-12.2.0\Resources\Libraries\OpenSSLLink64.dll.  While the file OpenSSLLink64.dll already exists, I am not familiar with LibraryFunctionLoad, I hope someone can help me fix this problem. Then I follow Szabolcs's suggestion to evaluate LibraryLink$LibraryError and obtain the output: Library load error 127: 找不到指定的程序。 (The specified module could not be found). Although my Windows Language is Chinese, all the installed paths (including the user name) are in English.

• I installed 12.1 version of Mathematica on win10. I didn't get the error you said after running your code. Apr 3 '20 at 3:03
• Please do not use the bugs tag when posting new questions. Do add this tag to other people's questions when appropriate. Please see the tag description for more details. Apr 3 '20 at 11:54
• Can you reproduce this after restarting Mathematica? If yes, please evaluate LibraryLink$LibraryError immediately after the error and add the result to the question. Apr 3 '20 at 11:54 • @Szabolcs Thanks for you reply, I have removed the tag and updated the question. Apr 3 '20 at 13:30 • See my comment under the other question. We should have a fix for this in the form of a paclet update soon. Apr 5 '20 at 4:36 ## 2 Answers A likely fix for this issue has been released with the CURLLink 12.1.1 paclet update. This update will not be automatically installed, but can be acquired by evaluating PacletSiteUpdate /@ PacletSites[]; PacletInstall["CURLLink"]  and restarting Mathematica. If anyone is curious, here are some comments on the symptoms being observed. As mentioned in the question, there was an error in loading the library function scrypt: LibraryFunction::libload: The function scrypt was not loaded from the file ... OpenSSLLink64.dll. There is nothing special about that symbol, it just happens to be the first one attempted. Furthermore, it is not missing from OpenSSLLink64.dll and the latter library is not corrupt in any way, but it does fail to load, so none of its symbols can be found. The problem is not with OpenSSLLink64.dll but with its main dependency, the OpenSSL library libcrypto-1_1-x64.dll. Normally it would be dynamically loaded from the Mathematica layout, specifically from the SystemFiles\Libraries\Windows-x86-64 directory and everything would work correctly. But under certain circumstances, another instance of the library present on the system (most likely installed in a system-wide location like C:\Windows\System32) can be found under the standard Windows DLL search order. It is also likely to be incompatible with OpenSSLLink because it has been compiled with a different set of enabled features, which results in the error seen. This will not be the case for most Windows installations (and clearly it was not the case for any of the systems used in release testing). What is the relevance of CURLLink and how can updating that paclet fix the problem? It turns out that one of libcurl's several dependencies can indirectly load libcrypto-1_1-x64.dll by relying on the OS to locate it. This happens early in the session, especially when the FE is used, for purposes such as checking for paclet updates or signing in to the cloud. By the way, that also explains the differences seen in a standalone kernel, or in an alternative local kernel, which happen to be initialized in a slightly different way. Fortunately, this problem is easy to fix by explicitly preloading the above dynamic dependency from its correct location instead of asking the OS for it. • Thanks a lot! I have checked this bug is perfectly fixed! Apr 7 '20 at 2:11 • Thanks for the confirmation, I expanded the answer with some more details. Apr 7 '20 at 2:57 The error message LibraryFunction::libload: The function scrypt was not loaded from the file C:\Users\[MYNAME]\AppData\Roaming\Mathematica\Paclets\Repository\Cryptography-12.2.0\Resources\Libraries\OpenSSLLink64.dll.  suggests that the library downloaded to your $UserBasePacletsDirectory is corrupt in some manner.

I would recommend running SystemOpen@$UserBasePacletsDirectory, going to the /Repository/ subdirectory, and deleting all directories that start with Cryptography. Restart Mathematica, try the functionality again, and see what happens. Hopefully it will work. I've checked the .dll within the same paclet installed on my Windows machine and it doesn't seem to have this issue the scrypt symbol is present. If the above does not work, alternatively you can copy OpenSSLLink64.dll from $InstallationDirectory\SystemFiles\Components\Cryptography\Resources\Libraries to your C:\Users\[MYNAME]\AppData\Roaming\Mathematica\Paclets\Repository\Cryptography-12.2.0\Resources\Libraries\. Barring any sort of corruption, the .dll at both of these locations should be near identical in content.

• Thanks for your answer :) The first suggestion does not work, and I have checked the two OpenSSLLink64.dll are exactly the same. Besides I tried to run GenerateAsymmetricKeyPair[] directly in the Kernel and found surprisingly no errors !!! While evaluating in the front-end fails, which makes me very puzzled. Apr 3 '20 at 18:12
• @Pei-XinShen what does Cryptography$LibraryVersion return in both your FE and kernel? – ktm Apr 3 '20 at 18:58 • The front-end still returns Encrypt::libopenssl: Couldn't load OpenSSL library.$Failed, while the kernel gives OpenSSL 1.1.1d 10 Sep 2019. I also try PacletObject["Cryptography"]["Version"], and they both returns 12.2.0. @ktm Apr 3 '20 at 19:03
• For the default local Kernel, it fails and returns Library load error 127, as illustrated in the question. But it is weird that when I create another local kernel, everything runs perfectly there (shown in my updated figure). Apr 3 '20 at 20:23
• The "missing procedure" that error 127 refers to is not scrypt` but something else. And while OpenSSLLink64.dll fails to load, the problem isn't in the DLL itself. Apr 5 '20 at 4:28