Is the server publicly available (for testing)?

@martin: certificates used in the test had no OCSP and CRL defined – which is usually conscious decision of CA owner (for example using short-living certificates issued by ACME-compatible infrastructure) and it's different situation than inaccessible revocation status information.

Web browsers don't complain in situations like that and in my opinion it shouldn't result in "Unknown certificate" warning. Certificate is OK, chain can be validated, revocation status is not expected to be checked. And if that was certificate with OCSP/CRL end-points defined, it should rather be something like "Can't check revocation status" warning instead of "Unknown certificate".

The error 80092012 stands for "The revocation function was unable to check revocation for the certificate".
So the certificate is correctly recognized, but it's revocation check function is possibly misconfigured.

Steps:

1. Create root CA, intermediate CA and host certificate (use CA/Browser Forum Baseline Requirements as guidance, when in doubt). Host certificate CN and SAN entries should match hostname of FTP server.
   
2. Import root CA to client machine trusted certificates store (using certlm.msc, for example).
   
3. Configure FTP server with enforced TLS (let's say pure-ftpd with TLS=3).
   
4. Configure certificate chain on FTP server: host private, host public, intermediate CA, optionally root CA at end (root CA generally shouldn't be sent, as client should have it in own trusted CA store).
   
5. Try to connect to this FTP server using WinSCP and following settings FTP, explicit TLS.
   

Outcome: "Warning: The server's certificate is not known." popup message. See attached log file for details.
Expected outcome: X.509 certificate chain successfully validated, connection established. It should work as in HTTPS server using same chain and web browser as client.