One of my developers has started getting this error, which causes the module tree to disappear etc in CS IDE, cant find anything on a KC / Forum search.
Just some additional detail on the above - CSIDE worked perfectly in this environment until it integrated with Archive Center. The error seems to be thrown immediately after calls are made to archive center config (single instance seckey config). This is a 21.1 OTCS instance, upgraded from 10.5. On the 10.5 instance, where the single instance radio button doesn't exist, we don't have a problem, so suspecting that it is related.
Hi Greg - the SSL error typically points to path issues with an external installation of OpenSSL. We wind up picking up the incorrect libraries in this case & the result is the above.
Given this: can you check to see if OpenSSL is installed as an independent application? If it is: does upgrading to the latest release (or uninstalling) resolve? If so: we know what needs to change (assuming that upgrading or uninstalling isn't seen as a fix in & of itself).
Should you want to look into this further: as per https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order it looks like figuring out where the DLL is coming from is a bit complicated, however this is where to begin the hunt 🙂
All the best (& lemme know if this applies at all) , Dave
Thanks Dave - OpenSSL is indeed installed on the server manifesting this issue. It is version 1.1.1 and I see the latest version is 3.0. Bit of a challenge we have in trying the removal/upgrades is that we are in a bit of a locked-down environment with a 3rd party provider controlling the infrastructure and peripheral installations (such as OpenSSL). Preferred option will definitely be unistallation/upgrade - unless they can give us a specific business case for keeping the status quo on servers provisioned for our use. While I get the very slow-moving wheels turning on that, I'll see if I can work anything out on the DLL article. (We have just been using http until now, so were potentially chasing a bit of a red herring on looking at seeing if https enablement would resolve the issue.
Hi Dave - unfortunately unistalling OpenSSL did not make a difference. Will see if I can get the latest version installed to see if that changes anything.
unfortunately uninstalling OpenSSL did not make a difference.
At the end of the day the error points to a mismatch between the SSL library version used by Content Server & what CSIDE is picking up from the environment. In the past removing OpenSSL got things moving.
Does doing a search for files named "libssl*" show anything? Maybe the uninstall left behind some detritus.
Hi Dave - I did indeed find libssl-1_1-x64.dll under c:\windows\system32. It was initially held by the perldtn proces (we had used perl for an archive centre upgrade. As above, before repointing to AC subsequent to the upgrade, this all worked fine). Uninstalled perl pipeline, and found the ssl.dll was held by tomcat, so stopped tomcat and was able to remove it without ill effect on tomcat. However, no change to behaviour and still getting that error. Googling on it seems to indicate that the code used must use an openssl version exactly the same as what it was built against (in this case the dropin for ixos) (does seem to be a fairly common error with .Net applications etc, but where they are specifically using openssl) so guess the next step is to try and either find out what version of openssl AC 20.4 expects (or the associated dropins?) or try a deployment of the latest version of openssl. (V3.0)
Although just checked - the version of openssl we were using was 1.1.1 - only released on 14 Dec 2021, so unlikely that 3.0.1 will sort the issue.
the version of openssl we were using was 1.1.1
As per the FAQ ( https://www.openssl.org/docs/faq.html , section "I’ve compiled a program under Windows and it crashes: why?" ):
As per 0.9.8 the above limitation is eliminated for .DLLs. OpenSSL
.DLLs compiled with some specific run-time option [we recommend the
default /MD] can be deployed with application compiled with different
option or even different compiler. But there is a catch! Instead of
re-compiling OpenSSL toolkit, as you would have to with prior versions,
you have to compile small C snippet with compiler and/or options of
your choice. The snippet gets installed as
<install-root>/include/openssl/applink.c and should be either added to
your project or simply #include-d in one [and only one] of your source
files. Failure to do either manifests itself as fatal "no
OPENSSL_Applink" error.
... so if you were using 1.1.1 this problem would only be seen if you / your vendor compiled without considering the above. Alternately it's possible that there are multiple OpenSSLs at play (with some of them pre-0.9.8) ...
Thanks Dave - yes - hence I've raised this with OpenText Support (as the vendor that compiled the drop-in). Definitely no earlier versions, as this server was a new build.
