The client certificate file I am trying with does indeed have the intermediate certificate included (and just in case, I've just tried without it and it presents the same error). This is probably an issue with openssl, but I'm not sure why. Running curl built with the same version of openssl used above, with this command line:

works perfectly fine (and also with curl loading the client cert and key separately, and also with curl loading the CA from the certificate store).

Thanks. Does your proxy-client_15-cert.crt contain just the leaf certificate? Or also the intermediate one? If just the leaf, would you please try appending the intermediate certificate too, to test if it changes anything?

Hey there, "print" seemingly isn't a valid option in that openssl command, so I removed it. I also used the MSYS2 distribution of openssl, let me know if you need output from that specific build. I'll note that the certificates were all generated with step and step-ca.

I've included the outputs unredacted, so please don't mention the hostname-looking CN in plain text here please :)

The _cafile variant of the connect command output included the -CAfile option pointing to the root certificate, which seemingly allowed the client certificate to be verified. Both of the connections fail with the same error though.

Can you post output of this command?

(redacted if you require)
Also, please try to connect with openssl and send the output too:

You can download Windows build of openssl from:
https://slproweb.com/download/Win64OpenSSL_Light-3_5_9.exe
(approved by the official OpenSSL site)

Connecting to a WebDAV server with a client certificate returns "Connection failed" with error:

The upstream server is a FileBrowser Quantum (v2.0.9-beta) instance with a Caddy (v2.11.4) instance in front performing TLS termination, and reverse proxying to FileBrowser. It is hosted on a non-standard HTTPS port.
Caddy is serving a non-publicly trusted certificate, which was trusted in WinSCP when prompted, and of which the root CA was already imported into the trusted root certificate authority store in Windows (for the current user only). The same root CA has created a certificate, and it has been bundled with the private key into a P12 file which is loaded by WinSCP as a client certificate in the site settings.
Attempting to connect to the server will fail with the error shown above, but connecting with Firefox with no server configuration changes does work normally (it prompts to send the client certificate, and everything works).
Disabling mTLS in Caddy, then removing the path to the client certificate in WinSCP makes the connection work.
Details:

• WinSCP version: 6.6.3 RC
  
• Windows version: Windows 11
  
• Protocol: WebDAV (TLS)
  

I have attached a session log, but the server hostname and certificate names are private, so quite a bit is redacted. To me, it looks like the client certificate CN is failing to be matched to something.