Since Mercury32 moved to using OpenSSL, I've never had any problem updating to the latest compatible version of OpenSSL.  I am currently using OpenSSL 1.0.2t released in 10-Sep-2019.
I just make sure I use a 32-bit build without external dependencies to the Microsoft Visual Studio Runtime DLLs, except for the system provided msvcrt.dll.
I don't build OpenSSL myself.  I download it from one of the Windows 32/64 precompiled binaries sites listed on the OpenSSL wiki.
Before I made the switch, a few years ago, I did verify that every function exported in the version that came with Mercury was available in the one I was switching too.
Now I just shut down Mercury, update the affected fields and restart.
Hoping that the next version of Mercury updates to use Open SSL 1.1.1 since 1.0.2 which was a LTS release is approaching EOL.

In order to send mail to many systems, including GMail, I had to bump up the compliance levels of my server, and so I created a certificate with Mercury and enabled SSL connections on Mercury S(MTP).

 This works for a while, but then it seizes up and stops accepting connections, reporting only 'SSL Error' and I have to restart Mercury.

Has anyone else seen this?  Is there a solution?

Assuming the error message is relevant the solution is most likely to update SSL handling, for instance by installing the 4.81 version of Mercury. It's still not publicly released but I can send you a download link if you would be interested to try it.

I certainly would be keen to give it a go.  It's certainly too unreliable the way it is, haha.  =)

On its way, let's hope it will work better!

Thank you for that.  I'll spin it up and report back.  

Where would you like me to submit feedback?  Here, privately, or...?

Either way works fine. I'll probably see it quicker if you send it directly to me though!

After a day or so with SSL enabled, Mercury starts refusing connections / dropping connections do to SSL connection errors. Drives me nuts. I need SSL enabled for gmail and such to send emails. I find myself having to restart mercury every few days.

I am using 4.80.145 with stunnel since many months without problems. Perhaps you should give stunnel a try too...

The beta version Rolf mentioned has been functioning without issue since I installed it.  It certainly seems like this is the fix.

It seems to have fixed the issue

The problem got triggered mostly when I received a lot of emails from gmail (or it seems)

Oddly enough,  in the past year I was not running into this problem that often. Once in a while I would have to restart mercury. But within the last few months it seems like I had to restart mercury almost every few days.

So I am thinking either a windows update changed how my server functions, openssl versions (too many open ssl version on same pc), or google and other companies started to use the newer version of TLS (more frequently), or there is an exploit that would crash the SSL.

I use to run into this issue with two mail servers and an ssl tunnel (both using open), and one would crash the other eventually ssl did not work. Somehow there was an OpenSSL conflict. So I stopped using WinSSL  (SSLWRAP) and stoped using SSL for rthe most part on thhe other server, and started to use stunnel.

This fixed the issue,  Stunnel SSL would not crashed, and for the other mail server would operate find, and mercury would operate fine. In the past, when SSL stopped working, all the programs that relied on OpenSSL (different version) would stop working.

But in the past few months, this issue started to act up again. and in the last month very frequent.

I am not much of a fan of OpenSSL Somehow a conflict starts to exist. It  would probably just be better to have a build version of the OpenSSL library using a different name, to avoid possible conflicts/caching.

On my other server, Mercury would always have an SSL error (both Server 2008 and Server 2012), yet other mail servers using older openssl operated fine.

I am hoping this fix will address this issue and will try mercury on that server too.

But on my main server (Windows 10 Pro), it seems like the issue has been fixed.

OpenSSL is a pain to work with. (Each program has its own version of OpenSSL dlls, some copy them to main windows directory, and I think there may of been a windows update that tried to remove/disable vulnerable versions)
My conclusion, openssl can be a version conflict nightmare. On top of that, some programs use a proprietary/pre-compiled version of openSSL, so switching the library to a newer version may break the program.

In the case of other run times, eg: c++ and vb, the names and version of the libraries are consistent, and newer version can be installed along side each other, but that's not the case of openssl, where newer version brick versions requiring older versions.

 I wish it was just as easy as to replace the OpenSSL libraries, but sadly enough its not.

The OpenSSL problem with different versions exists only with Windows without WSL. Linux is more straight ahead and all applications knows & uses the path.

Normally the maintainer(s) for an application is/are bugfixing such type of problems... We know about David's current illness, but his burnout is still there. PMail and Mercury urgently need updates specifically on what M$ has changed in terms of security, and the SSL issues are forcing all software vendors to fast patches. I have been waiting more than a year for the problems to be solved with "sentsince". As a quick fix, I can rewrite a PHP file on my e2-receiver and use "senton" instead. But that can not be a permanent state.