Tried the version you sent me and it does work with a local cacert.pem as expected.

Thanks!

Sorry for my late answer. It took me while to get to this.
I've implemented a support for custom certificate store files for all purposes (including the automatic upgrades).
https://winscp.net/tracker/2034
I'm sending you an email with a development version of WinSCP to the address you have used to register on this forum.
The new versions uses cacert.pem stored in the same folder as the WinSCP binary. But you can also use custom path via CertificateStorage value in HKCU\SOFTWARE\Martin Prikryl\WinSCP 2\Configuration\Interface.

Yup, I'm talking about the update check.

What exact connection does fail in WinSCP? Is this only about WinSCP check for updates? (as the question title suggests)

At first, it seemed exactly what I was looking for. The part about cacert.pem that is, because otherwise the root and intermediate certs are already in the Windows cert store.

Unfortunately however it doesn't seem like WinSCP is using cacert.pem at all (confirmed with procmon).

By glancing at code, I guessed that WinSCP is using neon and neon is using OpenSSL. And the Windows crypto comes to play as a callback when neon & openssl don't like the certificate (for whatever reason). Presumably since WinSCP doesn't pack (like git and most other) a root CA file (cacert.pem), neon/openssl will not like any https URL and then the callback will use the Windows crypto to decide whether or not it's ok.

Am I far off?

However, the fact that procmon is not showing any attempts to read cacert.pem makes me think that something has changed between that post and now.

The curl.exe binary that comes with Windows nowadays, has an option --ssl-no-revoke to disable checking for cert revocation. Please consider something similar.

No other program has the issue.

This thread might help you:
https://winscp.net/forum/viewtopic.php?t=24406

I had a little time to investigate a bit deeper the issue that I've been having for awhile.
I'm behind a corporate proxy that inspects the traffic, by breaking the TLS at the edge. The connection to the the client (WinSCP) is secured with a certificate issued by the edge appliance. The root CA and the intermediate are pushed to the domain machines by a domain policy. Chrome/Firefox etc. have no issues, apps that bring their own crypto (like git) need to have their CA root store updated and work fine after that.

WinSCP however does not. It throws Error: 80092012.
Which is "The revocation function was unable to check revocation for the certificate.".

I downloaded the source, though without C++ Builder (and being 25 years out of the C++ world) it is not easy to follow. The best candidate for where the error happens seem to be in Security.cpp

I can see that it goes for checking with and yes, the end certificate will fail this check as it doesn't list a revocation URL at all (the intermediate does).

What I don't understand is why it fails on two Windows Server Machines (2016 & 2019), but it does not fail on my Windows 10 machine.

I plucked out the function (WindowsValidateCertificate) into a test application and the test application failed the same way on all platforms.

So, if I read it correctly, WinSCP is using neon with OpenSSL. And it resorts to calling WindowsValidateCertificate only after neon's SSL validation failed.
When OpenSSL is used as a command-line tool, one can specify CAfile or CApath to point it to the trusted root certificates.
Where is the default root CA location and how can it be changed when OpenSSL is used as a library? Where is WinSCP trusted root CA store?