CAPI engine seems to break server validation

[Brett Stahlman]

Hello,
I'm attempting to use the s_client command on Windows 10 to connect to a
secure server (client.badssl.com) that requires client authentication. When
I run the following command...

echo -e 'GET / HTTP/1.1\r\nHost: client.badssl.com\r\n\r\n' |
./dist/bin/openssl.exe s_client -ign_eof -verifyCAfile ca-bundle.crt
-connect client.badssl.com:443

...server verification succeeds, but I get a 400 error: "No required SSL
certificate was sent"

So I tried using the CAPI engine to handle ssl client authentication:
echo -e 'GET / HTTP/1.1\r\nHost: client.badssl.com\r\n\r\n' |
./dist/bin/openssl.exe s_client -ign_eof -verifyCAfile ca-bundle.crt
-ssl_client_engine capi -connect client.badssl.com:443

But now the failure occurs even earlier:
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3310 bytes and written 330 bytes
Verification error: certificate signature failure

It seems that the CAPI engine is breaking the server verification somehow.
Note that the only reason I'm using the ca-bundle.crt is that I couldn't
figure out how to get CAPI to load the Windows "ROOT" certificate
store, which contains the requisite CA certs. Ideally, server
authentication would use the CA certs in the Windows "ROOT" store, and
client authentication would use the certs in the Windows "MY" store, but
CAPI doesn't appear to be loading either one.

Note: I can use the openssl "engine" command to get CAPI to list the certs
in a store by name: e.g.,
./dist/bin/openssl.exe engine -t -post store_name:ROOT -post list_certs capi

But this doesn't help much if the engine doesn't load them automatically
when a client connection is made with s_client. I was under the impression
that CAPI would automatically use the Windows cert stores for client and
server authentication. Have I misunderstood the goal of the CAPI engine?

Thanks,
Brett S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20201023/1b98e2de/attachment-0001.html>